diff options
| author | Sergio Lerner <sergiolerner@certimix.com> | 2014-05-05 16:45:07 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-05-05 19:45:20 +0000 |
| commit | ea4674ae98c66759dce9d0c01fb7a7b99ade56e5 (patch) | |
| tree | 6c53dd17b53c1a4671a9dd25a116e50c5df229dc | |
| parent | 49fce948adb5e080f0fa4b79a80bdd0019178d5e (diff) | |
| download | pi-bitcoindev-ea4674ae98c66759dce9d0c01fb7a7b99ade56e5.tar.gz pi-bitcoindev-ea4674ae98c66759dce9d0c01fb7a7b99ade56e5.zip | |
Re: [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem
| -rw-r--r-- | 49/7807bec596438f6b0cbec23b5d9189ae8237e9 | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/49/7807bec596438f6b0cbec23b5d9189ae8237e9 b/49/7807bec596438f6b0cbec23b5d9189ae8237e9 new file mode 100644 index 000000000..2d576b150 --- /dev/null +++ b/49/7807bec596438f6b0cbec23b5d9189ae8237e9 @@ -0,0 +1,113 @@ +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 <sergiolerner@certimix.com>) 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 <sergiolerner@certimix.com> +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 <jbonneau@princeton.edu> +References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net> + <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk> + <20140423150555.GE19430@savin> + <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com> + <53638616.2030009@certimix.com> <536388F9.3040607@certimix.com> + <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com> +In-Reply-To: <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com> +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" + <bitcoin-development@lists.sourceforge.net>, + =?UTF-8?B?RW1pbiBHw7xuIFNpcmVy?= <egs@systems.cs.cornell.edu>, + Ittay Eyal <ittay.eyal@cornell.edu> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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. + + |