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
|
Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 16DD2FE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Sep 2015 16:46:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com
[209.85.160.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E12223A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Sep 2015 16:46:34 +0000 (UTC)
Received: by ykcf206 with SMTP id f206so127697490ykc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Sep 2015 09:46:33 -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=vBMG3J8D+y5Ng3i0iSX/xdRPfUPUlD5iKSFDVWzF5Ag=;
b=TKb80WvDZdlEkv95vf3qhpwDgQZw3QaqK1DYvXcIf8qMZpqweDjqR8bwZ0RSkFy+C/
GnqBF2LBXPkrE5igssfCyPARMrvH2umDrMo2o8U9mvBCebRJ25pJerdAtZBG+0rsiFl1
c3su7oRymg6mIJNThr6hGVvv2dPuzlrmcdQSOic5fSkcrb7iIcuCM5dq28RJrNHonw6s
+C+ZZVlYjZ8bzzET/W1+kqrqmPVQ4yVbhf4RNXdZiaqjafuk9Ti+40DETcuH5p/HVihn
JZ4JXeAR5hq3BJlf7O1vCQYC5pSDWxWNMc8miFOsorpY2HXIVOMwmcWRmflHCoT9fLXr
pI+Q==
MIME-Version: 1.0
X-Received: by 10.13.244.134 with SMTP id d128mr29741619ywf.27.1441730793530;
Tue, 08 Sep 2015 09:46:33 -0700 (PDT)
Received: by 10.103.39.133 with HTTP; Tue, 8 Sep 2015 09:46:33 -0700 (PDT)
Received: by 10.103.39.133 with HTTP; Tue, 8 Sep 2015 09:46:33 -0700 (PDT)
In-Reply-To: <CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com>
References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com>
<CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com>
<CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com>
<CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com>
<CAG0bcYzBCsg9xNLGmu4S=PEPjtbd2iBLH52ryswbkRM23OqquA@mail.gmail.com>
<CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com>
<CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com>
Date: Tue, 8 Sep 2015 11:46:33 -0500
Message-ID: <CAAy62_JeG=_8sOgcgZNZSPHJYo8WxOkOHHkxCv6ZKjeRkbxujw@mail.gmail.com>
From: Andrew Johnson <andrew.johnson83@gmail.com>
To: Washington Sanchez <washington.sanchez@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0887bccf888a051f3f1b79
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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] Dynamic limit to the block size - BIP draft
discussion
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: Tue, 08 Sep 2015 16:46:35 -0000
--94eb2c0887bccf888a051f3f1b79
Content-Type: text/plain; charset=UTF-8
I rather like this idea, I like that we're taking block scaling back to a
technical method rather than political. BIP100 is frightening to me as it
gives a disproportionate amount of power to the miners, who can already
control their own blocksize with a soft cap. It also seems silly to worry
about a selfish mining attack if you're going to institute a miner vote
that an entity with that much hashrate can noticeably influence anyway.
101 is better but is still attempting to make a guess as to technological
progression quite far into the future. And then when we do finally hit 8GB
we will need yet another hard fork if we need to go bigger(or we may need
to do it earlier if the increase schedule isn't aggressive enough). And
who knows how large the ecosystem may be at that time, a hard fork may be
an undertaking of truly epic proportions due to the sheer number of devices
and embedded firmware that operates on the block chain.
I've done no math on this(posting from mobile) but something similar to
this would be reasonable, I think. Unbounded growth, as Adam points out,
is also undesirable.
Every 4032 blocks (~4 weeks), the maximum block size will be decreased by
10% *IF* a minimum of 2500 blocks has a size <= 40% of the maximum block
size at that time.
This requires a larger threshold to be crossed to move downwards, that way
we hopefully aren't oscillating back and forth constantly. I'll try to do
some blockchain research sometime this week and either back my plucked from
the air numbers or change them.
Andrew Johnson
On Sep 8, 2015 10:11 AM, "Washington Sanchez via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 1) It's not really clear to me how that would work, but assuming it does
> then it will go into a basket of attacks that are possible but unlikely due
> to the economic disincentives to do so.
>
> 2) That said, is the Achilles heal of this proposal the lack of a
> mechanism to lower the block size?
>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>
> On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <adam@cypherspace.org> wrote:
>
>> > A selfish mining attack would have to be performed for at least 2000
>> blocks over a period of 4 weeks in order to achieve a meager 10% increase
>> in the block size.
>>
>> You seem to be analysing a different attack - I mean that if someone
>> has enough hashrate to do a selfish mining attack, then setting up a
>> system that has no means to reduce block-size risks that at a point
>> where there is excess block-size they can use that free transaction
>> space to amplify selfish mining instead of collecting transaction
>> fees.
>>
>> Adam
>>
>
>
>
> --
> -------------------------------------------
> *Dr Washington Y. Sanchez <http://onename.com/drwasho>*
> Co-founder, OB1 <http://ob1.io>
> Core developer of OpenBazaar <https://openbazaar.org>
> @drwasho <https://twitter.com/drwasho>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c0887bccf888a051f3f1b79
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I rather like this idea, I like that we're taking block =
scaling back to a technical method rather than political.=C2=A0 BIP100 is f=
rightening to me as it gives a disproportionate amount of power to the mine=
rs, who can already control their own blocksize with a soft cap.=C2=A0 It a=
lso seems silly to worry about a selfish mining attack if you're going =
to institute a miner vote that an entity with that much hashrate can notice=
ably influence anyway. </p>
<p dir=3D"ltr">101 is better but is still attempting to make a guess as to =
technological progression quite far into the future.=C2=A0 And then when we=
do finally hit 8GB we will need yet another hard fork if we need to go big=
ger(or we may need to do it earlier if the increase schedule isn't aggr=
essive enough).=C2=A0 And who knows how large the ecosystem may be at that =
time, a hard fork may be an undertaking of truly epic proportions due to th=
e sheer number of devices and embedded firmware that operates on the block =
chain.</p>
<p dir=3D"ltr">I've done no math on this(posting from mobile) but somet=
hing similar to this would be reasonable, I think.=C2=A0 Unbounded growth, =
as Adam points out, is also undesirable.</p>
<p dir=3D"ltr">Every 4032 blocks (~4 weeks), the maximum block size will be=
decreased by 10% *IF* a minimum of 2500 blocks has a size <=3D 40% of t=
he maximum block size at that time.</p>
<p dir=3D"ltr">This requires a larger threshold to be crossed to move downw=
ards, that way we hopefully aren't oscillating back and forth constantl=
y.=C2=A0 I'll try to do some blockchain research sometime this week and=
either back my plucked from the air numbers or change them.</p>
<p dir=3D"ltr">Andrew Johnson</p>
<div class=3D"gmail_quote">On Sep 8, 2015 10:11 AM, "Washington Sanche=
z via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"a=
ttribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
1) It's not really clear to me how that would work, but assuming it doe=
s then it will go into a basket of attacks that are possible but unlikely d=
ue to the economic disincentives to do so.<div><br></div><div>2) That said,=
is the Achilles heal of this proposal the lack of a mechanism to lower the=
block size?=C2=A0</div><div><br></div><div>3) Let me put it another way, I=
've read that both Gavin and yourself are favorable to a dynamic limit =
on the block size. In your view, what is missing from this proposal, or wha=
t variables should be adjusted, to get the rules to a place where you and o=
ther Core developers would seriously consider it?</div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Wed, Sep 9, 2015 at 12:18 AM=
, Adam Back <span dir=3D"ltr"><<a href=3D"mailto:adam@cypherspace.org" t=
arget=3D"_blank">adam@cypherspace.org</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><span>> A selfish mining attack would have to be perf=
ormed for at least 2000 blocks over a period of 4 weeks in order to achieve=
a meager 10% increase in the block size.<br>
<br>
</span>You seem to be analysing a different attack - I mean that if someone=
<br>
has enough hashrate to do a selfish mining attack, then setting up a<br>
system that has no means to reduce block-size risks that at a point<br>
where there is excess block-size they can use that free transaction<br>
space to amplify selfish mining instead of collecting transaction<br>
fees.<br>
<span><font color=3D"#888888"><br>
Adam<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div>-------------------=
------------------------</div><div><b><a href=3D"http://onename.com/drwasho=
" target=3D"_blank">Dr Washington Y. Sanchez</a></b></div><div>Co-founder, =
<a href=3D"http://ob1.io" target=3D"_blank">OB1</a></div><div>Core develope=
r of <a href=3D"https://openbazaar.org" target=3D"_blank">OpenBazaar</a></d=
iv><div><a href=3D"https://twitter.com/drwasho" target=3D"_blank">@drwasho<=
/a></div></div><div><br></div></div></div></div></div>
</div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>
--94eb2c0887bccf888a051f3f1b79--
|
