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: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 65A0BD8E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 02:21:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
[209.85.213.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F73ECB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 02:21:23 +0000 (UTC)
Received: by mail-ig0-f169.google.com with SMTP id to4so1749321igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 18:21:23 -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=ffbkAZuekr+3WcY0LLsIsB0UMcxhDNFgLG+xaFsjU3Y=;
b=SO+Wvz9KkcZ/0nYASsbexCqXyJzPINr87/LWXRGXkncM/+YfIFBJyjJR6ks7GPsgbU
Z9mrjuaZEhGZDKuo3AVLS//BrrN45BbV1dcxkFNpA6Ohxajb0ZLxNrWL56B+3A5CVQba
bVupVOjIjGNw4DSNPWC2bJ6RWArqe9sEngP3XeHUbK+0RO8/vQQbo7weu7xiYNGUj5Ls
JPAbRJWtRY7IoQTy58sGU0hN+7+mc5LV0znMStgIH3BmlkRQql63jdiXgiM9Ajkz2cC5
ctIAMMbi05xIoBOUszXi3C+WvZW3M+TjR0WkATNfCj2KwOIPI+14MiQsUfYYEdkKmuC7
kN+A==
MIME-Version: 1.0
X-Received: by 10.50.36.105 with SMTP id p9mr1196351igj.54.1450318883031; Wed,
16 Dec 2015 18:21:23 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 18:21:22 -0800 (PST)
In-Reply-To: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
Date: Wed, 16 Dec 2015 21:21:22 -0500
Message-ID: <CADm_WcYdAHP95mrxH0CjvxKaV12rXEdBXf-L5QtKHuBL1ndFaQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=089e01176343d5907505270eadcc
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] Segregated Witness in the context of Scaling
Bitcoin
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: Thu, 17 Dec 2015 02:21:24 -0000
--089e01176343d5907505270eadcc
Content-Type: text/plain; charset=UTF-8
On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>
That's taking a big risk. "Build up some fee pressure" is essentially
risking a Fee Event if uptake is slower than planned, or traffic is greater
than expected.
>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>
A hard fork will never achieve 100% There are many credible folks and
estimates who feel a May hard fork is reasonable and doable.
Further, hard forks restore the full trustless nature of the post-hard-fork
nodes. Soft forks continually erode that. That's why SW should come via
hard fork. The end result is more secure - 100% validation of witness
transactions.
If regular hard fork plans are proposed in public, many months in advance,
there is plenty of time for the community to react. Hard forks create a
more predictable market and environment for Users, and a more secure
network.
Further, even if you believe SW makes hard fork unnecessary, it is the
responsible thing to code and communicate to users the plan for a Fee Event
just in case SW uptake and extension block use does not match theoretical
projections of SW proponents.
Finally, SW does not eliminate and is orthogonal to Short Term Problem #1
(orig. email - drift into ECE)
--089e01176343d5907505270eadcc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo <span dir=3D=
"ltr"><<a href=3D"mailto:lf-lists@mattcorallo.com" target=3D"_blank">lf-=
lists@mattcorallo.com</a>></span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>A large part =
of your argument is that SW will take longer to deploy than a hard fork, bu=
t I completely disagree. Though I do not agree with some people claiming we=
can deploy SW significantly faster than a hard fork, once the code is read=
y (probably a six month affair) we can get it deployed very quickly. It'=
;s true the ecosystem may take some time to upgrade, but I see that as a fe=
ature, not a bug - we can build up some fee pressure with an immediate rele=
ase valve available for people to use if they want to pay fewer fees.<br></=
div></blockquote><div><br></div><div>That's taking a big risk. =C2=A0&q=
uot;Build up some fee pressure" is essentially risking a Fee Event if =
uptake is slower than planned, or traffic is greater than expected.</div><d=
iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
On the other hand, a hard fork, while simpler for the ecosystem to upgrade =
to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5 f=
rom today if we all put off heads down and work). One thing that has concer=
ned me greatly through this whole debate is how quickly people seem to thin=
k we can roll out a hard fork. Go look at the distribution of node versions=
on the network today and work backwards to get nearly every node upgraded.=
.. Even with a year between fork-version-release and fork-activation, we=
9;d still kill a bunch of nodes and instead of reducing their security mode=
l, lead them to be outright robbed.<br></div></blockquote><div><br></div><d=
iv>A hard fork will never achieve 100% =C2=A0There are many credible folks =
and estimates who feel a May hard fork is reasonable and doable.</div><div>=
<br></div><div>Further, hard forks restore the full trustless nature of the=
post-hard-fork nodes.=C2=A0 Soft forks continually erode that.=C2=A0 That&=
#39;s why SW should come via hard fork.=C2=A0 The end result is more secure=
- 100% validation of witness transactions.</div><div><br></div><div>If reg=
ular hard fork plans are proposed in public, many months in advance, there =
is plenty of time for the community to react.=C2=A0 Hard forks create a mor=
e predictable market and environment for Users, and a more secure network.<=
/div><div><br></div><div>Further, even if you believe SW makes hard fork un=
necessary, it is the responsible thing to code and communicate to users the=
plan for a Fee Event just in case SW uptake and extension block use does n=
ot match theoretical projections of SW proponents.</div><div><br></div><div=
>Finally, SW does not eliminate and is orthogonal to Short Term Problem #1 =
(orig. email - drift into ECE)</div><div><br></div><div><br></div></div></d=
iv></div>
--089e01176343d5907505270eadcc--
|
