From: Sergio Lerner <sergiolerner@certimix•com>
To: Joseph Bonneau <jbonneau@princeton•edu>
Cc: bitcoin-research@lists•cs.princeton.edu,
"bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>,
"Emin Gün Sirer" <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
Date: Mon, 05 May 2014 16:45:07 -0300 [thread overview]
Message-ID: <5367EA43.1090308@certimix.com> (raw)
In-Reply-To: <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
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.
next prev parent reply other threads:[~2014-05-05 19:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
2014-04-21 1:30 ` [Bitcoin-development] Economics of information propagation Jonathan Levin
2014-04-21 3:58 ` Mark Friedenbach
2014-04-21 4:06 ` Peter Todd
2014-04-21 4:44 ` Daniel Lidstrom
2014-04-21 5:46 ` Daniel Lidstrom
2014-04-21 11:34 ` Tier Nolan
2014-04-21 13:04 ` Jorge Timón
2014-04-21 15:40 ` Ashley Holman
2014-04-21 15:58 ` Alan Reiner
2014-04-21 16:00 ` Mark Friedenbach
2014-04-21 16:22 ` Paul Lyon
2014-04-21 16:38 ` Mark Friedenbach
2014-04-21 16:39 ` Mike Hearn
2014-04-21 16:45 ` Jonathan Levin
2014-04-23 2:54 ` Tom Harding
2014-04-23 15:05 ` Peter Todd
[not found] ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
2014-05-02 11:48 ` [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem Sergio Lerner
2014-05-02 12:00 ` Sergio Lerner
[not found] ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
2014-05-05 19:45 ` Sergio Lerner [this message]
2014-05-05 20:27 ` Ittay
2014-05-07 4:31 ` [Bitcoin-development] DECOR+ Better block selection rule Sergio Lerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5367EA43.1090308@certimix.com \
--to=sergiolerner@certimix$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-research@lists$(echo .)cs.princeton.edu \
--cc=egs@systems$(echo .)cs.cornell.edu \
--cc=ittay.eyal@cornell$(echo .)edu \
--cc=jbonneau@princeton$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox