Ittay [ARCHIVE] on Nostr: 📅 Original date posted:2014-05-05 📝 Original message:As far as I understand, ...

📅 Original date posted:2014-05-05
📝 Original message: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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140505/4662568e/attachment.html>;