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
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1YycgC-0007o1-F6
for bitcoin-development@lists.sourceforge.net;
Sat, 30 May 2015 09:03:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.182 as permitted sender)
client-ip=209.85.220.182; envelope-from=voisine@gmail.com;
helo=mail-qk0-f182.google.com;
Received: from mail-qk0-f182.google.com ([209.85.220.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YycgA-0005U2-Il
for bitcoin-development@lists.sourceforge.net;
Sat, 30 May 2015 09:03:44 +0000
Received: by qkhg32 with SMTP id g32so58248940qkh.0
for <bitcoin-development@lists.sourceforge.net>;
Sat, 30 May 2015 02:03:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.216.135 with SMTP id m129mr15082990qhb.20.1432976617114;
Sat, 30 May 2015 02:03:37 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Sat, 30 May 2015 02:03:36 -0700 (PDT)
In-Reply-To: <CA+VAk3O7SmDkxL9rATWe9oqCVVKcT=cFXDJnARPN8pv=UiHaiA@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
<CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
<CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
<CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com>
<CA+VAk3O7SmDkxL9rATWe9oqCVVKcT=cFXDJnARPN8pv=UiHaiA@mail.gmail.com>
Date: Sat, 30 May 2015 02:03:36 -0700
Message-ID: <CACq0ZD7-qr4BCdnqOSXLYv-i58vAXWGcQ1oLsrbHoNFMeiNTtg@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Admin Istrator <andy@ftlio.com>
Content-Type: multipart/alternative; boundary=001a1135d24a3c0f70051748de91
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
(voisine[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: 1YycgA-0005U2-Il
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
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 09:03:44 -0000
--001a1135d24a3c0f70051748de91
Content-Type: text/plain; charset=UTF-8
> or achieving less than great DOS protection
Right now a bunch of redditors can DOS the network at the cost of a few
thousand dollars per day, shared between them. Since the cost of validating
transactions is far lower than current minimum relay fees, then increasing
the block size increases the cost of DOSing the network.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 29, 2015 at 10:53 AM, Admin Istrator <andy@ftlio.com> wrote:
> What about trying the dynamic scaling method within the 20MB range + 1
> year with a 40% increase of that cap? Until a way to dynamically scale is
> found, the cap will only continue to be an issue. With 20 MB + 40% yoy,
> we're either imposing an arbitrary cap later, or achieving less than great
> DOS protection always. Why not set that policy as a maximum for 2 years as
> a protection against the possibility of dynamic scaling abuse, and see what
> happens with a dynamic method in the mean time. The policy of Max(1MB,
> (average size over previous 144 blocks) * 2) calculated at each block seems
> pretty reasonable.
>
> As an outsider, the real 'median' here seems to be 'keeping the cap as
> small as possible while allowing for larger blocks still'. We know
> miners will want to keep space in their blocks relatively scarce, but we
> also know that doesn't exclude the more powerful miners from
> including superfluous transactions to increase their effective share of the
> network. I have the luck of not being drained by this topic over the past
> three years, so it looks to me as if its two poles of 'block size must
> increase' and 'block size must not increase' are forcing what is the clear
> route to establishing the 'right' block size off the table.
>
> --Andrew Len
> (sorry if anybody received this twice, sent as the wrong email the first
> time around).
>
> On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
>
>> What do other people think?
>>
>>
>> If we can't come to an agreement soon, then I'll ask for help
>> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
>> big increase now that grows over time so we may never have to go through
>> all this rancor and debate again.
>>
>> I'll then ask for help lobbying the merchant services and exchanges and
>> hosted wallet companies and other bitcoind-using-infrastructure companies
>> (and anybody who agrees with me that we need bigger blocks sooner rather
>> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
>> are running it. We'll be able to see uptake on the network by monitoring
>> client versions.
>>
>> Perhaps by the time that happens there will be consensus bigger blocks
>> are needed sooner rather than later; if so, great! The early deployment
>> will just serve as early testing, and all of the software already deployed
>> will ready for bigger blocks.
>>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting big miners to
>> do the same, and use the soft-fork block version voting mechanism to
>> (hopefully) get a majority and then a super-majority willing to produce
>> bigger blocks. The purpose of that process is to prove to any doubters that
>> they'd better start supporting bigger blocks or they'll be left behind, and
>> to give them a chance to upgrade before that happens.
>>
>>
>> Because if we can't come to consensus here, the ultimate authority for
>> determining consensus is what code the majority of merchants and exchanges
>> and miners are running.
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a1135d24a3c0f70051748de91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:13px">or achieving less=
than great DOS protection=C2=A0</span><div><span style=3D"font-size:13px">=
<br></span></div><div>Right now a bunch of redditors can DOS the network at=
the cost of a few thousand dollars per day, shared between them. Since the=
cost of validating transactions is far lower than current minimum relay fe=
es, then increasing the block size increases the cost of DOSing the=C2=A0ne=
twork.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div cl=
ass=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br>Aar=
on Voisine</div><div>co-founder and CEO<br><a href=3D"http://breadwallet.co=
m" target=3D"_blank">breadwallet.com</a></div></div></div></div></div></div=
>
<br><div class=3D"gmail_quote">On Fri, May 29, 2015 at 10:53 AM, Admin Istr=
ator <span dir=3D"ltr"><<a href=3D"mailto:andy@ftlio.com" target=3D"_bla=
nk">andy@ftlio.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><span style=3D"font-size:12.8000001907349px">What about tr=
ying the dynamic scaling method within the 20MB range + 1 year with a 40% i=
ncrease of that cap?=C2=A0 Until a way to dynamically scale is found, the c=
ap will only continue to be an issue.=C2=A0 With 20 MB + 40% yoy, we're=
either imposing an arbitrary cap later, or achieving less than great DOS p=
rotection always.=C2=A0 Why not set that policy as a maximum for 2 years as=
a protection against the possibility of dynamic scaling abuse, and see wha=
t happens with a dynamic method in the mean time.=C2=A0 The policy of Max(1=
MB, (average size over previous 144 blocks) * 2) calculated at each block s=
eems pretty reasonable. =C2=A0</span><br style=3D"font-size:12.800000190734=
9px"><br style=3D"font-size:12.8000001907349px"><span style=3D"font-size:12=
.8000001907349px">As an outsider, the real 'median' here seems to b=
e 'keeping the cap as small as possible while allowing for larger block=
s still'. =C2=A0 =C2=A0We know miners will want to keep space in their =
blocks relatively scarce, but we also know that doesn't exclude the mor=
e powerful miners from including=C2=A0superfluous=C2=A0transactions to incr=
ease their effective share of the network.=C2=A0 I have the luck of not bei=
ng drained by this topic over the past three years,=C2=A0so it looks to me =
as if its two poles of 'block size must increase' and 'block si=
ze must not increase' are forcing what is the clear route to establishi=
ng the 'right' block size off the table.=C2=A0<br></span><br>--Andr=
ew Len <br>(sorry if anybody received this twice, sent as the wrong email t=
he first time around).<br><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote"><div><div class=3D"h5">On Fri, May 29, 2015 at 5:39 AM, Gavin Andr=
esen <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" targe=
t=3D"_blank">gavinandresen@gmail.com</a>></span> wrote:<br></div></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">What =
do other people think?<div><br></div><div><br></div><div>If we can't co=
me to an agreement soon, then I'll ask for help reviewing/submitting pa=
tches to Mike's Bitcoin-Xt project that implement a big increase now th=
at grows over time so we may never have to go through all this rancor and d=
ebate again.</div><div><br></div><div>I'll then ask for help lobbying t=
he merchant services and exchanges and hosted wallet companies and other bi=
tcoind-using-infrastructure companies (and anybody who agrees with me that =
we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead o=
f Bitcoin Core, and state that they are running it. We'll be able to se=
e uptake on the network by monitoring client versions.</div><div><br></div>=
<div>Perhaps by the time that happens there will be consensus bigger blocks=
are needed sooner rather than later; if so, great! The early deployment wi=
ll just serve as early testing, and all of the software already deployed wi=
ll ready for bigger blocks.</div><div><br></div><div>But if there is still =
no consensus among developers but the "bigger blocks now" movemen=
t is successful, I'll ask for help getting big miners to do the same, a=
nd use the soft-fork block version voting mechanism to (hopefully) get a ma=
jority and then a super-majority willing to produce bigger blocks. The purp=
ose of that process is to prove to any doubters that they'd better star=
t supporting bigger blocks or they'll be left behind, and to give them =
a chance to upgrade before that happens.</div><div><br></div><div><br></div=
><div>Because if we can't come to consensus here, the ultimate authorit=
y for determining consensus is what code the majority of merchants and exch=
anges and miners are running.</div><span><font color=3D"#888888"><div class=
=3D"gmail_extra"><div><br></div><div><br></div>-- <br><div>--<br>Gavin Andr=
esen<br></div>
</div></font></span></div>
<br></div></div>-----------------------------------------------------------=
-------------------<span class=3D""><br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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></span></blockquote></div><br></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></div>
--001a1135d24a3c0f70051748de91--
|
