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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <akaramaoun@gmail.com>) id 1YyXR2-0005Yo-7B
for bitcoin-development@lists.sourceforge.net;
Sat, 30 May 2015 03:27:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.172 as permitted sender)
client-ip=209.85.213.172; envelope-from=akaramaoun@gmail.com;
helo=mail-ig0-f172.google.com;
Received: from mail-ig0-f172.google.com ([209.85.213.172])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YyXR0-000671-AI
for bitcoin-development@lists.sourceforge.net;
Sat, 30 May 2015 03:27:44 +0000
Received: by igbpi8 with SMTP id pi8so28376963igb.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 29 May 2015 20:27:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.43.199 with SMTP id y7mr18295183ice.12.1432956456773;
Fri, 29 May 2015 20:27:36 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Fri, 29 May 2015 20:27:36 -0700 (PDT)
In-Reply-To: <COL402-EAS985F0C95920085B4CDDD93CDC80@phx.gbl>
References: <COL402-EAS985F0C95920085B4CDDD93CDC80@phx.gbl>
Date: Sat, 30 May 2015 03:27:36 +0000
X-Google-Sender-Auth: 5qvNaBuSdt9fcsxRbNODPxEuQ0Y
Message-ID: <CAL8tG=nfs+UQJt7zWMc=p1Rf8vDcwFRctpEOR-Z358vKnpphAA@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Raystonn <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=bcaec519694195aec30517442c8b
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
(akaramaoun[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: 1YyXR0-000671-AI
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extension
blocks) Re: Proposed alternatives to the 20MB stepfunction
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, 30 May 2015 03:27:44 -0000
--bcaec519694195aec30517442c8b
Content-Type: text/plain; charset=UTF-8
Hello Adam
First of all, thank you for inventing hashcash, which is basically what
bitcoin is!
Some people have said that my proposal, subject line "Scaling Bitcoin with
Subchains" is essentially the idea of blockchain extensions. Though, I
think there is quite a difference between what I propose and what you
propose. You want to add one optional 10 MB blockchain that synchronizes
with the 1 MB blockchain, while I want to add ten 1 MB
blockchains that each synchronize with the 1 MB chain (and you can
continue like that). I think, as long as we want to keep using blockchains
for our cryptocurrency, we will need a tree structure of blockchains in
order to scale for an arbitrary number of transactions. With just one 10 MB
blockchain, someone who wants to do the lower valued transactions will need
to validate all 10 MB, while with ten 1 MB chains, they can choose just the
chain or chains that are of interest to them. With a tree structure you get
O(a^(n-1)) MB of transactions in the network while each participant only
has to validate O(n) MB of transactions (a is just the number of children
chains per parent divided by 2, so 5 in the case of 10 children as I
described). With just one child chain, you don't get this scaling, and it
is pretty much equivalent to increasing the blocksize, though with a
soft-fork instead of a hard-fork.
I think the actual way that the blockchains interact can be still worked
out (Recently I was thinking of maybe creating a contract system or even a
decentralized market between chains). But still, everyone should agree that
you need this kind of tree structure. Even if you want to only run a pruned
node, the CPU usage and memory scales just as bad. The tree structure also
has good privacy and miner decentralization properties, as I can write
about later.
But another thing that I recommend is an "exit plan". What if we go with
some kind of soft fork and then in the future some better idea comes along?
Then we should have a way to reverse the soft fork. If people already have
coins tied up in sidechains, it can be problematic. So perhaps, in case
people want to later ditch the soft fork, nodes in the parent chain can
allow only old transactions inside the child chains to be accepted back up,
while new transactions are not recognized anymore. That way you can limit
the amount of useless transaction traffic that results in case we want
something else.
On Sat, May 30, 2015 at 1:36 AM, Raystonn <raystonn@hotmail.com> wrote:
> My fear now is too much unnecessary complexity. More complex means
> brittle code, but also fewer programmers working on this, which is a risk.
>
> We shouldn't delay forever until every potential solution has been
> explored. There's always going to be one more thing to explore.
> On 29 May 2015 5:16 pm, Gavin Andresen <gavinandresen@gmail.com> wrote:
>
> RE: soft-forking an "extension block":
>
> So... go for it, code it up. Implement it in the Bitcoin Core wallet.
>
> Then ask the various wallet developer how long it would take them to
> update their software to support something like this, and do some UI
> mockups of what the experience would look like for users.
>
> If there are two engineering solutions to a problem, one really simple,
> and one complex, why would you pick the complex one?
>
> Especially if the complex solution has all of the problems of the simple
> one (20MB extension blocks are just as "dangerous" as 20MB main blocks,
> yes? If not, why not?)
>
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--bcaec519694195aec30517442c8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>Hello Adam<br><br></div>First of =
all, thank you for inventing hashcash, which is basically what bitcoin is!<=
br><br></div>Some people have said that my proposal, subject line "Sca=
ling Bitcoin with Subchains" is essentially the idea of blockchain ext=
ensions. Though, I think there is quite a difference between what I propose=
and what you propose. You want to add one optional 10 MB blockchain that s=
ynchronizes with the 1 MB blockchain, while I want to add ten 1 MB<br></div=
>=C2=A0blockchains that each synchronize with the 1 MB chain (and you can c=
ontinue like that). I think, as long as we want to keep using blockchains f=
or our cryptocurrency, we will need a tree structure of blockchains in orde=
r to scale for an arbitrary number of transactions. With just one 10 MB blo=
ckchain, someone who wants to do the lower valued transactions will need to=
validate all 10 MB, while with ten 1 MB chains, they can choose just the c=
hain or chains that are of interest to them. With a tree structure you get =
O(a^(n-1)) MB of transactions in the network while each participant only ha=
s to validate O(n) MB of transactions (a is just the number of children cha=
ins per parent divided by 2, so 5 in the case of 10 children as I described=
). With just one child chain, you don't get this scaling, and it is pre=
tty much equivalent to increasing the blocksize, though with a soft-fork in=
stead of a hard-fork.<br><br></div>I think the actual way that the blockcha=
ins interact can be still worked out (Recently I was thinking of maybe crea=
ting a contract system or even a decentralized market between chains). But =
still, everyone should agree that you need this kind of tree structure. Eve=
n if you want to only run a pruned node, the CPU usage and memory scales ju=
st as bad. The tree structure also has good privacy and miner decentralizat=
ion properties, as I can write about later.<br><br></div>But another thing =
that I recommend is an "exit plan". What if we go with some kind =
of soft fork and then in the future some better idea comes along? Then we s=
hould have a way to reverse the soft fork. If people already have coins tie=
d up in sidechains, it can be problematic. So perhaps, in case people want =
to later ditch the soft fork, nodes in the parent chain can allow only old =
transactions inside the child chains to be accepted back up, while new tran=
sactions are not recognized anymore. That way you can limit the amount of u=
seless transaction traffic that results in case we want something else.<br>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, May=
30, 2015 at 1:36 AM, Raystonn <span dir=3D"ltr"><<a href=3D"mailto:rays=
tonn@hotmail.com" target=3D"_blank">raystonn@hotmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">My fear now is too muc=
h unnecessary complexity.=C2=A0 More complex means brittle code, but also f=
ewer programmers working on this, which is a risk.</p>
<p dir=3D"ltr">We shouldn't delay forever until every potential solutio=
n has been explored.=C2=A0 There's always going to be one more thing to=
explore.<br>
</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On 29 May 2015 5:16 pm, Gavin Andresen <<a hr=
ef=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail=
.com</a>> wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">RE: s=
oft-forking an "extension block":<div><br></div><div>So... go for=
it, code it up. Implement it in the Bitcoin Core wallet.</div><div><br></d=
iv><div>Then ask the various wallet developer how long it would take them t=
o update their software to support something like this, and do some UI mock=
ups of what the experience would look like for users.</div><div><br></div><=
div>If there are two engineering solutions to a problem, one really simple,=
and one complex, why would you pick the complex one?</div><div><br></div><=
div>Especially if the complex solution has all of the problems of the simpl=
e one (20MB extension blocks are just as "dangerous" as 20MB main=
blocks, yes? If not, why not?)</div><div><br></div><div><br></div><div>-- =
<br><div>--<br>Gavin Andresen<br></div>
</div></div>
</blockquote></div></div></div><br>----------------------------------------=
--------------------------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</d=
iv>
</div>
--bcaec519694195aec30517442c8b--
|
