From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WhOpE-0003iR-9K for bitcoin-development@lists.sourceforge.net; Mon, 05 May 2014 19:45:20 +0000 X-ACL-Warn: Received: from p3plsmtpa06-03.prod.phx3.secureserver.net ([173.201.192.104]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WhOpC-0006Oe-Sq for bitcoin-development@lists.sourceforge.net; Mon, 05 May 2014 19:45:20 +0000 Received: from [192.168.0.23] ([201.231.95.129]) by p3plsmtpa06-03.prod.phx3.secureserver.net with id yKlA1n00D2nUpUh01KlBqN; Mon, 05 May 2014 12:45:12 -0700 Message-ID: <5367EA43.1090308@certimix.com> Date: Mon, 05 May 2014 16:45:07 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Joseph Bonneau References: <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk> <20140423150555.GE19430@savin> <53638616.2030009@certimix.com> <536388F9.3040607@certimix.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [173.201.192.104 listed in list.dnswl.org] X-Headers-End: 1WhOpC-0006Oe-Sq Cc: bitcoin-research@lists.cs.princeton.edu, "bitcoin-development@lists.sourceforge.net" , =?UTF-8?B?RW1pbiBHw7xuIFNpcmVy?= , Ittay Eyal Subject: Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:45:20 -0000 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.