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
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1YzPu6-0007nm-5O
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 13:37:22 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.179 as permitted sender)
client-ip=209.85.217.179; envelope-from=gavinandresen@gmail.com;
helo=mail-lb0-f179.google.com;
Received: from mail-lb0-f179.google.com ([209.85.217.179])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzPu2-00004y-7A
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 13:37:22 +0000
Received: by lbbqq2 with SMTP id qq2so84470322lbb.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 01 Jun 2015 06:37:11 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.199.133 with SMTP id jk5mr21580820lbc.32.1433165831781;
Mon, 01 Jun 2015 06:37:11 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Mon, 1 Jun 2015 06:37:11 -0700 (PDT)
In-Reply-To: <CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com>
References: <CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com>
Date: Mon, 1 Jun 2015 09:37:11 -0400
Message-ID: <CABsx9T2D_yde6ZCH0tib6kxBfOgf-3BZDcEx4zsiqrTsA=Nvzw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?UTF-8?B?SsOpcsO0bWUgTGVnb3VwaWw=?= <jjlegoupil@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c264be4ec4db051774ec6f
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
(gavinandresen[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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YzPu2-00004y-7A
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
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, 01 Jun 2015 13:37:22 -0000
--001a11c264be4ec4db051774ec6f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
RE: going to the public:
I started pushing privately for SOMETHING, ANYTHING to be done, or at the
very least for there to be some coherent plan besides "wait and see" back
in February.
As for it being unhealthy for me to write the code that I think should be
written and asking people to run it:
Ok. What would you suggest I do? I believe scaling up is the number one
priority right now. I think core devs SHOULD be taking time to solve it,
because I think the uncertainty of how it will be solved (or if it will be
solved) is bad for Bitcoin.
I think working on things like fixing transaction malleability is great...
but the reason to work on that is to enable smart contracts and all sorts
of other interesting new uses of the blockchain. But if we're stuck with
1MB blocks then there won't be room for all of those interesting new uses
on the blockchain.
Others disagree, and have the advantage of status-quo : if nothing is done,
they get what they want.
Based on some comments I've seen, I think there is also concern that "my
own personal network/computer connection might not be able to handle more
transaction volume." That is NOT a good reason to limit scalability, but I
think it is clouding the judgement of many of the core contributors who
started contributing as a spare-time hobby from their homes (where maybe
they have crappy DSL connections).
RE: decentralization:
I think this is a red-herring. I'll quote something I said on reddit
yesterday:
"I don't believe a 20MB max size will increase centralization to any
significant degree.
See
http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-cen=
tralized
and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
And I think we will have a lot LESS centralization of payments via services
like Coinbase (or hubs in some future StrawPay/Lightning network) if the
bitcoin network can directly handle more payment volume.
The centralization trade-offs seems very clear to me, and I think the "big
blocks mean more centralized" arguments are either just wrong or are
exaggerated or ignore the tradeoff with payment centralization (I think
that is a lot more important for privacy and censorship resistance)."
RE: incentives for off-chain solutions:
I'll quote myself again from
http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea :
"The =E2=80=9Clayer 2=E2=80=9D services that are being built on top of the =
blockchain are
absolutely necessary to get nearly instant real-time payments,
micropayments and high volume machine-to-machine payments, to pick just
three examples. The ten-minute settlement time of blocks on the network is
not fast enough for those problems, and it will be the ten minute block
interval that drives development of those off-chain innovations more than
the total number of transactions supported."
On Mon, Jun 1, 2015 at 8:45 AM, J=C3=A9r=C3=B4me Legoupil <jjlegoupil@gmail=
.com>
wrote:
> If during the "1MB bumpy period" something goes wrong, consensus among th=
e
> community would be reached easily if necessary.
>
That is the problem: this will be a "frog in boiling water" problem. I
believe there will be no sudden crisis-- instead, transactions will just
get increasingly unreliable and expensive, driving more and more people
away from Bitcoin towards... I don't know what. Some less expensive, more
reliable, probably more-centralized solution.
The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
> irreversible way, for gaining short-term better user experience.
>
If by long-term security you mean "will transaction fees be high enough to
pay for enough hashing power to secure the network if there are bigger
blocks" I've written about that:
http://gavinandresen.ninja/block-size-and-miner-fees-again
If you mean something else, then please be specific.
--=20
--
Gavin Andresen
--001a11c264be4ec4db051774ec6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">RE: going to the public:<div><br></div><div>I started push=
ing privately for SOMETHING, ANYTHING to be done, or at the very least for =
there to be some coherent plan besides "wait and see" back in Feb=
ruary.</div><div><br></div><div>As for it being unhealthy for me to write t=
he code that I think should be written and asking people to run it:</div><d=
iv><br></div><div>Ok. What would you suggest I do? I believe scaling up is =
the number one priority right now. I think core devs SHOULD be taking time =
to solve it, because I think the uncertainty of how it will be solved (or i=
f it will be solved) is bad for Bitcoin.</div><div><br></div><div>I think w=
orking on things like fixing transaction malleability is great... but the r=
eason to work on that is to enable smart contracts and all sorts of other i=
nteresting new uses of the blockchain. But if we're stuck with 1MB bloc=
ks then there won't be room for all of those interesting new uses on th=
e blockchain.</div><div><br></div><div>Others disagree, and have the advant=
age of status-quo : if nothing is done, they get what they want.</div><div>=
<br></div><div>Based on some comments I've seen, I think there is also =
concern that "my own personal network/computer connection might not be=
able to handle more transaction volume." That is NOT a good reason to=
limit scalability, but I think it is clouding the judgement of many of the=
core contributors who started contributing as a spare-time hobby from thei=
r homes (where maybe they have crappy DSL connections).</div><div><br></div=
><div><br></div><div>RE: decentralization:</div><div><br></div><div>I think=
this is a red-herring. I'll quote something I said on reddit yesterday=
:</div><div><br></div>"I don't believe a 20MB max size will increa=
se centralization to any significant degree.<br><br>See <a href=3D"http://g=
avinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized=
">http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-c=
entralized</a><br><br>and <a href=3D"http://gavinandresen.ninja/are-bigger-=
blocks-better-for-bigger-miners">http://gavinandresen.ninja/are-bigger-bloc=
ks-better-for-bigger-miners</a><br><br>And I think we will have a lot LESS =
centralization of payments via services like Coinbase (or hubs in some futu=
re StrawPay/Lightning network) if the bitcoin network can directly handle m=
ore payment volume.<br><br>The centralization trade-offs seems very clear t=
o me, and I think the "big blocks mean more centralized" argument=
s are either just wrong or are exaggerated or ignore the tradeoff with paym=
ent centralization (I think that is a lot more important for privacy and ce=
nsorship resistance)."<div><br></div><div><br></div><div>RE: incentive=
s for off-chain solutions:<br><br>I'll quote myself again from=C2=A0<a =
href=3D"http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea">ht=
tp://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea</a> :</div><d=
iv><br>"The =E2=80=9Clayer 2=E2=80=9D services that are being built on=
top of the blockchain are absolutely necessary to get nearly instant real-=
time payments, micropayments and high volume machine-to-machine payments, t=
o pick just three examples. The ten-minute settlement time of blocks on the=
network is not fast enough for those problems, and it will be the ten minu=
te block interval that drives development of those off-chain innovations mo=
re than the total number of transactions supported."<div><br></div><di=
v>On Mon, Jun 1, 2015 at 8:45 AM, J=C3=A9r=C3=B4me Legoupil <span dir=3D"lt=
r"><<a href=3D"mailto:jjlegoupil@gmail.com" target=3D"_blank">jjlegoupil=
@gmail.com</a>></span> wrote:<div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><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-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>If during the "=
;1MB bumpy period" something goes wrong, consensus among the community=
would be reached easily if necessary.<br></div></div></blockquote><div><br=
></div><div>That is the problem: this will be a "frog in boiling water=
" problem. I believe there will be no sudden crisis-- instead, transac=
tions will just get increasingly unreliable and expensive, driving more and=
more people away from Bitcoin towards... I don't know what. Some less =
expensive, more reliable, probably more-centralized solution.</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"><div dir=3D"ltr"><div>The
Gavin 20MB proposal is compromising Bitcoin's long-term security in an=
=20
irreversible way, for gaining short-term better user experience. <br></div>=
</div></blockquote><div><br></div><div>If by long-term security you mean &q=
uot;will transaction fees be high enough to pay for enough hashing power to=
secure the network if there are bigger blocks" I've written about=
that:=C2=A0<a href=3D"http://gavinandresen.ninja/block-size-and-miner-fees=
-again">http://gavinandresen.ninja/block-size-and-miner-fees-again</a></div=
><div><br></div><div><br></div><div>If you mean something else, then please=
be specific.</div></div><div><br></div>-- <br><div class=3D"gmail_signatur=
e">--<br>Gavin Andresen<br></div>
</div></div></div></div></div>
--001a11c264be4ec4db051774ec6f--
|
