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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BC97FA73;
Sun, 7 Feb 2016 16:55:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149077.authsmtp.com (outmail149077.authsmtp.com
[62.13.149.77])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id EAF9890;
Sun, 7 Feb 2016 16:55:58 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u17GtvSc032958;
Sun, 7 Feb 2016 16:55:57 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u17GtsOU044838
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sun, 7 Feb 2016 16:55:54 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 9CEF740012;
Sun, 7 Feb 2016 16:52:39 +0000 (UTC)
Received: by savin (Postfix, from userid 1000)
id A7A5B13FCB2; Sun, 7 Feb 2016 11:55:52 -0500 (EST)
Received: by savin (hashcash-sendmail, from uid 1000);
Sun, 7 Feb 2016 11:54:23 -0500
Date: Sun, 7 Feb 2016 11:54:23 -0500
From: Peter Todd <pete@petertodd.org>
To: Alex Morcos <morcos@gmail.com>
Message-ID: <20160207165423.GA26975@savin.petertodd.org>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com>
<1804222.7gVHPiWqto@kiwi> <201602062046.40193.luke@dashjr.org>
<CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
<CAPWm=eVG1MFygACo6Mb6iLSe=GwjygTjjKhmN1Btu9Uyw+Vc-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+"
Content-Disposition: inline
In-Reply-To: <CAPWm=eVG1MFygACo6Mb6iLSe=GwjygTjjKhmN1Btu9Uyw+Vc-w@mail.gmail.com>
X-Hashcash: 1:28:160207:morcos@gmail.com::Ys/I+et0zPUKz/H7:8im4x
X-Hashcash: 1:28:160207:gavinandresen@gmail.com::7ex4zD76ZJT7xJnE:00000000000000
00000000000000000000000EM+pQ
X-Hashcash: 1:28:160207:bitcoin-discuss@lists.linuxfoundation.org::DQCHK5wSzU5eH
oN0:0000000000000000000DUMvZ
X-Hashcash: 1:28:160207:bitcoin-dev@lists.linuxfoundation.org::FpLiIUsqCKAKdTH0:
000000000000000000000009RXNR
X-Server-Quench: a7508d34-cdbb-11e5-bcde-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdgUUHlAWAgsB AmAbWlJeVVh7XGY7 bghPaBtcak9QXgdq
T0pMXVMcUQRvdlhC eXseVh16dA0IeXl2 bU4sD3deXEwudkJg
ERoGR3AHZDJldTJM BBVFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYA50 ekkVN1UKRl0CGmx0 ZhYJBzgmBkBNTSE0
JB9uMV8OEQ4VM0Az LRM9XhpCUVcXBwJX FVBRDTQx
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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-discuss@lists.linuxfoundation.org,
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: Sun, 07 Feb 2016 16:55:59 -0000
--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> And the back and forth discussion over your BIP has been in large part a
> charade. People asking why you aren't picking 95% know very well why you
> aren't, but lets have an honest discussion of what the risks and in your
Eh, lets not put words into people's mouths. I personally don't
understand why Gavin is using 75% in the manner that he is, given there
are many better alternatives, even if you don't think you can get ~100%
hashing power support.
> mind potential benefits of 75% are. Important debate about parameters of
> your BIP get lost because we're sniping at each other about known
> disagreements. For instance, I strongly believe 28 days is far too short.
Note that the grace period adds a significant amount of complexity to
the implementation; a much simpler alternative is to just use a hashing
power activated change with a very high threshold - 99% or so - with a
minimum activation date some point reasonably far into the future.
Also the way the grace period is implemented means that if support
*drops* after 75% is reached, the hardfork still activates (I haven't
actually tested this, so I may be misunderstanding the code). Obviously,
this is a dangerous situation, and an easy way for miners to "poison the
well" and disruptively force the fork to be rescheduled without actually
attacking the coin (nothing wrong with changing your mind! and pool
distribution may change anyway).
Again, a simple high % miner consensus fork with a reasonable minimum
activation time avoids all these problems, with far less code
complexity.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
00000000000000000711a9829e87ba8ea548f1793950893043a5dc56893dc1dc
--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWt3a6XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNzExYTk4MjllODdiYThlYTU0OGYxNzkzOTUwODkzMDQz
YTVkYzU2ODkzZGMxZGMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftypwf+MSi7oWkEqP+ZR9TcN4TtfCNV
tgSAbEZ0MnqcSS/1KcGGqKwDIuIMAFL4ORnOv2/CAPNx+aUU+lOQcd/xefhk0RpS
/kNoYI60/LvVpi08D46MBLo42iF0ExvXKLyfLxtWH7z71mld8zPWN7BmG9de+dsn
s1t0oYcjuNZVtQAC/oVUt3h+L5y7/qC8OqW7gFh9bGYzaPhIcqOXxS0IRKklImiC
amAEy4H5a1N12Ztm0x4qbEXRlcXj/gDsYyWdNI1yrCZBqqwh6ZNoGrfasWOs+lML
VLy4gS/Iiw0RhfRW3WVZ2amWBpe2fU67FTLaI4Y7hm+kdHbvEsVzO6+sy4oiHw==
=YphC
-----END PGP SIGNATURE-----
--8t9RHnE3ZwKMSgU+--
|
