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
|
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 12AE211D8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 15:58:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
[209.85.223.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B2C61AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2015 15:58:24 +0000 (UTC)
Received: by iofh134 with SMTP id h134so63554016iof.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2015 08:58:23 -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=eJyPJxBgdy6tlP3sBhW0iZisySyAVyxcneKIFcp3aQs=;
b=PJCKrWfL/7WZ2tP1fAw4eW3+Xjn5n4QTwu8VtHJBkzpe9I1a4Xvpby6Zi7yX1LnIdc
/7qW+JF4XyAe/vifOwTdot0xoJg9Zb9O9d+l3wuivyiuPj77jleTPX9sI6nbYP5nC2C0
NsN3MgCGRBJOMDTAlLINmmdrvcrZmMMm6xfC4U50GSkB8tW14vAIG4otpLXXMIMQ6Blq
M9x+CuAXAwsbTMoSwjirajl8nsLhcxk8tMFam6okoelR9XPIxL57r4npfROWJC/PREC/
0y/nWI8Y/V4s+NphAQaDiY1eNA0qEnD3iFa87Z6Kx8ZyBY9OwwNOcn4WgjSDXs7GYf+K
tdHg==
X-Received: by 10.107.162.205 with SMTP id l196mr21646444ioe.3.1441295903685;
Thu, 03 Sep 2015 08:58:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.40 with HTTP; Thu, 3 Sep 2015 08:58:04 -0700 (PDT)
In-Reply-To: <CADm_WcbVRQMFHU0pS7hi99=Ey3Pu3t6pViaPG-KpHF40w69N6A@mail.gmail.com>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
<CADJgMzuWNNvMf6f9N0h0swAUATyAm4Y9Qu+ya33cEA1WB++sRg@mail.gmail.com>
<CADm_WcbVRQMFHU0pS7hi99=Ey3Pu3t6pViaPG-KpHF40w69N6A@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 3 Sep 2015 16:58:04 +0100
Message-ID: <CADJgMzsXrrY+-OHzUmnaDmFkqvDr29eHuwOvovSnUwjVnOiZOQ@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 15:58:26 -0000
On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
> A discussion of rolling out BIP 100 will not be avoided :)
>
> It is a hard fork; it would be silly to elide discussion of these key
> issues.
>
> I don't get the community's recent interest in avoiding certain topics.
It's not a matter of avoiding the subject, it's a whole separate
discussion and in the interests of efficient discussion, it is best
done separately. There's a whole BIP dedicated to the discussion of
consensus forks which you should probably give some input in also,
BIP99 [1]
Once we come to an agreement and can say "here's what we're doing
about blocksize, it will be X, or we'll raise by this algo", then we
can discuss the best way to implement the hard fork.
[1] https://github.com/bitcoin/bips/pull/181
>
>
>
> On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak@gmail.com> wrote:
>>
>> We should avoid discussing actual hard fork/softfork deployment
>> methodologies when discussing blocksize proposals because deployment
>> is a separate issue. As a recent case in point, look at how BIP65
>> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
>> That lead to a focused discussion of the functionality and relatively
>> quick inclusion.
>>
>> Deployment really is a separate issue than the mechanics of how BIP100
>> will function after activation.
>>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > Some comments:
>> >
>> > The 75% rule is meaningless here. Since this is a pure relaxation of
>> > rules,
>> > there is no such thing as "invalid version 4 blocks"
>> >
>> > The implication threshold is unclear. Is it 95% or 80%?
>> >
>> > Softfork requires a very high threshold (95%) to "attack" the original
>> > fork.
>> > This makes sure that unupgraded client will only see the new fork.
>> > In the case of hardfork, however, the new fork is unable to attack the
>> > original fork, and unupgraded client will never see the new fork. The
>> > initiation of a hardfork should be based on its acceptance by the
>> > economic
>> > majority, not miner support. 95% is an overkill and may probably never
>> > accomplished. I strongly prefer a 80% threshold rather than 95%.
>> >
>> > As I've pointed out, using 20-percentile rather than median creates an
>> > incentive to 51% attack the uncooperative minority.
>> >
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01=
0690.html
>> >
>> > Having said that, I don't have a strong feeling about the use of
>> > 20-percentile as threshold to increase the block size. That means the
>> > block
>> > size is increased only when most miners agree, which sounds ok to me.
>> >
>> > However, using 20-percentile as threshold to DECREASE the block size
>> > could
>> > be very dangerous. Consider that the block size has been stable at 8MB
>> > for a
>> > few years. Everyone are happy with that. An attacker would just need t=
o
>> > acquire 21% of mining power to break the status quo and send us all th=
e
>> > way
>> > to 1MB. The only way to stop such attempt is to 51% attack the attacke=
r.
>> > That'd be really ugly.
>> >
>> > For technical and ethical reasons, I believe the thresholds for increa=
se
>> > and
>> > decrease must be symmetrical: increase the block size when the
>> > x-percentile
>> > is bigger than the current size, decrease the block size when the
>> > (100-x)-percentile is smaller than the current size. The overall effec=
t
>> > is:
>> > the block size remains unchanged unless 80% of miners agree to.
>> >
>> > Please consider the use of "hardfork bit" to signify the hardfork:
>> >
>> >
>> > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_har=
dfork_bit_jl2012_at_xbthk_jul_23_2015/
>> >
>> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>> >
>> > Or, alternatively, please combine the hardfork with a softfork. I'm
>> > rewriting the specification as follow (changes underlined):
>> >
>> > Replace static 1M block size hard limit with a floating limit
>> > ("hardLimit").
>> >
>> > hardLimit floats within the range 1-32M, inclusive.
>> >
>> > Initial value of hardLimit is 1M, preserving current system.
>> >
>> > 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 "/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.
>> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1=
M
>> > votes. Votes above the maximum cap (32M) are counted as 32M votes.
>> > A new hardLimit is calculated at each difficult adjustment period (201=
6
>> > blocks), and applies to the next 2016 blocks.
>> > Calculate hardLimit by examining the coinbase scriptSig votes of the
>> > previous 12,000 blocks, and taking the 20th percentile and 80th
>> > percentile.
>> > New hardLimit is the median of the followings:
>> >
>> > min(current hardLimit * 1.2, 20-percentile)
>> > max(current hardLimit / 1.2, 80-percentile)
>> > current hardLimit
>> >
>> > version 4 block: the coinbase of a version 4 block must match this
>> > pattern:
>> > "/BV\d+/"
>> > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
>> > reject invalid version 4 blocks. (testnet4: 501 of last 1000)
>> > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks ar=
e
>> > version 4 or greater, reject all version <=3D 3 blocks. (testnet4: 750=
of
>> > last
>> > 1000)
>> > Block version number is calculated after masking out high 16 bits (fin=
al
>> > bit
>> > count TBD by versionBits outcome).
>> >
>> > Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=
=B0:
>> >> BIP 100 initial public draft:
>> >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>> >>
>> >> Emphasis on "initial" This is a starting point for the usual open
>> >> source feedback/iteration cycle, not an endpoint that Must Be This
>> >> Way.
>> >>
>> >>
>> >>
>> >> Links:
>> >> ------
>> >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>
>
|
