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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1XlK4o-0008IX-RN
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Nov 2014 16:01:54 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.180 as permitted sender)
client-ip=209.85.212.180; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wi0-f180.google.com;
Received: from mail-wi0-f180.google.com ([209.85.212.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XlK4m-0000vX-SX
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Nov 2014 16:01:54 +0000
Received: by mail-wi0-f180.google.com with SMTP id hi2so6822719wib.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Nov 2014 08:01:46 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.90.175 with SMTP id bx15mr48104808wjb.25.1415030506641;
Mon, 03 Nov 2014 08:01:46 -0800 (PST)
Received: by 10.27.203.138 with HTTP; Mon, 3 Nov 2014 08:01:46 -0800 (PST)
In-Reply-To: <CABm2gDqXkAKoNKwvznPfKKEq+c-F+Co7kudqQa2wHjcCU3iysQ@mail.gmail.com>
References: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
<CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com>
<CABm2gDqXkAKoNKwvznPfKKEq+c-F+Co7kudqQa2wHjcCU3iysQ@mail.gmail.com>
Date: Mon, 3 Nov 2014 18:01:46 +0200
Message-ID: <CAE28kURz3smtwDvVuPQDFxosqB2tRNWiM3bf=BeLcjhJ2eiR5A@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7bfd011eb1dd720506f676c6
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: 1XlK4m-0000vX-SX
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 16:01:55 -0000
--047d7bfd011eb1dd720506f676c6
Content-Type: text/plain; charset=UTF-8
> From the introduction "[...]Because signers prove computational work,
> rather than proving secret knowledge as
> is typical for digital signatures, we refer to them as miners. To
> achieve stable consensus on the
> blockchain history, economic incentives are provided where miners are
> rewarded with fees and
> subsidies in the form of coins that are valuable only if the miners
> form a shared valid history,
> incentivising them to behave honestly.[...]"
>
This isn't applicable in case of sidechains: anybody with sufficient
hashpower will be able to unlock a locked coin on the parent chain by
producing an SPV proof.
"Only if the miners form a shared valid history" isn't a requirement here,
as miner will get bitcoins which aren't in any way connect to sidechain he
have wrecked. Thus there is no incentive to behave honestly.
Thus sidechains, in principle, reward their miners
>
with the same Bitcoin will use in the future: only transaction fees.
> Since some people claim that won't be enough
Whether it is enough depends on a variety of factors, including existence
of other chains miner can mine.
You cannot assume that it is the same situation as with a simple
single-chain model.
E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining
bitcoins as usual, and in parallel work on an SPV proof to claim these 1000
BTC. (I assume that merged-mining is allowed.)
In this case the amount of fees which miners could collect by honest mining
on the sidechain is irrelevant, as long as it is smaller than 1000 BTC.
This is quite different from attacks which can be performed on vanilla
Bitcoin (see below), so I don't think you can say that the security model
is the same.
Also says "Given our assumption that p > q, the probability drops
>
exponentially as the number of blocks the
> attacker has to catch up with increases."
>
Yes, but that doesn't apply to reorganizations which attacker might cause
intentionally.
Hence I think it was disingenuous to include these two very different
treats into one section:
it sounds like you claim that attacker-induced reorganizations are
unlikely, while it isn't the case.
So the longer the contest period is, the harder it is to succeed with
> a fraudulent transfer.
>
Yes, but "harder" isn't same as "unlikely".
Another problem with this section is that it only mentions reorganizations.
But a fraudulent transfer can happen without a reorganization, as an
attacker can produce an SPV proof which is totally fake. So this is not
similar to double-spending, attacker doesn't need to own coins to perform
an attack.
> I hope this clarifies our assumptions.
>
Yep, thanks. It looks like you assume that sidechain security will be
similar to Bitcoin security in the long term.
Now quite the assumptions I've been looking for, but OK...
I'm sorry for the harsh tone, but I just find it hilarious that people who
explained that proof-of-stake is not going to work because an attacker
might collect everybody's past signing keys to rewrite the whole history
(I'm referring to this: https://download.wpsoftware.net/bitcoin/pos.pdf )
didn't bother to mention that miners can collude to wreck a sidechain and
get an awesome reward, basically for free.
something something the mote in thy brother's eye something something
--047d7bfd011eb1dd720506f676c6
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"><div=
>=C2=A0</div><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;padding-left:1ex"><span>
</span>From the introduction "[...]Because signers prove computational=
work,<br>
rather than proving secret knowledge as<br>
is typical for digital signatures, we refer to them as miners. To<br>
achieve stable consensus on the<br>
blockchain history, economic incentives are provided where miners are<br>
rewarded with fees and<br>
subsidies in the form of coins that are valuable only if the miners<br>
form a shared valid history,<br>
incentivising them to behave honestly.[...]"<br></blockquote><div><br>=
</div><div>This isn't applicable in case of sidechains: anybody with su=
fficient hashpower will be able to unlock a locked coin on the parent chain=
by producing an SPV proof.</div><div>"Only if the miners form a share=
d valid history" isn't a requirement here, as miner will get bitco=
ins which aren't in any way connect to sidechain he have wrecked.=C2=A0=
Thus there is no incentive to behave honestly.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">Thus sidechains, in principle, reward their miners<br></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
with the same Bitcoin will use in the future: only transaction fees.<br>
Since some people claim that won't be enough</blockquote><div><br></div=
><div>Whether it is enough depends on a variety of factors, including exist=
ence of other chains miner can mine.</div><div>You cannot assume that it is=
the same situation as with a simple single-chain model.</div><div><br></di=
v><div>E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep min=
ing bitcoins as usual, and in parallel work on an SPV proof to claim these =
1000 BTC. (I assume that merged-mining is allowed.)</div><div>In this case =
the amount of fees which miners could collect by honest mining on the sidec=
hain is irrelevant, as long as it is smaller than 1000 BTC.</div><div><br><=
/div><div>This is quite different from attacks which can be performed on va=
nilla Bitcoin (see below), so I don't think you can say that the securi=
ty model is the same.</div><div><br></div><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;padding-left:1ex">Also says "=
Given our assumption that p > q, the probability drops<br></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">
exponentially as the number of blocks the<br>
attacker has to catch up with increases."<br></blockquote><div><br></d=
iv><div>Yes, but that doesn't apply to reorganizations which attacker m=
ight cause intentionally.</div><div>Hence I think it was disingenuous to in=
clude these two very different treats into one section:</div><div>it sounds=
like you claim that attacker-induced reorganizations are unlikely, while i=
t isn't the case.</div><div><br></div><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;padding-left:1ex">So the longer th=
e contest period is, the harder it is to succeed with<br>
a fraudulent transfer.<br></blockquote><div><br></div><div>Yes, but "h=
arder" isn't same as "unlikely".</div><div><br></div><di=
v>Another problem with this section is that it only mentions reorganization=
s.</div><div>But a fraudulent transfer can happen without a reorganization,=
as an attacker can produce an SPV proof which is totally fake. So this is =
not similar to double-spending, attacker doesn't need to own coins to p=
erform an attack.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">I hope this clarif=
ies our assumptions.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">Yep, thanks. It loo=
ks like you assume that sidechain security will be similar to Bitcoin secur=
ity in the long term.</div><div class=3D"gmail_extra">Now quite the assumpt=
ions I've been looking for, but OK...</div><div class=3D"gmail_extra"><=
br></div><div class=3D"gmail_extra">I'm sorry for the harsh tone, but I=
just find it hilarious that people who explained that proof-of-stake is no=
t going to work because an attacker might collect everybody's past sign=
ing keys to rewrite the whole history</div><div class=3D"gmail_extra">(I=
9;m referring to this:=C2=A0<a href=3D"https://download.wpsoftware.net/bitc=
oin/pos.pdf">https://download.wpsoftware.net/bitcoin/pos.pdf</a> )=C2=A0</d=
iv><div class=3D"gmail_extra">didn't bother to mention that miners can =
collude to wreck a sidechain and get an awesome reward, basically for free.=
</div><div class=3D"gmail_extra">something something the mote in thy brothe=
r's eye something something</div></div>
--047d7bfd011eb1dd720506f676c6--
|
