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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1XlInk-0003Yt-SM
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Nov 2014 14:40:13 +0000
Received: from mail-wi0-f173.google.com ([209.85.212.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XlInj-0006eU-34
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Nov 2014 14:40:12 +0000
Received: by mail-wi0-f173.google.com with SMTP id n3so6646582wiv.12
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Nov 2014 06:40:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=9j6Tfb2SHiqCFg2kLixrEoz+fdmcoI+DrKk3UnNLPsQ=;
b=hMNrOVTqrnKFE75v3I+CIXvSHqsu9Pm9tPOStzuDHBINyll4HMWKjXrlWb6vZUSYDw
IZuOYmW91qvBImcXzTSrxjHnG7bOtIZ7LTmcKjFshZLLB6aB1AFCmtEkNzcm4jrv/BQy
jjIAzHuihMUtjTcA3OAZt0QRkccQPE7Ko/Yw0yU/a1680wA9RDuzdGOisuffQI6ADokD
bDe7F8LH9I1JUKXcAjhX2nDjeK0Rwjy8tlr5wWqtFfGHlMNWYlTGIhecL7XAIuewh/nv
CUwvKV1bU9bCktyK4S+pc5Y71ST/l5HCBRW+MDQqqtpMdTvLjxzRPvgCRnA3FS0X/Srg
S3Yw==
X-Gm-Message-State: ALoCoQljE9lY8I2gHPcTvT0NrSSOD1ZP+22bwYEHncYJBf6z/HY7xeRzRNHeow5im6sND6Elyoa4
MIME-Version: 1.0
X-Received: by 10.180.98.170 with SMTP id ej10mr7091597wib.74.1415024089578;
Mon, 03 Nov 2014 06:14:49 -0800 (PST)
Received: by 10.194.45.5 with HTTP; Mon, 3 Nov 2014 06:14:49 -0800 (PST)
X-Originating-IP: [85.59.57.28]
In-Reply-To: <CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com>
References: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
<CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com>
Date: Mon, 3 Nov 2014 15:14:49 +0100
Message-ID: <CABm2gDqXkAKoNKwvznPfKKEq+c-F+Co7kudqQa2wHjcCU3iysQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1XlInj-0006eU-34
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
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 14:40:14 -0000
On Mon, Nov 3, 2014 at 1:12 PM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
>
>> 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.
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.[...]"
Ignoring altrustic miners, the irreversibility of a DMMS chain
obviously depends on the rewards received by miners on that chain.
Nobody is claiming that sidechains will be "as secure bitcoin", any 2
way pegged assets is always "more secure" (probably too vague of a
term in this context) in its original chain.
> 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.
Since all seigniorage from Bitcoin's initial distribution is spent on
mining subsidies for the main chain, it is not available to subsidize
sidechains too. 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 (is not always clear to
me if they believe that won't be enough for sidechains or also for
bitcoin when the subsidies are gone), we included this section with
other ideas we have explored to further. Some of them, like
"time-shifted fees" could be interesting for Bitcoin itself in the
future.
> 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.
Reorganizations are both a naturally occurring phenomenon and
something that an attacker may cause to revert history.
Section "11. Calculations" of the Bitcoin whitepaper gives you this
formula (in C code):
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
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."
In this case, the contest period determines z, the number of blocks
the attacker has to catch up from the honest chain.
So the longer the contest period is, the harder it is to succeed with
a fraudulent transfer.
For example, if a given sidechain chooses 52560 as the contest period
(1 year assuming 10 min blocks), it will be very hard for an attacker
to produce a fake alternative longest-than-the-last-year-of-history
fork to steal coins.
A sidechain with such an extreme contest period would probably not be
very practical though, since honest users would have to wait more than
a year to complete transfers from the parent chain to the sidechain
and viceversa.
I hope this clarifies our assumptions.
|
