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
|
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 44D3DEEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 21:12:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk
[62.13.149.55])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 29F1A2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Feb 2016 21:12:09 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u16LC4iZ039029;
Sat, 6 Feb 2016 21:12:04 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 u16LC19H052568
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 6 Feb 2016 21:12:02 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 0FC0540092;
Sat, 6 Feb 2016 21:08:47 +0000 (UTC)
Date: Sat, 6 Feb 2016 16:11:58 -0500
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20160206211158.GA14053@muck>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<201602060012.26728.luke@dashjr.org>
<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
<CALqxMTGu1EtVxRYTxLBpE-0zWH59dnQa1zst9p9vdmbCckBjtQ@mail.gmail.com>
<CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
In-Reply-To: <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
X-Server-Quench: 44d553a8-cd16-11e5-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgQUHlAWAgsB AmAbWVVeUV97WWA7 bghPaBtcak9QXgdq
T0pMXVMcUQRufW8A D2YeVxt3cQ0IeXh0 Z04sWnQPWUF5JE5g
ERpVE3AHZDJldWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYA50 ekkVN1UKRl0CGmx0 ZhYJBzgmBkBNTSE0
JB9uMV8OEQ4VM0Az LRM9XhpCUVcXBwJX FVBRDTQx
X-Authentic-SMTP: 61633532353630.1037: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 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: Sat, 06 Feb 2016 21:12:11 -0000
--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wr=
ote:
> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace.org> wrote:
>=20
> >
> > It would probably be a good idea to have a security considerations
> > section
>=20
>=20
> Containing what? I'm not aware of any security considerations that are a=
ny
> different from any other consensus rules change.
I covered the security considerations unique to hard-forks on my blog:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
> > , also, is there a list of which exchange, library, wallet,
> > pool, stats server, hardware etc you have tested this change against?
> >
>=20
> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>=20
> https://bitcoinclassic.com/
How do we know any of this testing is actually being performed? I don't
currently know of any concrete testing actually done.
> > Do you have a rollback plan in the event the hard-fork triggers via
> > false voting as seemed to be prevalent during XT? (Or rollback just
> > as contingency if something unforseen goes wrong).
> >
>=20
> The only voting in this BIP is done by the miners, and that cannot be fak=
ed.
Are you unaware of Not Bitcoin XT?
https://bitcointalk.org/index.php?topic=3D1154520.0
> I can't imagine any even-remotely-likely sequence of events that would
> require a rollback, can you be more specific about what you are imagining?
> Miners suddenly getting cold feet?
See above.
Also, as the two coins are separate currencies and can easily trade
against each other in a 75%/25% split, it would be easy for the price to
diverge and hashing power to move.
In fact, I've been asked multiple times now by exchanges and other
players in this ecosystem for technical advice on how to split coins
across the chains effectively (easily done with nLockTime). Notably, the
exchanges who have asked me this - who hold customer funds on their
behalf - have informed me that their legal advice was that the
post-hard-fork coins are legally speaking separate currencies, and
customers must be given the opportunity to transact in them separately
if they choose too. Obviously, with a 75%/25% split, while block times
on the other chain will be slower, the chain is still quite useful and
nearly as secure as the main chain against 51% attack; why I personally
have suggested a 99% threshold:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.=
html
(remember that the threshold can always be soft-forked down)
It's also notable that millions of dollars of Bitcoin are voting agsast
the fork on the proof-of-stake voting site Bitcoinocracy.com While
obviously not comprehensive, the fact that a relatively obscure site
like it can achieve participation like that, even without an easy to use
user friendly interface.
> > How do you plan to monitor and manage security through the hard-fork?
> >
>=20
> I don't plan to monitor or manage anything; the Bitcoin network is
> self-monitoring and self-managing. Services like statoshi.info will do the
> monitoring, and miners and people and businesses will manage the network,
> as they do every day.
Please provide details on exactly how that's going to happen.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWtmGbXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwODMyMDg3NDg0M2YyODJmNTU0YWEyNDM2MjkwNjQyZmNm
YTgxZTVhMDFkNzg2OTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyH2gf/WfhKYbr/Wq6dIf6iuOML4/KH
KBTYVfWM5vUqL04Iz23KY+aj84uc+RxFY23KsSkrxwPdT96uRMV7DZnvb3uofoff
gTQ5pLvRagU73EFJ/0b8+D7Wj29DeG1tmuHK7wcG0BwMY8O18M0g3sM2Ilwo5Gh1
De/hZnT5H1Xk95na8JsKslNTNCLHABr6+vmYUS+tgMwtyzSLIWmyYpmHZ+6V0Kvm
biMWwXzL4b8b6Lv5aTsvfh2AbieT8qk6CT3njL8pB4SJEJynTwna+DX8ObwuWmmP
XInCxN2gcYZrPRh6VgdGF8x2T3rLVPlkLjz3Z6qaDSa2s4YVXZooVOYHttUMBA==
=R7NX
-----END PGP SIGNATURE-----
--6TrnltStXW4iwmi0--
|
