01:20:39 plowsof: "Rucknium have there been any KISS solutions of lifting suggested defences against selfish mining from published papers? Like instead of first seen, lick the winner at random? " 01:20:41 Regarding what to pick as the random source, we could hash the array of all candidate block hashes and use the first bits as entropy for picking 01:20:43 see here: https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$vRiWlVnrANOGV_7hUHiZ3PX3O6yfq7ocooltlHDVTJI?via=matrix.org&via=monero.social&via=cypherstack.com 01:21:16 *all competing block hashes 05:24:28 https://juraj.bednar.io/en/blog-en/2020/11/18/bitcoin-censorship-will-most-likely-come-pt-2/ 05:24:29 may be good to read 11:44:35 History of BFT in Ethereum: past votes affect chain tip selection. https://eth2book.info/latest/part2/consensus/lmd_ghost/#finding-the-head-block 13:12:46 voting, slashing, halting, liveness, safety, 1/3, 2/3... it's an entire can of worms 13:12:47 I wonder if / when the project decides on a general direction forward, should we do weighted voting based proof_reserves? with slashing / voiding the vote if somebody votes more than once :) 13:25:05 it would be a gauge for coin migration / price movement after the inevitable hard fork 13:29:05 I also wonder why my proposal hasn't solicited more discussion.. 13:29:05 PoW, as I understand it has no deadlock (100% safety), but 33% liveness (defined as something good/expected happens, under selfish mining+51% attack) 13:29:07 I believe my proposal raises that bar to 66% for the so-coined 51% attack to be profitable. 13:38:00 if anybody wonders about the percentages, just have a look at yesterday's raid from qubic, their transparent hashrate was at around 2gh/s whereas 1gh/s was used internally for their side-chain 13:42:09 Going through the linked paper @venture, hopefully I can say something constructive 13:43:06 thanks! It would just be the section 3.6.1 that is relevant 13:43:13 I wonder if this stems from a Bitcoin talk thread I was reading? I.e. where this came from 13:44:27 byzcoin.. yeah no idea what happened to that and why it failed or never launched?, would be good to find that out. But yes, i did come to it from bitcointalk 13:51:04 This is a crazy idea, but almost feels too easy. The thing is that it changes the selfish mining for sure, they can't predict which block chain will win. If your +2 on the side chain you potentially use lots of work by not being cooperative 13:53:55 Looks like they werent using pow for byzcoin tho, but it should still work 13:54:34 I'll look up the byzcoin discussion I guess. The problem is that this requires a hard fork, and that takes some time 14:17:16 yes, it does seem more aligned. It doesn't eliminate the attack vector completely though, if you can generate blocks and compare hashes faster than rest. but this takes 150% network hashrate (the side chain hashrate is never included in monerod hashrate). 1/1.5 = 0.6666 14:18:18 if Im understanding this correctly, we’d also need to broadcast all minority chains (that have valid pow) for this to work. currently we dont do this 14:18:35 someone proposed this the other day 14:20:20 not sure about this. in the honest / normal case, there are no minority chains? and if somebody broadcasts an altchain, we compare it with the main chain (each sibling if it's deeper than one block re-org) 14:20:54 and reject atomically 14:21:52 if Im reading this correctly, the suggestion is to make reorgs determinisitic but unpredictable via hashing 14:22:35 everyone needs to compare both chains to make this happen 14:23:03 yes, it's deterministic. and exponentially harder the longer re-org. since it's 0.5 if you have 2 candidate block hashes. 0.5^3 for the alt branch to be accepted + the needed difficulty in the first place 14:23:16 selfish mining also becomes more unpredictable as you “lose” 50% of the time you try it. someone better with statistics may need to crunch the outcome 14:24:00 *my example was for 3 blocks deep re-org 14:24:39 I don’t follow the last part of your sentence. why would it get harder for longer reorgs? 14:25:33 each competing block of the alt chain has a sibling in the main chain. it would be compared to each and the entire alt-chain would be rejected atomically 14:26:21 since, this is not something that can be done in pure PoW? 14:27:05 yeah I thought it was saying you put every block hash involved in sorted order into a hash function again, and then use that to determine which entire chain to use 14:28:20 maybe I need to read the whole paper instead of skipping to this section? 14:29:18 I will also read through again.. not sure if they went further. The sibling thing was my interpretation of it 14:30:40 but intuitively, we want it to be exponentially harder with each block, instead of building an alt chain and then doing one coin-toss? 14:32:29 Yes, but I don't see how it can done that way. You cant pick and choose blocks and you can't know which chain was seen first 14:33:06 it's also used for indexing with which block to go with / mine upon. so having multiple block hashes at different levels in the array doesn't work 14:33:07 The other issue is that I think this helps pop off honesst chains 14:33:26 Nvm, not thrilled about it, but will look at Bitcoin talk for some outside thoughts 14:35:53 doesn't the re-org procedure has the blockchain and the altchain? 14:36:17 https://eprint.iacr.org/2019/676.pdf, p.3 III for critique 14:39:46 With 3.6.1, am I missing something, or does this simply change how the singular top block in a chain is selected, if there are competing top blocks? A deep reorganization to a chain with more is still possible afaict 14:39:55 they don't mention the selfish mining defense but other parts of byzcoin like their collective signing it seems 14:40:59 well, how is it now selected? First seen? But yes, it changes 14:41:19 and yes, it's still possible but with more hashing power to honest miners 14:41:39 (imho) 14:41:54 It's only used to select between forks of equal chainwork. Longer chain still takes precedence. 14:42:51 I still don't see how their defense mechanism works to the benefit of everyone. A selfish miner could just trigger a single alternative block proposal, and win 50% of the time 14:45:02 I tend to prefer the simplicity of the first block seen is the one that should be used, but this seems like a relatively minor implementation detail not a meaningful increase in security 14:45:53 It doesn't work basically, I got excited because I was reading with too hopeful of eyes. Sorry 14:46:07 Unless tevador has any follow ups 14:53:22 it's a balance shift of 33% needed for a selfish miner to 66% 14:55:05 Where do you get the 66% from? Page 15? 14:55:12 i guess you are right here. we would need to keep the fluffy orphans or fluffy orphan chain around for IBD/sync. 14:55:13 But it wouldn't happen anymore than previous time before qubic, unless they have 66% 14:57:26 i derived it. might be wrong. but since selfish mining doesn't increase network hashrate (they replace blocks), currently they need 33%. and with that change it would be 0.66 I THINK. need to formalize it again. but the percentages are tricky when we calculate attackers hashrate, since this is not transparent 14:58:16 AFAIK this deterministic fork selection was used to reduce the impact of network propagation delays. It was not meant to address selfish mining. 14:58:34 Having 51% hashrate would allow them to always have the longest block in any case under this scheme. So I don't see how it's possible to be higher than 51% 14:58:46 Yes but the problem is they can still do one block in secret, then trigger this algorithm when the honest nodes relay there block. The selfish node would win 50% of the time. Currently the selfish mining algorithm gives up if there's another block relayed 14:58:50 no, they directly tackle selfish mining with that 14:59:07 Yes, it makes selfish mining worse. 14:59:19 And I don't think it works as expected 15:01:06 You can't use the deterministic selection for chains of different length, otherwise anyone can fork off a block of any age just by mining a block that wins the selection formula. 15:01:43 i need to think it through, but my intuition is that blocks produced are basically a sampling function of the underlying hashrate. 15:01:45 in 50% of the cases AFTER they produced a block, the attacker would need to generate another one which the majority was already mining upon 15:02:10 that's why it needs to be applied at every level 15:02:30 but maybe I'm really premature with this... 15:03:26 The example in the paper includes a finality layer with the PBFT, which might be crossing wires here 15:04:31 ^ see my previous explanation. 15:04:31 but again, i might be missing something 15:07:19 "Currently the selfish mining algorithm gives up if there's another block relayed" 15:07:21 I don't think this is accurate, they might be building nonetheless and hoping to catch up 15:08:39 ah well, need to read sirer's paper again. but it's not substantial 15:13:57 "(Now same length. Try our luck)" from the selfish-mining paper 15:17:52 I believe, this would cut their luck of the sampling function / blocks found literally in half, which by definition eliminates their luck 15:22:30 51% of what? The effort that goes into the main chain? Not any side chain. That's not true then. if you have say 60% and eventually 40% of the hashrate produces a block and you attempt to override it, you have 50% chance to do so. 15:23:20 so your 40% hashrate gives you 20% effective blocks produced under adverserial conditions (in the worst case), in the average case, it's 40 15:24:27 ^ given the hash thing proposal 15:43:04 currently: 15:43:05 > 33%: need 50% luck to override / re-org the main chain 15:43:07 > 50% can always override completely and catch-up the main chain eventually, ie. squat all blocks 15:43:09 with the hashing: 15:43:11 > 33% no chance to override the main chain *probabilisticly*. If you have 20%, 20% will go through eventually 15:43:13 > 50% may cut others effective hashrate in half. 20% hashrate => 10% blocks over adversial times 15:43:15 > 66% I believe that number is correct, can always override completely 15:44:06 formatting went wrong , there should be an > before the numbers 15:45:27 <1​7lifers:matrix.org> put a backslash before each of the greater-than signs 15:51:41 currently: 15:51:41 \> 33%: need 50% luck to override / re-org the main chain 15:51:43 \> 50% can always override completely and catch-up the main chain eventually, ie. squat all blocks 15:51:45 with the hashing: 15:51:47 \> 33% no chance to override the main chain _probabilisticly_. If you have 20%, 20% will go through eventually 15:51:49 \> 50% may cut others effective hashrate in half. 20% hashrate => 10% blocks over adversial times 15:51:51 \> 66% I believe that number is correct, can always override completely 15:54:28 not repeating the same points challenge: IMPOSSIBLE 16:26:10 There is nothing you can do with PoW that protects the network from an attacker with >50% of the hashrate. 16:28:05 Some people really believes that there exists some CONSENSUS algorithm that resist to 51% attack. aka consensus being resilient to consensus 16:36:41 tevador: you can get rid of it /s 16:37:44 51% would be the bound even with full synchrony, yeah 17:41:48 takes a bet and a monte carlo simulation to prove you wrong. 17:41:49 we do agree that blocks are sampling from the hashrate distribution, right? So, under normal circumstances, having 2 players with 1% and 99% hashrate, will have the minor player produce 100 blocks out of 10,000 for example. 17:41:51 same logic for 60/40 distribution. 17:41:53 under adverserial circumstances, the blocks are not accurately sampling from the distribution because of overwritings by the major player. 17:41:55 but I maintain, that in the range of 50-66%, at least half will get through and fail to be overriden given the hashing thingy. 17:41:57 it's maybe easier to see when you think of effort or hashrate as thermodynamic work, general flow of entropy. the adversary mines need to "mine" backwards that direction since every time the hash-coin-toss fails for him, he needs to attempt again by finding a whole new block hash. and that will happen 50% of the time. he will be able to succeed in the other half, hence slashing th 17:41:59 e expected payout of the victim in half (from 40% to 20%) 17:42:46 One detail you missed: an attacker with >50% of the hashrate can produce 100% of the blocks. 17:43:52 tevador: right now, pure PoW, this is the case. if he chooses to do so / employ overwriting 17:46:01 The attacker can simply ignore all blocks they didn't mine themselves and eventually their chain will be the longest one. No magic math or hashes can help with that. 17:46:38 for > 66%, yes 17:46:44 For >50% 17:46:49 but I guess a monte carlo is warranted 17:48:44 it would get rejected by the rest if he ignores one that didn't satisfy the hash condition 17:49:16 it would get rejected by the rest if he ignores one that and builds a competing one that didn't satisfy the hash condition 17:49:26 Monte Carlo will just confirm what I said above. >50% by definition means the attacker is on average producing more chainwork than the rest of the network, so under any "most-work" rule, their chain will always be selected. 17:49:57 we are talking about amending the most-work / LCR rule 17:51:25 OK, then please write out the complete set of changes (not here but in a document/repository) and then it can be reviewed. Any rule other than "most-work" is set to fail with PoW. 18:00:01 "it's maybe easier to see when you think of effort or hashrate as thermodynamic work, general flow of entropy. the adversary mines need to "mine" backwards that direction since every time the hash-coin-toss fails for him, he needs to **attempt again by finding a whole new block hash**. and that will happen 50% of the time. he will be able to succeed in the other half, hence slashi 18:00:01 ng the expected payout of the victim in half (from 40% to 20%)" 18:00:03 please remember, the effort I highlighted will not contribute to cumulative difficulty 18:03:53 If your new rule is that everytime I encounter two valid blocks at the same height, I use a hash-coin-toss to select the correct one, then this is completely disfunctional. I can mine a block at height 1 until I win the coin toss and reorg the whole network to the genesis block. 18:05:53 tevador: first of all, first you would need an altchain with similar cumulative diff. secondly, the coin toss is applied at every block along both chains 18:06:30 A chain of one is the most interesting. A selfish miner ends up with even more blocks 18:07:18 If you can't see this, then the discussion needs to happen in direct messages or something, because it's not going to work. The paper also had other flaws as listed in document above 18:08:02 You just said that cumulative diff rule was amended with the new rule. 18:08:49 If you want to continue, the chat should be in #monero-research-lounge 18:09:09 it's okay, we can end it here. I will attempt to model a monte carlo simulation. but it's rather complex. 18:10:22 Then remember to model a scenario when a new node joins the network and is presented with the attacker's chain that has a much higher cumulative difficulty. 18:11:03 ok