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
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3B08B1159
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 17:32:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
[209.85.212.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7182710B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 17:32:30 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so60008073wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 10:32:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:content-transfer-encoding;
bh=wLAwFETIzz+nYR2sUVTjhggYpHGYG8XvztEXgokZ7VU=;
b=JRSxNAsKBMA5YWNqetU34bQDCuOfzhDNCwFqtwgK7f7xsNEzznPHrlv9y7zn0MT3H0
0ZATWOtRdL4tqaPrfKs/tJC8kOgZCmgmlff+2LjeyJrt9hPlOcR/ByeBG8zwShwQ1rq3
3z1nZn+cOeQFmFrYX7QucmuB9iqRAU8oHWAWzwRJn+tDVzK0LeP+BXXh3fJNyqHvrIeG
+nUiAJop8reUy7vlyVPKKHFw5mEasoLz4ThXMD1zWTPVwYuFraXEI7tP4slwHxHuESd/
hcyoCTG7YM1L0DKEW8GnFQm6s092WbI6mZ5Vw34A+nZLtVl/tGjvQhNr0e9FbJVjAICO
XqgA==
X-Received: by 10.194.191.164 with SMTP id gz4mr53131086wjc.21.1441301548948;
Thu, 03 Sep 2015 10:32:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.211.16 with HTTP; Thu, 3 Sep 2015 10:32:09 -0700 (PDT)
In-Reply-To: <CADm_WcaJYogJWeQ0kkADgYMS7=H9f60Y4thr_XT-thROyYfg2w@mail.gmail.com>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
<CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com>
<301aa5f682f8aa408b9f6f4618095fe2@xbt.hk>
<CADm_WcaJYogJWeQ0kkADgYMS7=H9f60Y4thr_XT-thROyYfg2w@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 3 Sep 2015 18:32:09 +0100
Message-ID: <CADJgMzuTJZxj7BWoEKD51OM=V200EfEimWM2Tkix7+zkCWcE0w@mail.gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM, 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
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.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 17:32:31 -0000
Just use a 4-byte unsigned integer where the integer is the size in
bytes. It's concise and less complex (and less complex to implement).
There's no need for human readable strings here.
On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Take a look at the latest update:
>
> - swiped Tier Nolan verbiage, which I agree was usefully more clear
> - added 'M' suffix and removed 'V' from coinbase scriptSig
>
>
> On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 1. I think there is no need to have resolution at byte level, while
>> resolution at MB level is not enough. kB would be a better choice.
>>
>> 2. In my specification a v4 block without a vote is invalid, so there is
>> no need to consider absent or invalid votes
>>
>> 3. We should allow miners to explicitly vote for the status quo, so they
>> don't need to change the coinbase vote every time the size is changed. T=
hey
>> may indicate it by /BV/ in the coinbase, and we should look for the firs=
t
>> "/BVd*/" instead of "/BVd+/"
>>
>> 4. Alternatively, miners may vote in different styles: /BV1234567/,
>> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5=
MB,
>> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
>>
>> Tier Nolan via bitcoin-dev =E6=96=BC 2015-09-03 07:59 =E5=AF=AB=E5=88=B0=
:
>>>
>>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> *
>>>>
>>>> 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).
>>>
>>>> * Changing hardLimit is accomplished by encoding a proposed value
>>>> within a block's coinbase scriptSig.
>>>>
>>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>>>> 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.
>>>
>>>> * 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.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
