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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 40123267
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 14:28:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 706B18F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 14:28:30 +0000 (UTC)
Received: by ioii16 with SMTP id i16so55310626ioi.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 07:28:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=RBBlybTGnLt1xKeyYwZv8Is+AOcYYV+tBxY2XB8+DpM=;
b=CA1u07O7fJ4AfC3GhFrVwGc/LaFUYc/ZZHdm8UK5q5rsbNn21faTsi2q+VfNwOiBOq
LYwYY/GFHfdRtXJsW/K1wJSKCQn6tInNYfOlZeGj6NUX5TzyXQ5vy8jjXjccgQ3mYaW3
0P44H95EPkQ4gKVwkmY2widqLPC7AIyS/roObejdatX8IOERV2sqI1uGzwXcvtt5qMtR
6FtqCZvg0i/Hcsbyda5IK8812Xilnq/Av7CCl+qvplFEilQVB0Nvtc1ZoWROgxHgnNgf
uf6295w9GCtXewu4dqipn4dCSwmk75vqjCqBFZ+ZL4geqmAUfTqxfD1cFdJYuuhB7M8a
/CsA==
MIME-Version: 1.0
X-Received: by 10.107.3.33 with SMTP id 33mr11157207iod.132.1438266509940;
Thu, 30 Jul 2015 07:28:29 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 07:28:29 -0700 (PDT)
In-Reply-To: <CABsx9T1Wgf8u-ZKXmiRhQwdJNkDJg9RL_o2j2cWxP-6nKmxS2Q@mail.gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
<55B94FAD.7040205@mail.bihthai.net>
<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
<74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
<CAPg+sBjsQPUZEj0LFHBWuM4E+4SsUu4C9fcb7OJX4SC4+omvPQ@mail.gmail.com>
<CABsx9T1Wgf8u-ZKXmiRhQwdJNkDJg9RL_o2j2cWxP-6nKmxS2Q@mail.gmail.com>
Date: Thu, 30 Jul 2015 16:28:29 +0200
Message-ID: <CAPg+sBhRiiAAnmUc0HzW3=eXSNnYdAPAdi4eKN=+bdzGuo_X2w@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113ed3a46ae2c9051c1884af
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
temporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 14:28:31 -0000
--001a113ed3a46ae2c9051c1884af
Content-Type: text/plain; charset=UTF-8
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>> Let's scale the block size gradually over time, according to
>> technological growth.
>
>
> Yes, lets do that-- that is EXACTLY what BIP101 intends to do.
>
Oh come on. Immediately increasing to 8 MB while miners currently don't
even seem to bother validating blocks?
With the added belt&suspenders reality check of miners, who won't produce
> blocks too big for whatever technology they're using.
>
Or a future where miners are even more centralized than now, which avoids
all problems relay and propagation speed has?
> So what do you think the scalability road map should look like? Should we
> wait to hard fork until Blockstream Elements is ready for deploying on the
> main network, and then have One Grand Hardfork that introduces all the
> scalability work you guys have been working on (like Segregated Witness and
> Lightning)?
>
Lightning does not require a hard fork, except that larger blocks would be
very useful for its bulk settlements.
Or is the plan to avoid controversy by people voluntarily moving their
> bitcoin to a sidechain where all this scaling-up innovation happens?
>
As I have said a dozen times now: sidechains are a mechanism for
experimentation. Maybe through them we will discover technology that allows
better on-chain and/or off-chain scalability, but people moving their coins
to a sidechain has far worse security tradeoffs than just increasing the
Bitcoin blockchain.
No plan for how to scale up is the worst of all possible worlds, and the
> lack of a direction or plan(s) is my main objection to the current status
> quo.
>
Ok, here is a proposal I was working on. I'd like to have had more time,
but I agree a direction/plan are needed to align expectations for the
future: https://gist.github.com/sipa/c65665fc360ca7a176a6.
> And any plan that requires inventing brand-new technology is going to be
> riskier than scaling up what we already have and understand, which is why I
> think it is worthwhile to scale up what we have IN ADDITION TO working on
> great projects like Segregated Witness and Lightning.
>
And I think that the reason that so many people care about this suddenly is
because of a fear that somehow the current block size "won't be enough".
Bitcoin has utility at any block size, and perhaps more at some values for
it than others. Talking about "not enough" is acknowledging that we really
believe the block size should scale to demand, while it is the other way
around.
--
Pieter
--001a113ed3a46ae2c9051c1884af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen <span dir=
=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">g=
avinandresen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><span class=3D""><div class=3D"gmail_quote">On T=
hu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <span dir=3D"ltr"><<a href=3D=
"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let's scale the=
block size gradually over time, according to technological growth.</blockq=
uote></div><br></span>Yes, lets do that-- that is EXACTLY what BIP101 inten=
ds to do.</div></div></blockquote><div><br></div><div>Oh come on. Immediate=
ly increasing to 8 MB while miners currently don't even seem to bother =
validating blocks?<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div class=3D"gmail_extra">With the added belt&suspenders reality =
check of miners, who won't produce blocks too big for whatever technolo=
gy they're using.<br></div></div></blockquote><div><br></div><div>Or a =
future where miners are even more centralized than now, which avoids all pr=
oblems relay and propagation speed has? <br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">So what do you think the scalability road map should look =
like? Should we wait to hard fork until Blockstream Elements is ready for d=
eploying on the main network, and then have One Grand Hardfork that introdu=
ces all the scalability work you guys have been working on (like Segregated=
Witness and Lightning)?</div></div></blockquote><div><br></div><div>Lightn=
ing does not require a hard fork, except that larger blocks would be very u=
seful for its bulk settlements.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra">Or is the plan to avoid contro=
versy by people voluntarily moving their bitcoin to a sidechain where all t=
his scaling-up innovation happens?</div></div></blockquote><div><br></div><=
div>As I have said a dozen times now: sidechains are a mechanism for experi=
mentation. Maybe through them we will discover technology that allows bette=
r on-chain and/or off-chain scalability, but people moving their coins to a=
sidechain has far worse security tradeoffs than just increasing the Bitcoi=
n blockchain.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra">No plan for how to scale up is the worst of all =
possible worlds, and the lack of a direction or plan(s) is my main objectio=
n to the current status quo.<br></div></div></blockquote><div><br></div><di=
v>Ok, here is a proposal I was working on. I'd like to have had more ti=
me, but I agree a direction/plan are needed to align expectations for the f=
uture:=C2=A0 <a href=3D"https://gist.github.com/sipa/c65665fc360ca7a176a6">=
https://gist.github.com/sipa/c65665fc360ca7a176a6</a>.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"></div><=
div class=3D"gmail_extra"><div><br></div><div>And any plan that requires in=
venting brand-new technology is going to be riskier than scaling up what we=
already have and understand, which is why I think it is worthwhile to scal=
e up what we have IN ADDITION TO working on great projects like Segregated =
Witness and Lightning.</div></div></div></blockquote><div><br></div><div>An=
d I think that the reason that so many people care about this suddenly is b=
ecause of a fear that somehow the current block size "won't be eno=
ugh". Bitcoin has utility at any block size, and perhaps more at some =
values for it than others. Talking about "not enough" is acknowle=
dging that we really believe the block size should scale to demand, while i=
t is the other way around.<br><br></div><div>-- <br></div><div>Pieter<br><b=
r> </div></div></div></div>
--001a113ed3a46ae2c9051c1884af--
|
