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
|
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 9D9FFFDD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 23:04:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com
[209.85.192.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1570E195
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 23:04:29 +0000 (UTC)
Received: by mail-qg0-f53.google.com with SMTP id u30so80245135qge.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Feb 2016 15:04:28 -0800 (PST)
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;
bh=8Z0GpEcmNUHnN+WjYt9fgjyJ+dT1mqDHEt/DEu+jHu8=;
b=0gYVvfwOZhSPkW2dbzs9cBGjm3HN1vQX7P+p8RSG1REaQIESjTgoTacw9y02a8qlOw
8rHOyZEPgtuI63GXv3tWVBE/7GGQtZyMKYBhwQevYDkCnVmJ0zoBbHe4iwWDuCLzBCcQ
4TiOfd/rw3VjcFhmWnfdMkiNoF4m3YCnMNloSKKbh+Ws8OPEWf44QJVQq1EHuZy1iC3N
BF+jnihWpHTMFl7wh3jSc/n09L+ai8ZD0NgCbn5aFLgFH3DN46Qo6Twe3f/6RQbmQwbi
UcVfAvgi3KgF2AD5icrxhrY/5bT5sxgseNxf6dfdjNdGx6sbOSjYK5yKYfMMEf1AYsfJ
FPhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=8Z0GpEcmNUHnN+WjYt9fgjyJ+dT1mqDHEt/DEu+jHu8=;
b=P+iVdfE5cwCC75BIIPc3JOfmOBIkIsGdfyedSoz0XSwUxYvzovHCrjGN9Dz32xfX1I
0ECjapts6C5ncBN+mpl12ACbtZCrbce9b1073DPIRCIjcQOjNXjuxXnyHw/L0rKrQZe8
xA6FRMqv96977corGlseh6zJwTbVo+VVtoVbwW/jnnY6okE2sUfewL3ARhoOKBycQaT5
UvU3xmHC7fVsAXrtzS5utKxxbHyuTjGn9ux0DoK+a8BF16f0wT7+3+DOalDwaBaIuRMy
eY1MMy1ZJB5HYg8cBuMVmctXvY5cnjazwgDgQWLyLvOOMOeunZYUyqXffj6+rFC+XgiB
Mxlg==
X-Gm-Message-State: AG10YORnbvUzyfwrWfZJm0GBZmujs+dblIbwDMPLUXnTpZ9bWdZ+Wz9FqPbWTpR4FZg8SVfuno+MyfdJvMbjWQ==
X-Received: by 10.141.6.130 with SMTP id i124mr20931293qhd.90.1454713468380;
Fri, 05 Feb 2016 15:04:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.65.210 with HTTP; Fri, 5 Feb 2016 15:04:09 -0800 (PST)
In-Reply-To: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Fri, 5 Feb 2016 23:04:09 +0000
Message-ID: <CADJgMztVG0WSZ5mgG87eZGCGqvS1BjK9uKSXaaFmdTyHxD-v0g@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a6538886b03052b0ddfd9
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,
HTML_MESSAGE,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
X-Mailman-Approved-At: Fri, 05 Feb 2016 23:14:01 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
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: Fri, 05 Feb 2016 23:04:29 -0000
--001a113a6538886b03052b0ddfd9
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
> https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
> Increase block size limit to 2,000,000 bytes.
> After 75% hashpower support then 28-day grace period.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
>
> Blog post walking through the code:
> http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
>
It's great to finally see a BIP, although seems strange to ask for feedback
after releasing binaries.
In any case, the issue isn't about "whether or not it is a good idea to
roll out a hard fork", the question has always been about how to do safe
hard fork deployment and what the technological requirements are for doing
so. Your BIP/blogs do not actually address any of this. 75% miner
signalling with a 28 day flag day thereafter gives virtually no time for
the entire ecosystem to migrate and is widely considered unsafe. It's
plainly obvious that an entire ecosystem of 5000 full nodes cannot be
prepared in a month.
--001a113a6538886b03052b0ddfd9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 5, 2016 at 8:51 PM, Gavin Andresen 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-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr">This has been reviewed by merchants, miners and=
exchanges for a couple of weeks, and has been implemented and tested as pa=
rt of the Bitcoin Classic and Bitcoin XT implementations.<div><br></div><di=
v>Constructive feedback welcome; argument about whether or not it is a good=
idea to roll out a hard fork now will be unproductive, so I vote we don=
9;t go there.</div><div><br></div><div>Draft BIP:</div><div>=C2=A0=C2=A0<a =
href=3D"https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.medi=
awiki" target=3D"_blank">https://github.com/gavinandresen/bips/blob/bump2mb=
/bip-bump2mb.mediawiki</a></div><div><br></div><div>Summary: =C2=A0</div><d=
iv>=C2=A0 Increase block size limit to 2,000,000 bytes.</div><div>=C2=A0 Af=
ter 75% hashpower support then 28-day grace period.</div><div>=C2=A0 With a=
ccurate sigop counting, but existing sigop limit (20,000)</div><div>=C2=A0 =
And a new, high limit on signature hashing</div><div><br></div><div>Blog po=
st walking through the code:</div><div>=C2=A0=C2=A0<a href=3D"http://gavina=
ndresen.ninja/a-guided-tour-of-the-2mb-fork" target=3D"_blank">http://gavin=
andresen.ninja/a-guided-tour-of-the-2mb-fork</a><br><div><br></div><div>Blo=
g post on a couple of the constants chosen:</div><div>=C2=A0=C2=A0<a href=
=3D"http://gavinandresen.ninja/seventyfive-twentyeight" target=3D"_blank">h=
ttp://gavinandresen.ninja/seventyfive-twentyeight</a></div></div></div></bl=
ockquote><div><br></div><div style=3D"font-size:12.8px">It's great to f=
inally see a BIP, although seems strange to ask for feedback after releasin=
g binaries.<br></div><div style=3D"font-size:12.8px"><br></div><div><span s=
tyle=3D"font-size:12.8px">In any case, the issue isn't about "whet=
her or not it is a good idea to roll out a hard fork", the question ha=
s always been about how to do safe hard fork deployment and what the techno=
logical requirements are for doing so. Your BIP/blogs do not actually addre=
ss any of this. 75% miner signalling with a 28 day flag day thereafter give=
s virtually no time for the entire ecosystem to migrate and is widely consi=
dered unsafe. It's plainly obvious that an entire ecosystem of 5000 ful=
l nodes cannot be prepared in a month.</span></div><div><br></div></div></d=
iv></div>
--001a113a6538886b03052b0ddfd9--
|
