From: Ittay <ittay.eyal@cornell•edu>
To: Sergio Lerner <sergiolerner@certimix•com>
Cc: bitcoin-research@lists•cs.princeton.edu,
"bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>,
"Joseph Bonneau" <jbonneau@princeton•edu>,
"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, 5 May 2014 16:27:08 -0400 [thread overview]
Message-ID: <CABT1wWkwLh8GVgE_0jgCJgm+rMwdKNMiVtSDQf28H8af0hci+w@mail.gmail.com> (raw)
In-Reply-To: <5367EA43.1090308@certimix.com>
[-- Attachment #1: Type: text/plain, Size: 3640 bytes --]
As far as I understand, the incentives Sergio suggests would work. So
we can assume that the pruned uncle blocks would still win their creators
at least partial revenue.
As for selfish mining - I'm not sure how GHOST affects it. I don't think it
does. The selfish miners just care about heaviest subtree rather than
longest chain. DECOR changes revenue collection significantly, so it
certainly affects selfish mining. I believe it changes the threshold at
which
selfish mining is profitable, but doesn't deter selfish mining completely:
Selfish miners can still cause others to reduce their revenue by having
them work on older blocks.
Ittay
On Mon, May 5, 2014 at 3:45 PM, Sergio Lerner <sergiolerner@certimix•com>wrote:
>
> 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.
>
[-- Attachment #2: Type: text/html, Size: 4491 bytes --]
next prev parent reply other threads:[~2014-05-05 20:27 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
2014-05-05 20:27 ` Ittay [this message]
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=CABT1wWkwLh8GVgE_0jgCJgm+rMwdKNMiVtSDQf28H8af0hci+w@mail.gmail.com \
--to=ittay.eyal@cornell$(echo .)edu \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-research@lists$(echo .)cs.princeton.edu \
--cc=egs@systems$(echo .)cs.cornell.edu \
--cc=jbonneau@princeton$(echo .)edu \
--cc=sergiolerner@certimix$(echo .)com \
/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