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
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EB1128ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 14:45:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f180.google.com (mail-io0-f180.google.com
[209.85.223.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 61CC51C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Aug 2015 14:45:39 +0000 (UTC)
Received: by ioii16 with SMTP id i16so19088057ioi.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Aug 2015 07:45:38 -0700 (PDT)
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=OxikNpD96DlvHj5JIB7r35VrlD8dsXMRzPuqytaPsv0=;
b=LVS5V9usTxETu7QcZ3rC7WSS90QOjQNh56rMBKwaW2HPtwjqRAWPEwuPUk7PeDsYcr
HO5NMReC5X0qPGs0KaS8M9eBcis0xBz9Zo77LIuZxPFb++eMhMcokVFRGyVRzWTEMIN6
wtF5c6NstxiVjynGKZuXPct3WXGOaZs7dls43EkRY11R3DHphorZSiTgPBYYM8lTNLfq
3gSmndCuyndi226BX+lqKU93LQ7PbP99Xqxt8D1n/BZnglRDXmpcYv52W0onlo9RGxK+
+CdLcs6cT1o2M++E1ZUZcid6xePlRuy4jXKT94PxOXCrbOzjoS1qi3zi/tcL00l+P+CF
psgA==
MIME-Version: 1.0
X-Received: by 10.107.3.224 with SMTP id e93mr4112069ioi.160.1438699538898;
Tue, 04 Aug 2015 07:45:38 -0700 (PDT)
Received: by 10.64.241.137 with HTTP; Tue, 4 Aug 2015 07:45:38 -0700 (PDT)
In-Reply-To: <CABsx9T1rN9j8dkFgEqw6dMYfwht8Z=WEzEObZx11XQ59SF4EiQ@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
<CAPg+sBjwVxYTOn3+bwahHGSGpBh5BCh5b4OOFkw_2x97YZSFPQ@mail.gmail.com>
<CA+w+GKS_wDDgf=HjPgD5QZ_wdTRg7i_oYUgBRmh9HpufETAP=w@mail.gmail.com>
<CABm2gDqvpWdHdjo1OBzbw-6ivu5DEGcfvK8duc3-KAjsSeWapA@mail.gmail.com>
<CA+w+GKRPPcgCO0pBP2PjKGU49tWuBoF1vRJzY+4fWn71HOVDPw@mail.gmail.com>
<CABm2gDqV1NdHJZBmUWX3AxVYy6ErU7AB-wsWgGzbiTL1twdq6g@mail.gmail.com>
<CA+w+GKTLBWj6b4ppwrmnXb_gybYFcrX7haLBSdCnMaijy2An4w@mail.gmail.com>
<CABm2gDpWPhYNh=g-ZXCsfe-aPq=N6NKSWKP9kr-KtPVrWAxB7Q@mail.gmail.com>
<CAAO2FKHsczkwwqO87cJFtxBp9JE=vf=GcxLx37GpRUkPq8VGHQ@mail.gmail.com>
<CAPg+sBjvzxGAPvk6PEhuxWzg00+krY_+goZbCLTWngvrCVCKvA@mail.gmail.com>
<CABsx9T1rN9j8dkFgEqw6dMYfwht8Z=WEzEObZx11XQ59SF4EiQ@mail.gmail.com>
Date: Tue, 4 Aug 2015 10:45:38 -0400
Message-ID: <CAPWm=eXmJJHf2FoEmMXD_D3RVBoTJRXbCy=_1J=eSLnpyzopuA@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a113df88ef46666051c7d56c0
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
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: Tue, 04 Aug 2015 14:45:40 -0000
--001a113df88ef46666051c7d56c0
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>
> As far as I can tell, nobody besides miners running old and/or buggy
> software lost money due to outsourced mining validation (please correct me
> if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
> bitcoin.org seem to have freaked out and pushed the panic button (with
> dire warnings of not trusting transactions until 20 confirmations), but
> theymos was well known for using an old, patched version of Core for
> blockexplorer.com so maybe that's not surprising.
>
>
I'm also looking forward to Greg's post-mortem, because I had a completely
different takeaway from the BIP66 mini-forks. My view is that despite the
extremely cautious and conservative planning for the completely
uncontentious fork, the damage could and would have been very significant
if it had not been for several core devs manually monitoring, intervening
and problem solving for other network participants. I don't believe thats
the way the system should work. Participants in the Bitcoin community have
come to rely on the devs for just making sure everything works for them.
That's not sustainable. The system needs to be made fundamentally more
secure if its going to succeed, not depend on the good will of any
particular parties, otherwise it certainly will no longer be permissionless.
The BIP66 fork was urgently required to fix an undisclosed consensus bug,
unanimously agreed on and without technical objection, and it was still
fraught with problems. That's the most clear cut example of when we should
have a fork. A change to a consensus limit that a significant proportion
of the community disagrees with for economic or technical reasons or both
should be raising a sea of red flags.
--001a113df88ef46666051c7d56c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><span class=3D"">On Tue, Aug 4, 2015 at 7:27 A=
M, Pieter Wuille via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
p dir=3D"ltr">I would say that things already demonstrately got terrible. T=
he mining landscape is very centralized, with apparently a majority dependi=
ng on agreements to trust each other's announced blocks without validat=
ion.</p></blockquote></span><div>And that is a problem... why?</div><div><b=
r></div><div>As far as I can tell, nobody besides miners running old and/or=
buggy software lost money due to outsourced mining validation (please corr=
ect me if I'm wrong-- I'm looking forward to Greg's post-mortem=
). The operators of <a href=3D"http://bitcoin.org" target=3D"_blank">bitcoi=
n.org</a> seem to have freaked out and pushed the panic button (with dire w=
arnings of not trusting transactions until 20 confirmations), but theymos w=
as well known for using an old, patched version of Core for <a href=3D"http=
://blockexplorer.com" target=3D"_blank">blockexplorer.com</a> so maybe that=
's not surprising.</div><div><br></div></div></div></div></blockquote><=
div><br></div><div>I'm also looking forward to Greg's post-mortem, =
because I had a completely different takeaway from the BIP66 mini-forks.=C2=
=A0 My view is that despite the extremely cautious and conservative plannin=
g for the completely uncontentious fork, the damage could and would have be=
en very significant if it had not been for several core devs manually monit=
oring, intervening and problem solving for other network participants.=C2=
=A0 I don't believe thats the way the system should work.=C2=A0 Partici=
pants in the Bitcoin community have come to rely on the devs for just makin=
g sure everything works for them.=C2=A0 That's not sustainable.=C2=A0 T=
he system needs to be made fundamentally more secure if its going to succee=
d, not depend on the good will of any particular parties, otherwise it cert=
ainly will no longer be permissionless.</div><div><br></div><div>The BIP66 =
fork was urgently required to fix an undisclosed consensus bug, unanimously=
agreed on and without technical objection, and it was still fraught with p=
roblems.=C2=A0 That's the most clear cut example of when we should have=
a fork.=C2=A0 A change to a consensus limit that a significant proportion =
of the community disagrees with for economic or technical reasons or both s=
hould be raising a sea of red flags.<br></div><div><br></div></div><br></di=
v></div>
--001a113df88ef46666051c7d56c0--
|
