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
|
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 44713B8F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 15:12:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EA64170
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 15:12:12 +0000 (UTC)
Received: by lbblt2 with SMTP id lt2so12800839lbb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2015 07:12:11 -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=5yTU/rDB+rPDCmZPrH7B99htFU+eV1GLwujPjA6M6Vo=;
b=sYZzdjAM2QHiVikHbQJLwE9xpTQXyrt0gBajl7YP9wFuMrii+7v3wePew2xfDgV5HC
qNMXH5pSFwsUat0/sGrErtvjzMCMOyKKx2Qjh9FSlLzrO5QMCMlQEP6Ao+/7PZH2+CkU
D62uPlW5oJNULvhOanIRHLv7etmAbavBuWIXlm87wsSOqRG1gYZXegmdReYBtNnpP+YA
ST2qw1UiQhg6I2ZN1UzdIs2NBa30BLTUWwitAcv2OLbB8YqD0+QXLf5Qn45PXV/lDyx/
AhMf8F7/6ubHAnRwbD9lZgQn0k1pZ39n90e2McTDnNwVswPT0h44j7o9iCglCr54YRYj
BFzw==
MIME-Version: 1.0
X-Received: by 10.112.54.229 with SMTP id m5mr158125lbp.125.1449587530815;
Tue, 08 Dec 2015 07:12:10 -0800 (PST)
Received: by 10.25.22.95 with HTTP; Tue, 8 Dec 2015 07:12:10 -0800 (PST)
In-Reply-To: <CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<20151208110752.GA31180@amethyst.visucore.com>
<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
Date: Tue, 8 Dec 2015 10:12:10 -0500
Message-ID: <CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c3fd1cd85f29052664658e
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
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
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, 08 Dec 2015 15:12:13 -0000
--001a11c3fd1cd85f29052664658e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for laying out a road-map, Greg.
I'll need to think about it some more, but just a couple of initial
reactions:
Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
coinbase is messy and will just complicate consensus-critical code (as
opposed to making the right side of the merkle tree in block.version=3D5
blocks the segwitness data).
It will also make any segwitness fraud proofs significantly larger (merkle
path versus merkle path to coinbase transactions, plus ENTIRE coinbase
transaction, which might be quite large, plus merkle path up to root).
We also need to fix the O(n^2) sighash problem as an additional BIP for ANY
blocksize increase. That also argues for a hard fork-- it is much easier to
fix it correctly and simplify the consensus code than to continue to apply
band-aid fixes on top of something fundamentally broken.
Segwitness will require a hard or soft-fork rollout, then a significant
fraction of the transaction-producing wallets to upgrade and start
supporting segwitness-style transactions. I think it will be much quicker
than the P2SH rollout, because the biggest transaction producers have a
strong motivation to lower their fees, and it won't require a new type of
bitcoin address to fund wallets. But it still feels like it'll be six
months to a year at the earliest before any relief from the current
problems we're seeing from blocks filling up.
Segwitness will make the current bottleneck (block propagation) a little
worse in the short term, because of the extra fraud-proof data. Benefits
well worth the costs.
------------------
I think a barrier to quickly getting consensus might be a fundamental
difference of opinion on this:
"Even without them I believe we=E2=80=99ll be in an acceptable position =
with
respect to capacity in the near term"
The heaviest users of the Bitcoin network (businesses who generate tens of
thousands of transactions per day on behalf of their customers) would
strongly disgree; the current state of affairs is NOT acceptable to them.
--=20
--
Gavin Andresen
--001a11c3fd1cd85f29052664658e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for laying out a road-map, Greg.<div><br></div><div=
>I'll need to think about it some more, but just a couple of initial re=
actions:</div><div><br></div><div>Why segwitness as a soft fork? Stuffing t=
he segwitness merkle tree in the coinbase is messy and will just complicate=
consensus-critical code (as opposed to making the right side of the merkle=
tree in block.version=3D5 blocks the segwitness data).</div><div><br></div=
><div>It will also make any segwitness fraud proofs significantly larger (m=
erkle path versus =C2=A0merkle path to coinbase transactions, plus ENTIRE c=
oinbase transaction, which might be quite large, plus merkle path up to roo=
t).</div><div><div><br></div><div><br></div><div>We also need to fix the O(=
n^2) sighash problem as an additional BIP for ANY blocksize increase. That =
also argues for a hard fork-- it is much easier to fix it correctly and sim=
plify the consensus code than to continue to apply band-aid fixes on top of=
something fundamentally broken.</div><div><br></div></div><div><br></div><=
div>Segwitness will require a hard or soft-fork rollout, then a significant=
fraction of the transaction-producing wallets to upgrade and start support=
ing segwitness-style transactions.=C2=A0 I think it will be much quicker th=
an the P2SH rollout, because the biggest transaction producers have a stron=
g motivation to lower their fees, and it won't require a new type of bi=
tcoin address to fund wallets.=C2=A0 But it still feels like it'll be s=
ix months to a year at the earliest before any relief from the current prob=
lems we're seeing from blocks filling up.</div><div><br></div><div>Segw=
itness will make the current bottleneck (block propagation) a little worse =
in the short term, because of the extra fraud-proof data.=C2=A0 Benefits we=
ll worth the costs.</div><div><br></div><div>------------------</div><div><=
br></div><div>I think a barrier to quickly getting consensus might be a fun=
damental difference of opinion on this:</div><div>=C2=A0 =C2=A0"<span =
style=3D"font-size:12.8px">Even without them I=C2=A0</span><span style=3D"f=
ont-size:12.8px">believe we=E2=80=99ll be in an acceptable position with re=
spect to capacity=C2=A0</span><span style=3D"font-size:12.8px">in the near =
term"</span><br></div><div class=3D"gmail_extra"><div><br></div><div>T=
he heaviest users of the Bitcoin network (businesses who generate tens of t=
housands of transactions per day on behalf of their customers) would strong=
ly disgree; the current state of affairs is NOT acceptable to them.</div><d=
iv><br></div><div><br></div><div><br></div>-- <br><div class=3D"gmail_signa=
ture">--<br>Gavin Andresen<br></div>
</div></div>
--001a11c3fd1cd85f29052664658e--
|
