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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 95278116C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 11:59:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
[209.85.220.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC5A319C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 11:59:01 +0000 (UTC)
Received: by qkcj187 with SMTP id j187so19884909qkc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 04:59:01 -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:cc
:content-type; bh=myNQSAVK4762WS0Zx4qG1WL1AZPYciFbzSJsQloODAQ=;
b=0Q0oo6O0fl1p0PDO6+t99WfsVebm7ImlveAtvT3bjk9iFEHO+c2Tv4QjjJHZmgC5PS
HA1z4pad226P4KzqH5Xm8UDlrSjGizNMHPkRHmzAV1xe2S5jrpa99ndFOrtzOHkXA8Hx
Tpa3IiTRrL9Sgg54Pl3hxNDSSQEvJll4bRYVQTQf7QQjIUdc6Nsp1peKJnbkgSu6B2Rl
KyoECs9C8TaZ+6n8V9gxqeB97cDJ8RaSOfUbxFvPck2Ku0v1xuRCfjaUr2J8z3pyPWoN
G1aXC9b1YGFZ8XVq/wEb14N1zB1I1cyL05YZ7ydb6/Y8M4zC/9U9yf7uJPSNrLC4EvDq
XV1Q==
MIME-Version: 1.0
X-Received: by 10.55.42.163 with SMTP id q35mr36933423qkq.107.1441281541202;
Thu, 03 Sep 2015 04:59:01 -0700 (PDT)
Received: by 10.140.107.4 with HTTP; Thu, 3 Sep 2015 04:59:01 -0700 (PDT)
In-Reply-To: <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
Date: Thu, 3 Sep 2015 12:59:01 +0100
Message-ID: <CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11493ef44905d5051ed682a1
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP 100 specification
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, 03 Sep 2015 11:59:02 -0000
--001a11493ef44905d5051ed682a1
Content-Type: text/plain; charset=UTF-8
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 1.
>
> hardLimit floats within the range 1-32M, inclusive.
>
>
>
Does the 32MB limit actually still exist anywhere in the code? In effect,
it is re-instating a legacy limitation.
The message size limit is to minimize the storage required per peer. If a
32MB block size is required, then each network input buffer must be at
least 32MB. This makes it harder for a node to support a large number of
peers.
There is no reason why a single message is used for each block. Using the
merkleblock message (or a different dedicated message), it would be
possible to send messages which only contain part of a block and have a
limited maximum size.
This would allow receiving parts of a block from multiple sources.
This is a separate issue but should be considered if moving past 32MB block
sizes (or maybe as a later protocol change).
>
> 1. Changing hardLimit is accomplished by encoding a proposed value
> within a block's coinbase scriptSig.
> 1. Votes refer to a byte value, encoded within the pattern
> "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If
> there is more than one match with with pattern, the first match is counted.
>
> Is there a need for byte resolution? Using MB resolution would use up
much fewer bytes in the coinbase.
Even with the +/- 20% rule, miners could vote for the nearest MB. Once the
block size exceeds 5MB, then there is enough resolution anyway.
> 1. Absent/invalid votes and votes below minimum cap (1M) are counted
> as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes.
>
>
I think abstains should count for the status quo. Votes which are out of
range should be clamped.
Having said that, if core supports the change, then most miners will
probably vote one way or another.
> New hardLimit is the median of the followings:
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
I think this is unclear, though mathematically exact.
Sort the votes for the last 12,000 blocks from lowest to highest.
Blocks which don't have a vote are considered a vote for the status quo.
Votes are limited to +/- 20% of the current value. Votes that are out of
range are considered to vote for the nearest in range value.
The raise value is defined as the vote for the 2400th highest block (20th
percentile).
The lower value is defined as the vote for the 9600th highest block (80th
percentile).
If the raise value is higher than the status quo, then the new limit is set
to the raise value.
If the lower value is lower than the status quo, then the new limit is set
to the lower value.
Otherwise, the size limit is unchanged.
--001a11493ef44905d5051ed682a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <span dir=3D"ltr=
"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif"><ol><li=
>
<pre>hardLimit floats within the range 1-32M, inclusive.</pre></li></ol></d=
iv></blockquote><div><br></div><div>Does the 32MB limit actually still exis=
t anywhere in the code?=C2=A0 In effect, it is re-instating a legacy limita=
tion.<br><br></div><div>The message size limit is to minimize the storage r=
equired per peer.=C2=A0 If a 32MB block size is required, then each network=
input buffer must be at least 32MB. This makes it harder for a node to sup=
port a large number of peers.<br><br></div><div>There is no reason why a si=
ngle message is used for each block.=C2=A0 Using the merkleblock message (o=
r a different dedicated message), it would be possible to send messages whi=
ch only contain part of a block and have a limited maximum size.<br><br></d=
iv><div>This would allow receiving parts of a block from multiple sources.=
=C2=A0 <br><br></div><div>This is a separate issue but should be considered=
if moving past 32MB block sizes (or maybe as a later protocol change).<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif"><ol><li><=
span style=3D"white-space:pre-wrap">Changing hardLimit is accomplished by e=
ncoding a proposed value within a block's coinbase scriptSig.</span></l=
i>
<ol>
<li><span style=3D"white-space:pre-wrap">Votes refer to a byte value, encod=
ed within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,=
000,000 byte hardLimit. </span><span style=3D"white-space:pre-wrap;text-dec=
oration:underline">If there is more than one match with with pattern, the f=
irst match is counted.</span></li></ol></ol></div></blockquote><div>Is ther=
e a need for byte resolution?=C2=A0 Using MB resolution would use up much f=
ewer bytes in the coinbase.<br><br></div><div>Even with the +/- 20% rule, m=
iners could vote for the nearest MB.=C2=A0 Once the block size exceeds 5MB,=
then there is enough resolution anyway.<br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div style=3D"font-size:10pt;font-f=
amily:Verdana,Geneva,sans-serif"><ol><ol>
<li><span style=3D"white-space:pre-wrap">Absent/invalid votes and votes bel=
ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3=
2M) are counted as 32M votes.</span></li></ol></ol></div></blockquote><div>=
<br></div><div>I think abstains should count for the status quo.=C2=A0 Vote=
s which are out of range should be clamped.<br><br></div><div>Having said t=
hat, if core supports the change, then most miners will probably vote one w=
ay or another.<br><br>><span style=3D"white-space:pre-wrap"> New hardLim=
it is the median of the followings:</span><span style=3D"white-space:pre-wr=
ap"><br>> m</span><span style=3D"white-space:pre-wrap">in(current ha=
rdLimit * 1.2, 20-percentile)</span><span style=3D"white-space:pre-wrap"><b=
r>> max(current hardLimit / 1.2, 80-percentile)</span><span style=3D=
"white-space:pre-wrap"><br>> current hardLimit</span><span style=3D"=
text-decoration:underline;white-space:pre-wrap"></span><span style=3D"text-=
decoration:underline;white-space:pre-wrap"></span><br><br></div><div>I thin=
k this is unclear, though mathematically exact.<br></div><div><br></div>Sor=
t the votes for the last 12,000 blocks from lowest to highest.=C2=A0 <br><b=
r>Blocks which don't have a vote are considered a vote for the status q=
uo.<br><br></div><div class=3D"gmail_quote">Votes are limited to +/- 20% of=
the current value.=C2=A0 Votes that are out of range are considered to vot=
e for the nearest in range value.<br></div><br><div class=3D"gmail_quote">T=
he raise value is defined as the vote for the 2400th highest block (20th pe=
rcentile).<br></div><div class=3D"gmail_quote">The lower value=C2=A0 is def=
ined as the vote for the 9600th highest block (80th percentile).<br><br></d=
iv><div class=3D"gmail_quote">If the raise value is higher than the status =
quo, then the new limit is set to the raise value.<br></div><div class=3D"g=
mail_quote">If the lower value is lower than the status quo, then the new l=
imit is set to the lower value.<br></div><div class=3D"gmail_quote">Otherwi=
se, the size limit is unchanged.<br></div></div></div>
--001a11493ef44905d5051ed682a1--
|
