public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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.edu \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=bitcoin-research@lists.cs.princeton.edu \
    --cc=egs@systems.cs.cornell.edu \
    --cc=jbonneau@princeton.edu \
    --cc=sergiolerner@certimix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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