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
|
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 <pieter.wuille@gmail.com>) id 1Z3maV-0001Zq-41
for bitcoin-development@lists.sourceforge.net;
Sat, 13 Jun 2015 14:39:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.169 as permitted sender)
client-ip=209.85.160.169; envelope-from=pieter.wuille@gmail.com;
helo=mail-yk0-f169.google.com;
Received: from mail-yk0-f169.google.com ([209.85.160.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z3maT-0000yV-Vr
for bitcoin-development@lists.sourceforge.net;
Sat, 13 Jun 2015 14:39:11 +0000
Received: by ykar6 with SMTP id r6so4149265yka.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 13 Jun 2015 07:39:04 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.129.131.214 with SMTP id t205mr24436888ywf.26.1434206344495;
Sat, 13 Jun 2015 07:39:04 -0700 (PDT)
Received: by 10.37.93.67 with HTTP; Sat, 13 Jun 2015 07:39:04 -0700 (PDT)
In-Reply-To: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
Date: Sat, 13 Jun 2015 16:39:04 +0200
Message-ID: <CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Andrew <onelineproof@gmail.com>
Content-Type: multipart/alternative; boundary=001a114f57c0b2c76c0518672fcc
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
(pieter.wuille[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: 1Z3maT-0000yV-Vr
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
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: Sat, 13 Jun 2015 14:39:11 -0000
--001a114f57c0b2c76c0518672fcc
Content-Type: text/plain; charset=UTF-8
On Wed, May 20, 2015 at 4:55 AM, Andrew <onelineproof@gmail.com> wrote:
> Hi
>
> I briefly mentioned something about this on the bitcoin-dev IRC room. In
> general, it seems experts (like sipa i.e. Pieter) are against using
> sidechains as a way of scaling. As I only have a high level understanding
> of the Bitcoin protocol, I cannot be sure if what I want to do is actually
> defined as a side chain, but let me just propose it, and please let me know
> whether it can work, and if not why not (I'm not scared of digging into
> more technical resources in order to fully understand). I do have a good
> academic/practical background for Bitcoin, and I'm ready to contribute code
> if needed (one of my contributions includes a paper wallet creator written
> in C).
>
>
In your proposal, transactions go to a chain based the addresses involved.
We can reasonably assume that different people's wallet will tend to be
distributed uniformly over several sidechains to hold their transactions
(if they're not, there is no scaling benefit anyway...). That means that
for an average transaction, you will need a cross-chain transfer in order
to get the money to the recipient (as their wallet will usually be
associated to a chain that is different from your own). Either you use an
atomic swap (which actually means you end up briefly with coins in the
destination chain, and require multiple transactions and a medium delay),
or you use the 2way peg transfer mechanism (which is very slow, and reduces
the security the recipient has to SPV).
Whatever you do, the result will be that most transactions are:
* Slower (a bit, or a lot, depending on what mechanism you use).
* More complex, with more failure modes.
* Require more and larger transactions (causing a total net extra load on
all verifiers together).
And either:
* Less secure (because you rely on a third party to do an atomic swap with,
or because of the 2 way peg transfer mechanism which has SPV security)
* Doesn't offer any scaling benefit (because the recipient needs to fully
validate both his own and the receiver chain).
In short, you have not added any scaling at all, or reduced the security of
the system significantly, as well as made it significantly less convenient
to use.
So no, sidechains are not a direct means for solving any of the scaling
problems Bitcoin has. What they offer is a mechanism for easier
experimentation, so that new technology can be built and tested without
needing to introduce a new currency first (with the related speculative and
network effect problems). That experimentation could eventually lead us to
discover mechanisms for better scaling, or for more scalability/security
tradeoffs (see for example the Witness Segregation that Elements Alpha has).
--
Pieter
--001a114f57c0b2c76c0518672fcc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, May 20, 2015 at 4:55 AM, Andrew <span dir=3D"ltr">=
<<a href=3D"mailto:onelineproof@gmail.com" target=3D"_blank">onelineproo=
f@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
<div><div><div><div><div><div>Hi<br><br></div>I briefly mentioned something=
about this on the bitcoin-dev IRC room. In general, it seems experts (like=
sipa i.e. Pieter) are against using sidechains as a way of scaling. As I o=
nly have a high level understanding of the Bitcoin protocol, I cannot be su=
re if what I want to do is actually defined as a side chain, but let me jus=
t propose it, and please let me know whether it can work, and if not why no=
t (I'm not scared of digging into more technical resources in order to =
fully understand). I do have a good academic/practical background for Bitco=
in, and I'm ready to contribute code if needed (one of my contributions=
includes a paper wallet creator written in C).<br><br></div></div></div></=
div></div></div></div></div></blockquote><div><br></div><div>In your propos=
al, transactions go to a chain based the addresses involved. We can reasona=
bly assume that different people's wallet will tend to be distributed u=
niformly over several sidechains to hold their transactions (if they're=
not, there is no scaling benefit anyway...). That means that for an averag=
e transaction, you will need a cross-chain transfer in order to get the mon=
ey to the recipient (as their wallet will usually be associated to a chain =
that is different from your own). Either you use an atomic swap (which actu=
ally means you end up briefly with coins in the destination chain, and requ=
ire multiple transactions and a medium delay), or you use the 2way peg tran=
sfer mechanism (which is very slow, and reduces the security the recipient =
has to SPV).<br><br></div><div>Whatever you do, the result will be that mos=
t transactions are:<br></div><div>* Slower (a bit, or a lot, depending on w=
hat mechanism you use).<br></div><div>* More complex, with more failure mod=
es.<br></div><div>* Require more and larger transactions (causing a total n=
et extra load on all verifiers together).<br></div><div><br></div><div>And =
either:<br></div><div>* Less secure (because you rely on a third party to d=
o an atomic swap with, or because of the 2 way peg transfer mechanism which=
has SPV security)<br></div><div>* Doesn't offer any scaling benefit (b=
ecause the recipient needs to fully validate both his own and the receiver =
chain).<br><br></div><div>In short, you have not added any scaling at all, =
or reduced the security of the system significantly, as well as made it sig=
nificantly less convenient to use.<br><br></div><div>So no, sidechains are =
not a direct means for solving any of the scaling problems Bitcoin has. Wha=
t they offer is a mechanism for easier experimentation, so that new technol=
ogy can be built and tested without needing to introduce a new currency fir=
st (with the related speculative and network effect problems). That experim=
entation could eventually lead us to discover mechanisms for better scaling=
, or for more scalability/security tradeoffs (see for example the Witness S=
egregation that Elements Alpha has).<br><br></div><div>-- <br></div><div>Pi=
eter<br><br></div></div></div></div>
--001a114f57c0b2c76c0518672fcc--
|
