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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E6CBCB37
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 02:44:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com
[209.85.220.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ACD816C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 02:44:47 +0000 (UTC)
Received: by mail-pa0-f51.google.com with SMTP id jx14so4918611pad.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 18:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version:content-type
:content-transfer-encoding:subject:from:date:to:cc:message-id;
bh=2VR1HMa2KzdYMLiS5acfJdb5123dSel+Vi3gkXMePnA=;
b=LPeQk9mbHPG1ReglnzcsZSFpJAium7IlJVoj31DWCndbst1Rc87gnzgEA8/S/y1kE/
2cJQV1JHVIxGgI/lZ7+X8K5k/1699CvwP9Xs3T7knJZP0hcmokYEToRN6fwDv2B/hsye
ZQDl7DdrzMFdL8uJ50buXH4myeneaa1ZwK8ML8ic/zKe1WxiY0GsRZLr3Laq64hipL67
NwHoCViYaQd1mWGjCt7D6aptjbO2JIXuLjbph+au76DE/fJAMDnbTYvHFHrmMzgoharr
YmLPQiMasDmG6czEYL47kITmdxuWTH27ghcA3SBa/p4hUPra39JWBzoyww6ETTRE/oxK
vp+g==
X-Received: by 10.66.232.170 with SMTP id tp10mr68889567pac.38.1450320286820;
Wed, 16 Dec 2015 18:44:46 -0800 (PST)
Received: from [172.31.99.24] ([4.16.104.187])
by smtp.gmail.com with ESMTPSA id
xz6sm11854721pab.42.2015.12.16.18.44.44
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 16 Dec 2015 18:44:46 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <CADm_WcYdAHP95mrxH0CjvxKaV12rXEdBXf-L5QtKHuBL1ndFaQ@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
<CADm_WcYdAHP95mrxH0CjvxKaV12rXEdBXf-L5QtKHuBL1ndFaQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----T3XGSWMD9HCEQPKRR1D88JZIX5M2II"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Wed, 16 Dec 2015 18:44:56 -0800
To: Jeff Garzik <jgarzik@gmail.com>,
Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <FC95D096-74AE-4B1C-B11B-1CB718538E7D@gmail.com>
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:44:48 -0000
------T3XGSWMD9HCEQPKRR1D88JZIX5M2II
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far.
At least SW *is* a scaling solution (albeit most of the important benefits are long term). The issue of fee events has nothing to do with scaling - it has to do with economics...specifically whether we should be subsidizing transactions, who should pay the bill for it, etc. My own personal opinion is that increasing validation costs works against adoption, not for it...even if it artificially keeps fees low - and we'll have to deal with a fee event sooner or later anyhow. You may disagree with my opinion, but please, let's stop confounding the economic issues with actual scaling.
On December 16, 2015 6:21:22 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>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)
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------T3XGSWMD9HCEQPKRR1D88JZIX5M2II
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far.<br>
<br>
At least SW *is* a scaling solution (albeit most of the important benefits are long term). The issue of fee events has nothing to do with scaling - it has to do with economics...specifically whether we should be subsidizing transactions, who should pay the bill for it, etc. My own personal opinion is that increasing validation costs works against adoption, not for it...even if it artificially keeps fees low - and we'll have to deal with a fee event sooner or later anyhow. You may disagree with my opinion, but please, let's stop confounding the economic issues with actual scaling.<br><br><div class="gmail_quote">On December 16, 2015 6:21:22 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo <span dir="ltr"><<a href="mailto:lf-lists@mattcorallo.com" target="_blank">lf-lists@mattcorallo.com</a>></span> wrote:<br /><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="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, 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.<br /></div></blockquote><div><br /></div><div>That's taking a big risk. "Build up some fee pressur
e"
is essentially risking a Fee Event if uptake is slower than planned, or traffic is greater than expected.</div><div><br /></div><div> </div><blockquote class="gmail_quote" style="margin: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 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.<br /></div></blockquote><div><br /></div><div>A hard fork will never achieve 100% There 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. Soft forks continually erode that. That's why SW should c
ome via
hard fork. The end result is more secure - 100% validation of witness transactions.</div><div><br /></div><div>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.</div><div><br /></div><div>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.</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></div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------T3XGSWMD9HCEQPKRR1D88JZIX5M2II--
|
