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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DAC37A1B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 23:59:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com
[209.85.213.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 432A7135
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 23:59:34 +0000 (UTC)
Received: by igcto18 with SMTP id to18so28744014igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2015 15:59:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type:content-transfer-encoding;
bh=CQngwCW9RjmpsFHCussEcuMYC9ymFhIhNJYahFIFJ9Q=;
b=I5YiNdX1xHIqjUcJMbMwe0dEHuaZ90Fx+HDWJHsMuE/rAAlomsjZxfAqg3qU45ATR9
U+EI+l0KZ+Z1dZmpr61lXpZz8s0GGb244oMCw3TulKWn9QL9Jat/qmXIyCieXUwAYdNb
FDf3LqfDpCRD7bWQJLbLzkCoxc9k0c7yGjQjs3VRr2LHca4uZQksJg7a/q76RhcP0BSC
GjhOwU3J17R4C6gxgEwOBqHw1DFGcwu9r842ZoAROHcdi7fVMwYEHp4UxYOL/5vgdTkF
3j7DrvzpJm37LvibcWOmfVd64CEs7kxXPrne0v1mq0SgeUGYlwDoE5QhSv/mCyNEL7QL
UtJw==
MIME-Version: 1.0
X-Received: by 10.50.134.2 with SMTP id pg2mr23177311igb.48.1449619173796;
Tue, 08 Dec 2015 15:59:33 -0800 (PST)
Sender: gmaxwell@gmail.com
Received: by 10.107.192.70 with HTTP; Tue, 8 Dec 2015 15:59:33 -0800 (PST)
In-Reply-To: <CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<20151208110752.GA31180@amethyst.visucore.com>
<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
Date: Tue, 8 Dec 2015 23:59:33 +0000
X-Google-Sender-Auth: aNQ7vDxIdfPrsFbWcZaHQGXudo8
Message-ID: <CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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] 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 23:59:35 -0000
On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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's nearly complexity-costless to put it in the coinbase transaction.
Exploring the costs is one of the reasons why this was implemented
first.
We already have consensus critical enforcement there, the height,
which has almost never been problematic. (A popular block explorer
recently misimplemented the var-int decode and suffered an outage).
And most but not all prior commitment proposals have suggested the
same or similar. The exact location is not that critical, however,
and we do have several soft-fork compatible options.
> It will also make any segwitness fraud proofs significantly larger (merkl=
e
> path versus merkle path to coinbase transactions, plus ENTIRE coinbase
> transaction, which might be quite large, plus merkle path up to root).
Yes, it will make them larger by log2() the number of transaction in a
block which is-- say-- 448 bytes.
With the coinbase transaction thats another couple kilobytes, I think
this is negligible.
From a risk reduction perspective, I think it is much preferable to
perform the primary change in a backwards compatible manner, and pick
up the data reorganization in a hardfork if anyone even cares.
I think thats generally a nice cadence to split up risks that way; and
avoid controversy.
> We also need to fix the O(n^2) sighash problem as an additional BIP for A=
NY
> blocksize increase.
The witness data is never an input to sighash, so no, I don't agree
that this holds for "any" increase.
> 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.
The fraud proof data is deterministic, full nodes could skip sending
it between each other, if anyone cared; but the overhead is pretty
tiny in any case.
> 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 positio=
n with
> respect to capacity in the near term"
>
> The heaviest users of the Bitcoin network (businesses who generate tens o=
f
> thousands of transactions per day on behalf of their customers) would
> strongly disgree; the current state of affairs is NOT acceptable to them.
My message lays out a plan for several different complementary
capacity advances; it's not referring to the current situation--
though the current capacity situation is no emergency.
I believe it already reflects the emerging consensus in the Bitcoin
Core project; in terms of the overall approach and philosophy, if not
every specific technical detail. It's not a forever plan, but a
pragmatic one that understand that the future is uncertain no matter
what we do; one that trusts that we'll respond to whatever
contingencies surprise us on the road to success.
|
