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
|
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 44A1B1001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 17:09:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com
[209.85.215.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9ECE72F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 17:09:48 +0000 (UTC)
Received: by mail-lf0-f43.google.com with SMTP id 78so83266406lfy.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Feb 2016 09:09:48 -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
:content-type; bh=KYdiV/c2SJdrJe0YNTAVNbw/9Pzq09puJ/abbBWEu9c=;
b=r4WQlgTXLxqub0gc8bXyZ1vS4GDxX/qWGc4uSSiJ7CVejDS5nZwTzng3k9YRjvj/TZ
2pyLH8msqaBIBct+2/q417Jl9OJNqn/YcP/fdhR7Id7RWemnJs++1IrC6L3MNpo3BbYw
n1A0Cp0CX8A9Bwq5X5BRodnlgco8F94LTWLIsw1mct7YWg4q4PkLaqS5twF8dCkCJIus
hbnTsZqpYQAVTWUBOPWYsSgW6mx1wZwUCVwVgxh7/EDeMp6HJm+6X47x6T1irtBuyWJY
9+io7EFid4nWe9GP5/Dj+HjBBoDovtVgFy84L+0SoqnlzyO8scAMmKew+pvC+85j8zSy
3L9w==
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:content-type;
bh=KYdiV/c2SJdrJe0YNTAVNbw/9Pzq09puJ/abbBWEu9c=;
b=Wgxf5hiVwjCuQ8qLvdp9VNoI2FdBIHKV3fIaQbC4SVpuDc+skhOyxmjU1K2r+B+W3Q
nEM1QgpgyW10pQYyAgQUpHKPXiZL8SYtqrNqYOpoT4mQjWMuDxirredtzzEqj5tjMIjg
BcPk0zBxeuxkMdvo8byM+9fhzmrU8iuADgWOIL2o6NThlZyX21BA8T5yDYBtiX3YWVb/
fxxf9/yk2p8aaAfYPzkw/1STkE4yGS5g99tn20HILDVbu3HP+TB5OhXhblP4s3afdsIf
+jdglikUgGczPjeS1qlldmnDkjcQsqF0Ai2GWZlvl8jWb4nUISAiruZON9l4AcbAu08h
x+3w==
X-Gm-Message-State: AG10YOTT4dGgmcXBfDkE2NvrfiTVdrPJlTSoZg2KEfq3imM8Ru/QJHSi5esl5PU6b0JsBFgkqTVC4L6rnUwDmA==
MIME-Version: 1.0
X-Received: by 10.25.213.134 with SMTP id m128mr9905878lfg.87.1454864987135;
Sun, 07 Feb 2016 09:09:47 -0800 (PST)
Received: by 10.25.206.68 with HTTP; Sun, 7 Feb 2016 09:09:46 -0800 (PST)
In-Reply-To: <CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com>
Date: Sun, 7 Feb 2016 12:09:46 -0500
Message-ID: <CABsx9T0nXVUqZOfH0izsEwv3oU85GKmt8RLgLfXXZk5S-N1OZA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11420fbac124f1052b3126ee
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: Sun, 07 Feb 2016 17:19:43 +0000
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 17:09:51 -0000
--001a11420fbac124f1052b3126ee
Content-Type: text/plain; charset=UTF-8
As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.
I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."
Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer. I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
http://gavinandresen.ninja/minority-branches
... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.
All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.
As for the argument that creating and testing a patch for Core would take
longer than 28 days:
The glib answer is "people should just run Classic, then."
A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.
That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.
--
--
Gavin Andresen
--001a11420fbac124f1052b3126ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">As I feared, request on feedbac=
k for this specific BIP has devolved into a general debate about the merits=
of soft-forks versus hard-forks (versus semi-hard Kosher Free Range forks.=
..).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I=
've replied to several people privately off-list to not waste people=
9;s time rehashing arguments that have been argued to death in the past.</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I do wan=
t to briefly address all of the concerns that stem from "what if a sig=
nificant fraction of hashpower (e.g. 25%) stick with the 1mb branch of the =
chain."</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">Proof of work cannot be spoofed. If there is very little (a few perc=
ent) of hashpower mining a minority chain, confirmations on that chain take=
orders of magnitude longer.=C2=A0 I wrote about why the incentives are ext=
remely strong for only the stronger branch to survive here:</div><div class=
=3D"gmail_extra">=C2=A0<a href=3D"http://gavinandresen.ninja/minority-branc=
hes">http://gavinandresen.ninja/minority-branches</a></div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">... the debate about whethe=
r or not that is correct doesn't belong here in bitcoin-dev, in my humb=
le opinion.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">All of the security concerns I have seen flow from an assumption that=
significant hashpower continues on the weaker branch. The BIP that is unde=
r discussion assumes that analysis is correct. I have not seen any evidence=
that it is not correct; all experience with previous forks (of both Bitcoi=
n and altcoins) is that the stronger branch survives and the weaker branch =
very quickly dies.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><div><br></div><div>As for the argument that creating and test=
ing a patch for Core would take longer than 28 days:</div><div><br></div><d=
iv>The glib answer is "people should just run Classic, then."</di=
v><div><br></div><div>A less glib answer is it would be trivial to create a=
patch for Core that accepted a more proof-of-work chain with larger blocks=
, but refused to mine larger blocks.</div><div><br></div><div>That would be=
a trivial patch that would require very little testing (extensive testing =
of 8 and 20mb blocks has already been done), and perhaps would be the best =
compromise until we can agree on a permanent solution that eliminates the a=
rbitrary, contentious limits.</div><div><br></div>-- <br><div class=3D"gmai=
l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Gavin Andres=
en<br></div><div><br></div></div></div></div></div>
</div></div>
--001a11420fbac124f1052b3126ee--
|
