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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1XlGUs-0004TB-5d
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Nov 2014 12:12:34 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XlGUq-0000VP-Nt
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Nov 2014 12:12:34 +0000
Received: by mail-wi0-f177.google.com with SMTP id ex7so6176821wid.16
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Nov 2014 04:12:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.187.164 with SMTP id ft4mr46905960wjc.76.1415016746520;
Mon, 03 Nov 2014 04:12:26 -0800 (PST)
Received: by 10.27.203.138 with HTTP; Mon, 3 Nov 2014 04:12:26 -0800 (PST)
In-Reply-To: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
References: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
Date: Mon, 3 Nov 2014 14:12:26 +0200
Message-ID: <CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b874b268715540506f34259
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(alex.mizrahi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XlGUq-0000VP-Nt
Subject: Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there
a way to do bitcoin-staging?)
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, 03 Nov 2014 12:12:34 -0000
--047d7b874b268715540506f34259
Content-Type: text/plain; charset=UTF-8
> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf
Haven't seen any material discussion of this paper in this mailing list, so
I'll start.
(Otherwise, I've seen Peter Todd's reaction on reddit.)
This paper fails to demonstrate that sidechains are anything more than a
wishful thinking.
It can be distilled down to this:
"We want such and such features, hence we'll use DMMS, the same thing
Bitcoin uses, thus it will be secure!"
Um, no.
Alt-coins also use DMMS, but aren't as secure as Bitcoin.
So DMMS does not work by itself, it is a mechanism to secure a blockchain
using economic incentives.
The sidechains paper does not mention this, as far as I can tell.
In my opinion, this is not acceptable. If you're making a proposal, you
need to describe what conditions are required for it to work.
Authors are clearly aware of the problem and mention it in section 6
"Future directions" 6.1. "Hashpower attack resistance".
The problem is they do not make it clear that the proposal just makes no
sense until this is solved.
In the discussions on reddit I've noticed that pretty much everybody
believes that release of sidechains paper implies that the proposal is
complete and now we are just waiting the implementation.
It doesn't help that the paper itself tries to sweep the problem under the
rug and has misleading statements.
Particularly, I'm talking about section "4.2. Fraudulent transfers":
"Reorganisations of arbitrary depth are in principle possible, which could
allow an attacker to
completely transfer coins between sidechains before causing a
reorganisation longer than the contest
period on the sending chain to undo its half of the transfer. ... If the
attacker is allowed to return the transferred coins to the original
chain, he would increase the number of coins in his possession at the
expense of other users of the sidechain.
Before discussing how to handle this, we observe that this risk can be made
arbitrarily small by
simply increasing the contest period for transfers."
Wow, really? Is this risk stochastic?
The first sentence implies that attacker is able to cause a reorganization
of an arbitrary depth, but the rest of the section implies that
reorganizations are a naturally occurring phenomenon.
All in all, I find this paper really disappointing. It's going to be
influential (9 co-authors, many of which are regarded as Bitcoin core
developers, must be good!) and hyped, and thus might focus research on an
area which is fundamentally flawed.
--047d7b874b268715540506f34259
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">For those following this thread, we have now written a pap=
er<br>
describing the side-chains, 2-way pegs and compact SPV proofs.<br>
(With additional authors Andrew Poelstra & Andrew Miller).<br>
<br>
<a href=3D"http://blockstream.com/sidechains.pdf" target=3D"_blank">http://=
blockstream.com/sidechains.pdf</a></blockquote><div><br></div><div>Haven=
9;t seen any material discussion of this paper in this mailing list, so I&#=
39;ll start.=C2=A0</div><div>(Otherwise, I've seen Peter Todd's rea=
ction on reddit.)</div><div><br></div><div>This paper fails to demonstrate =
that sidechains are anything more than a wishful thinking.</div><div>It can=
be distilled down to this:</div><div>"We want such and such features,=
hence we'll use DMMS, the same thing Bitcoin uses, thus it will be sec=
ure!"</div><div>Um, no.=C2=A0</div><div>Alt-coins also use DMMS, but a=
ren't as secure as Bitcoin.</div><div><br></div><div>So DMMS does not w=
ork by itself, it is a mechanism to secure a blockchain using economic ince=
ntives.</div><div>The sidechains paper does not mention this, as far as I c=
an tell.</div><div><br></div><div>In my opinion, this is not acceptable. If=
you're making a proposal, you need to describe what conditions are req=
uired for it to work.</div><div><br></div><div>Authors are clearly aware of=
the problem and mention it in section 6 "Future directions" 6.1.=
"Hashpower attack resistance".</div><div>The problem is they do =
not make it clear that the proposal just makes no sense until this is solve=
d.</div><div><br></div><div>In the discussions on reddit I've noticed t=
hat pretty much everybody believes that release of sidechains paper implies=
that the proposal is complete and now we are just waiting the implementati=
on.</div><div><br></div><div>It doesn't help that the paper itself trie=
s to sweep the problem under the rug and has misleading statements.</div><d=
iv>Particularly, I'm talking about section "4.2. Fraudulent transf=
ers":</div><div><br></div><div>"Reorganisations of arbitrary dept=
h are in principle possible, which could allow an attacker to</div><div>com=
pletely transfer coins between sidechains before causing a reorganisation l=
onger than the contest</div><div>period on the sending chain to undo its ha=
lf of the transfer. ...=C2=A0If the attacker is allowed to return the trans=
ferred coins to =C2=A0the original</div><div>chain, he would increase the n=
umber of coins in his possession at the expense of other users of the sidec=
hain.</div><div>Before discussing how to handle this, we observe that this =
risk can be made arbitrarily small by</div><div>simply increasing the conte=
st period for transfers."</div><div><br></div><div>Wow, really? Is thi=
s risk stochastic?</div><div><br></div><div>The first sentence implies that=
attacker is able to cause a reorganization of an arbitrary depth, but the =
rest of the section implies that reorganizations are a naturally occurring =
phenomenon.</div><div><br></div><div>All in all, I find this paper really d=
isappointing. It's going to be influential (9 co-authors, many of which=
are regarded as Bitcoin core developers, must be good!) and hyped, and thu=
s might focus research on an area which is fundamentally flawed.</div><div>=
<br></div><div><br></div></div></div></div>
--047d7b874b268715540506f34259--
|
