On 02/05/2014 10:56 a.m., Joseph Bonneau wrote: > This is an interesting idea Sergio. I have two concerns: > > You mention "50% of the block reward" going to the uncle block. Does > this mean the parent gets 1, and the uncle 0.5, or both get 0.5? In > the first interpretation (which I assumed was the design), mining is > no longer a zero-sum game and this could have lots of unforeseen > implications. For example, selfish mining might be more profitable, > since you're less disincentivized to avoid conflicts. The second interpretation is the correct one. > In the second interpretation, there's pressure to have the next miner > ignore the uncle to not share the reward. This would encourage > kickback-style attacks and advantage large mining pools because they > can mine on their own blocks and ignore colliding uncles. Including an uncle can be done at any time before a coinbase matures (100 blocks) (of course the term "uncle" is misleading in those cases) . So, for example, the uncle can be included 50 blocks afterward. So it's very difficult that a miner prevents other miners from including the uncle and taking the reward given by uncle inclusion.
Same ineffective attack: A big miner could try to bribe all other miners not to include the uncle, but this would be terribly costly. Suppose that I mine a block ignoring an uncle Z and then I publish this message: "Every miner from block number X to block number Y that does not include this uncle Z will be given Q Bitcoins". How much would Q be? Since by including the uncle the miner gets 5 BTC of reward (in the example case where block reward is 50 BTC), then each bribery payment would have to be higher than 5 BTC, totaling 500 BTC ! much more than the 25 BTC the miner will loose by including the uncle. Just by sending a transaction with a lot of fees that depends on my block does not prevent subsequent miners from including the supposedly banned uncle. Then, I think there are no kickback-style attacks. > > Also, I think this came up in the Princeton meet-up, but it's not > ideal to just hash the blocks to decide the "winner" because this lets > you know in advance your block's likelihood of winning a collision by > looking at how high or low its hash is, in which case you can publish > a weak block right away or withhold a strong one and do selfish > mining. A better approach to break ties between blocks A and B is to > see if H(A||B) < H(B||A). That way neither block holder can find out > in advance if their block is likely to win a collision. > In the DECOR protocol, I think selfish miners cannot get any advantage, because the blocks that loose the latency race will come back as uncles and get their reward share anyway. Maybe Ittay Eyal and Emin Gun Sirer can say more about this... Best regards, Sergio. ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
