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
198
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A507CE22
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 05:11:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2BACE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 05:11:48 +0000 (UTC)
Received: by mail-ig0-f180.google.com with SMTP id to18so27354203igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 21:11: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
:cc:content-type;
bh=aex761AUiCLaeJBUTpmr5obGzCQAM3E4hcZqkh+Y7qM=;
b=Pvr8OMduwA4Y5G07D26ZE6Q9Z/NyIVwTOStDqWp0M40ckfbHkBWyrR1d0dgGwVJFSR
uSuwYv4wbqFkXyjN1BU4eTca3nPMHSrY+wZXopDoyKRGCHSpDCqisC2sz4EyDDn88vgS
MfiSdZFDheVKUaxv3cn93ThONuGOnVQ0q9Qmr0cBRu1QYlu4KtSLbas80YptKn6bKbWd
Q2M7yaN7V2Y0gdH4xKW8sXQsuQIuzpX2JPIC5ohnatklAx8EgWGwJpQjUqixnu13V5pz
HVLin73T5BX4qt9Av9qBFs4Km0IMyDWGbSlByq/opRJGrPhhlIO0Y9BWKP0egIOt8UwN
v1Vw==
MIME-Version: 1.0
X-Received: by 10.50.36.105 with SMTP id p9mr741076igj.54.1450415508325; Thu,
17 Dec 2015 21:11:48 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Thu, 17 Dec 2015 21:11:48 -0800 (PST)
In-Reply-To: <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
Date: Fri, 18 Dec 2015 00:11:48 -0500
Message-ID: <CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=089e01176343268d5e0527252d3b
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 development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
moral hazard
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: Fri, 18 Dec 2015 05:11:49 -0000
--089e01176343268d5e0527252d3b
Content-Type: text/plain; charset=UTF-8
On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.
1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.
2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.
There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption. Users of the Service can still drift randomly
and unpredictably into a Fee Event.
SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear
Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.
As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
--089e01176343268d5e0527252d3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <span dir=
=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">p=
ieter.wuille@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><span class=3D"">On Wed, Dec 16=
, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> 2) If block size stays at 1M, the Bitcoin Core developer team should s=
ign a<br>
> collective note stating their desire to transition to a new economic p=
olicy,<br>
> that of "healthy fee market" and strongly urge users to exam=
ine their fee<br>
> policies, wallet software, transaction volumes and other possible User=
<br>
> impacting outcomes.<br>
<br>
</span>You present this as if the Bitcoin Core development team is in charg=
e<br>
of deciding the network consensus rules, and is responsible for making<br>
changes to it in order to satisfy economic demand. If that is the<br>
case, Bitcoin has failed, in my opinion.<br></blockquote><div><br></div><di=
v>Diverging from the satoshi block size change plan[1] and current economic=
s would seem to require a high level of months-ahead communication to users=
.</div><div><br></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;padding-left:1ex">
all. Yes, old full nodes after a soft fork are not able to fully<br>
validate the rules new miners enforce anymore, but they do still<br>
verify the rules that their operators opted to enforce. Furthermore,<br>
they can't be prevented. For that reason, I've proposed, and am<br>
working hard, on an approach that includes Segregated Witness as a<br>
first step. It shows the ecosystem that something is being done, it<br>
kicks the can down the road, it solves/issues half a dozen other<br>
issues at the same time, and it does not require the degree of<br>
certainty needed for a hardfork.<br></blockquote><div><br></div><div></div>=
</div></div><div class=3D"gmail_extra">Segregated Witness does not kick the=
can, it solves none of the problems #1, #3 - #8 explicitly defined and lis=
ted in email #1.</div><div class=3D"gmail_extra"><br></div><div class=3D"gm=
ail_extra">1) =C2=A0A plan of "SW + no hard fork" is gambling wit=
h ECE risk, gambling there will be no Fee Event, because the core block siz=
e is still heavily contended -- 100% contended at time out SW rollout.</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) We are =
only 100% certain that bitcoin works in the blocks-not-full-on-avg state, w=
here there is a healthy buffer between the hard limit and the average block=
size.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>There is remains major ECE risk due to the core block size freeze, possibl=
y pushing the system into a new, untried economic state and causing major m=
arket and actor disruption.=C2=A0 Users of the Service can still drift rand=
omly and unpredictably into a Fee Event.</div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra">SW mitigates this</div><div class=3D"gma=
il_extra">- only after several months</div><div class=3D"gmail_extra">- onl=
y assuming robust adoption rates by up-layer ecosystem software, and=C2=A0<=
/div><div class=3D"gmail_extra">- only assuming transaction volume growth i=
s flat or sub-linear</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">Those conditions=C2=A0<i style=3D"font-weight:bold">must</=
i>=C2=A0go as planned to fulfill "SW kicked the can" -- a lot of =
if's.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">As stated, SW is orthogonal to the drift-into-uncharted-waters problem =
outlined in email #1, which a short term bump does address.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div></div>
--089e01176343268d5e0527252d3b--
|
