1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
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.
|
