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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
Return-Path: <stanga@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 215E7412
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 15:10:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com
[209.85.214.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A72C1E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 15:10:12 +0000 (UTC)
Received: by obbda8 with SMTP id da8so67644131obb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2015 08:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc:content-type;
bh=WpFItliP7Is2sj4jrrg+fi8A7DYeCI694UdNXaMWJpE=;
b=X5ece6wuf+hDm77hp1GYoKRXZSWII0zdPfisVhyUgfEnIsr5avDLOUDM5y+tQTYv4y
sDB9vk7ZCyjyiPhewmxA4nKGIeJOv/ynGWH9japphx+3M66oZNAP4U7DR9qPwHo+z5oW
UeEt7k/gHNEH5jrKAbvWyQUtv/MGaIRg6KnzXWJ53P7osMvUJfZFtjBn8rN4+GC9sWRH
wz+JHJNCTcnJx8yILibIwKZ24TeW+toAq/fMUx0nv751rtjCr9ddEbKleB3VvFw7fpLa
UMhoyuj36/YCJoyH60ZXu16sc2lx/RvyST1sgJ9qiYwZYdgvD9sXecuTLRqFbfvy1HAD
BenA==
X-Received: by 10.60.124.226 with SMTP id ml2mr5290209oeb.27.1444921811953;
Thu, 15 Oct 2015 08:10:11 -0700 (PDT)
MIME-Version: 1.0
Sender: stanga@gmail.com
Received: by 10.182.104.164 with HTTP; Thu, 15 Oct 2015 08:09:52 -0700 (PDT)
In-Reply-To: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com>
References: <CAPkFh0viwmkUvjo4Qj50TNnkA5kG3z-3dLGExjkmDacE4E49Ow@mail.gmail.com>
<CABaSBaxWAsEG71FTy4SrVu94BXokeozmJ80tjsNU8ERpTfFaFA@mail.gmail.com>
<CABT1wW=xqShMGU0+eDiNyNkr-77fQ_HnyKL87C6iGL-xq8BYVw@mail.gmail.com>
<28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com>
From: Ittay <ittay.eyal@cornell.edu>
Date: Thu, 15 Oct 2015 11:09:52 -0400
X-Google-Sender-Auth: fNQbPuisxGKXkVVrq2u1P2jKAy0
Message-ID: <CABT1wWm0QXjGAXgrBMT7w+25kcsEJnP8JZ5RSpuk3aefX45+wQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=047d7b414eee546dcc0522261347
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Ittay <ittay.eyal@cornell.edu>,
Ittay via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 15:10:14 -0000
--047d7b414eee546dcc0522261347
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks, Matt. Response inline.
On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> That conversation missed a second issue. Namely that there is no way to
> punish people if there is a double spend in a micro block that happens in
> key block which reorg'd away the first transaction. eg one miner mines a
> transaction in a micro block, another miner (either by not having seen th=
e
> first yet, or being malicious - potentially the same miner) mines a key
> block which reorgs away the first micro block and then, in their first
> micro block, mines a double spend. This can happen at any time, so you en=
d
> up having to fall back to regular full blocks for confirmation times :(.
>
If NG is to be used efficiently, microblocks are going to be very frequent,
and so such forks should occur at almost every key-block publication. Short
reorgs as you described are the norm. A user should wait before accepting a
transaction to make sure there was no key-block she missed. The wait time
is chosen according to the network propagation delay (+as much slack as the
user feels necessary). This is similar to the situation in Bitcoin when you
receive a block. To be confident that you have one confirmation you should
wait for the propagation time of the network to make sure there is no
branch you missed.
As for the malicious case: the attacker has to win the key-block, have the
to-be-inverted transaction in the previous epoch, and withhold his
key-block for a while. That being said, indeed our fraud proof scheme
doesn't catch such an event, as it is indistinguishable from benign
behavior.
> Also, Greg Slepak brought up a good point on twitter at
> https://twitter.com/taoeffect/status/654358023138209792. Noting that this
> model means users could no longer pick transactions in a mining pool whic=
h
> was set up in such a way (it could be tweaked to do so with separate
> rewards and pubkeys, but now the user can commit fraud at a much lower co=
st
> - their own pool reward, not the block's total reward).
>
Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
Do you perceive this as a significant practical issue?
>
> On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail.com> wrote:
>>
>>> On Wed, Oct 14, 2015 at 1:02 PM, Emin G=C3=BCn Sirer
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > while the whitepaper has all the nitty gritty details:
>>> > http://arxiv.org/abs/1510.02037
>>>
>>> Taking reward compensation back by fraud proofs is not enough to fix
>>> the problems associated with double spending (such as, everyone has to
>>> wait for the "real" confirmations instead of the "possibly
>>> double-spend" confirmations). Some of this was discussed in -wizards
>>> recently:
>>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>>
>>
>> Fraud proof removes all the attacker's revenue. It's like the attacker
>> sacrifices an entire block for double spending in the current system. I
>> think Luke-Jr got it right at that discussion.
>>
>> Best,
>> Ittay
>>
>> ------------------------------
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
--047d7b414eee546dcc0522261347
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks, Matt. Response inline.=C2=A0<br><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Wed, Oct 14, 2015 at 2:57 PM, Ma=
tt Corallo <span dir=3D"ltr"><<a href=3D"mailto:lf-lists@mattcorallo.com=
" target=3D"_blank">lf-lists@mattcorallo.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div>That conversation missed a second issue. Nam=
ely that there is no way to punish people if there is a double spend in a m=
icro block that happens in key block which reorg'd away the first trans=
action. eg one miner mines a transaction in a micro block, another miner (e=
ither by not having seen the first yet, or being malicious - potentially th=
e same miner) mines a key block which reorgs away the first micro block and=
then, in their first micro block, mines a double spend. This can happen at=
any time, so you end up having to fall back to regular full blocks for con=
firmation times :(.<br></div></blockquote><div><br></div><div>If NG is to b=
e used efficiently, microblocks are going to be very frequent, and so such =
forks should occur at almost every key-block publication. Short reorgs as y=
ou described are the norm. A user should wait before accepting a transactio=
n to make sure there was no key-block she missed. The wait time is chosen a=
ccording to the network propagation delay (+as much slack as the user feels=
necessary). This is similar to the situation in Bitcoin when you receive a=
block. To be confident that you have one confirmation you should wait for =
the propagation time of the network to make sure there is no branch you mis=
sed.=C2=A0</div><div><br></div><div>As for the malicious case: the attacker=
has to win the key-block, have the to-be-inverted transaction in the previ=
ous epoch, and withhold his key-block for a while. That being said, indeed =
our fraud proof scheme doesn't catch such an event, as it is indistingu=
ishable from benign behavior.=C2=A0</div><div>=C2=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div>Also, Greg Slepak brought up a good point on twitter=
at <a href=3D"https://twitter.com/taoeffect/status/654358023138209792" tar=
get=3D"_blank">https://twitter.com/taoeffect/status/654358023138209792</a>.=
Noting that this model means users could no longer pick transactions in a =
mining pool which was set up in such a way (it could be tweaked to do so wi=
th separate rewards and pubkeys, but now the user can commit fraud at a muc=
h lower cost - their own pool reward, not the block's total reward).<br=
></div></blockquote><div><br></div><div>Agreed x3: This is a good point, it=
is correct, and the tweak is dangerous.=C2=A0</div><div>Do you perceive th=
is as a significant practical issue?=C2=A0</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div><br><div class=3D"gmail_quote"><div><div>On Octob=
er 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:</div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div><div>
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <span dir=3D"ltr"><<a href=
=3D"mailto:kanzure@gmail.com" target=3D"_blank">kanzure@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Oct 14, 2015 a=
t 1:02 PM, Emin G=C3=BCn Sirer<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> while the whitepaper has all the nitty gritty details:<br>
>=C2=A0 =C2=A0 =C2=A0 <a href=3D"http://arxiv.org/abs/1510.02037" rel=3D=
"noreferrer" target=3D"_blank">http://arxiv.org/abs/1510.02037</a><br>
<br>
</span>Taking reward compensation back by fraud proofs is not enough to fix=
<br>
the problems associated with double spending (such as, everyone has to<br>
wait for the "real" confirmations instead of the "possibly<b=
r>
double-spend" confirmations). Some of this was discussed in -wizards<b=
r>
recently:<br>
<a href=3D"http://gnusha.org/bitcoin-wizards/2015-09-19.log" rel=3D"norefer=
rer" target=3D"_blank">http://gnusha.org/bitcoin-wizards/2015-09-19.log</a>=
</blockquote><div><br></div><div>Fraud proof removes all the attacker's=
revenue. It's like the attacker sacrifices an entire block for double =
spending in the current system. I think Luke-Jr got it right at that discus=
sion.=C2=A0</div><div><br></div><div>Best,=C2=A0</div></div></div><div clas=
s=3D"gmail_extra">Ittay=C2=A0</div><div class=3D"gmail_extra"><br></div></d=
iv>
<p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000=
"></p></div></div><span><pre><hr><br>bitcoin-dev mailing list<br><a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a><br><a href=3D"https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfou=
ndation.org/mailman/listinfo/bitcoin-dev</a><br></pre></span></blockquote><=
/div></div></blockquote></div><br></div></div>
--047d7b414eee546dcc0522261347--
|
