summaryrefslogtreecommitdiff
path: root/fc/317e1c0f92af9bca52b054324377ff04e019f9
blob: 5997e7eda858bc926fa6ddf21d6e744954f579c8 (plain)
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
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1CA801000
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 17:45:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com
	[209.85.215.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 067C415A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 17:45:15 +0000 (UTC)
Received: by mail-lf0-f48.google.com with SMTP id l143so74817153lfe.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Feb 2016 09:45:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=nK9J+bJv+zARkRYdfbX6R3V5bsq3o78bLLjLjq5DxXY=;
	b=MfBtLny31YI93u3ZWnD6+I2nWr5Nq/zrAztdaZACZfq+8p8i9G31udXIJ01dJkNPt6
	Rz/ta9rQOYRTk3clRD/uUEJeilKg3mYWl7BldUxdek1m4JXlNCqF3pLtTd1nitsGZp42
	i/1jpSRYBMiVtXTkZOOpPIg7RZBAnC+WUonnr4b8bWzlPuAJOM+YF5CvUqHiCPC2HK3t
	i64LYqaPlPstNZ72Xb7CC5bgMGGgvn8AHLcwx++Dsvz4Q/ErgyoGOtAHiV8aU9pEYLRg
	iPZ0C2RkvO6uxR+Q8roqDvU8i8kua9DSi9sh7JgdxLOeCj3VrqJSRfvzjxgNw58lfvUW
	iT5Q==
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=nK9J+bJv+zARkRYdfbX6R3V5bsq3o78bLLjLjq5DxXY=;
	b=Y51Otzp1JQv9u1Txn9mvv/YYPElfKmWfwSvl/EGLQbqp1BZRQT0kHrhQr+X0aTBL7E
	6IVBROIw58XmmYVq49XXvjsXyl0J1LOV3Gr/WrrCv073BaSKbQ617WmtN8e6l8IJFNTY
	6+/O/3Iyq906nYSWlJBmYiN2L3uyHxTEDpe9HkkGjjGombboe299lGDUYR3UJgllqsyW
	yqdFudPe55cmWQuldLq0G0wvI7MA70u7eM9C/fEUIFZNfVXbuOxre6ByX5q170kTncqq
	E7foVSEUhImeYuNYyHEr2YrRSVwS4bQEfYI5d7qtK42zpInaJ96hFVciGgbqwnOf03Um
	lU8A==
X-Gm-Message-State: AG10YOR+j9I0CBTXYX566Zj9KxcYS6+NzBGB1D0EgpizYX8YVPiOuvezu26uQ24ib0sZDIMvCJkpy8z59bfS8A==
MIME-Version: 1.0
X-Received: by 10.25.43.20 with SMTP id r20mr8433433lfr.30.1454780714437; Sat,
	06 Feb 2016 09:45:14 -0800 (PST)
Received: by 10.25.206.68 with HTTP; Sat, 6 Feb 2016 09:45:14 -0800 (PST)
In-Reply-To: <CALqxMTGu1EtVxRYTxLBpE-0zWH59dnQa1zst9p9vdmbCckBjtQ@mail.gmail.com>
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>
Date: Sat, 6 Feb 2016 12:45:14 -0500
Message-ID: <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a114116bcb5d766052b1d8709
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
X-Mailman-Approved-At: Sat, 06 Feb 2016 17:46:16 +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: Sat, 06 Feb 2016 17:45:17 -0000

--001a114116bcb5d766052b1d8709
Content-Type: text/plain; charset=UTF-8

On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace.org> wrote:

>
> It would probably be a good idea to have a security considerations
> section


Containing what?  I'm not aware of any security considerations that are any
different from any other consensus rules change.

(I can write a blog post summarizing our slack discussion of SPV security
immediately after the first greater-than-1mb-block if you like).



> , also, is there a list of which exchange, library, wallet,
> pool, stats server, hardware etc you have tested this change against?
>

That testing is happening by the exchange, library, wallet, etc providers
themselves. There is a list on the Classic home page:

https://bitcoinclassic.com/


>
> 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).
>

The only voting in this BIP is done by the miners, and that cannot be faked.

Are you talking about people spinning up pseudo-full-nodes that fake the
user-agent?

As I said, there are people who have said they will spin up thousands of
full nodes to help prevent possible Sybil attacks which would become
marginally easier to accomplish immediately after the first >1mb block was
produced and full nodes that hadn't upgraded were left behind.

Would Blockstream be willing to help out by running a dozen or two extra
full nodes?

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?


> How do you plan to monitor and manage security through the hard-fork?
>

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.

-- 
--
Gavin Andresen

--001a114116bcb5d766052b1d8709
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 S=
at, Feb 6, 2016 at 12:01 PM, Adam Back <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><br>
It would probably be a good idea to have a security considerations<br>
section</blockquote><div><br></div><div>Containing what?=C2=A0 I&#39;m not =
aware of any security considerations that are any different from any other =
consensus rules change.</div><div><br></div><div>(I can write a blog post s=
ummarizing our slack discussion of SPV security immediately after the first=
 greater-than-1mb-block if you like).</div><div><br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">, also, is there a list of which exchange, library, wallet=
,<br>
pool, stats server, hardware etc you have tested this change against?<br></=
blockquote><div><br></div><div>That testing is happening by the exchange, l=
ibrary, wallet, etc providers themselves. There is a list on the Classic ho=
me page:</div><div><br></div><div><a href=3D"https://bitcoinclassic.com/">h=
ttps://bitcoinclassic.com/</a><br></div><div>=C2=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x">
<br>
Do you have a rollback plan in the event the hard-fork triggers via<br>
false voting as seemed to be prevalent during XT?=C2=A0 (Or rollback just<b=
r>
as contingency if something unforseen goes wrong).<br></blockquote><div><br=
></div><div>The only voting in this BIP is done by the miners, and that can=
not be faked.</div><div><br></div><div>Are you talking about people spinnin=
g up pseudo-full-nodes that fake the user-agent?</div><div><br></div><div>A=
s I said, there are people who have said they will spin up thousands of ful=
l nodes to help prevent possible Sybil attacks which would become marginall=
y easier to accomplish immediately after the first &gt;1mb block was produc=
ed and full nodes that hadn&#39;t upgraded were left behind.</div><div><br>=
</div><div>Would Blockstream be willing to help out by running a dozen or t=
wo extra full nodes?</div><div><br></div><div>I can&#39;t imagine any even-=
remotely-likely sequence of events that would require a rollback, can you b=
e more specific about what you are imagining?=C2=A0 Miners suddenly getting=
 cold feet?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">How do you plan to mon=
itor and manage security through the hard-fork?<br></blockquote><div><br></=
div><div>I don&#39;t plan to monitor or manage anything; the Bitcoin networ=
k is self-monitoring and self-managing. Services like <a href=3D"http://sta=
toshi.info">statoshi.info</a> will do the monitoring, and miners and people=
 and businesses will manage the network, as they do every day.</div><div><b=
r></div></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div>--<br>Gavin Andresen<br></div><div><br></div></div></div></=
div>
</div></div>

--001a114116bcb5d766052b1d8709--