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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 915C8EDF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Feb 2016 16:55:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0AD610C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Feb 2016 16:55:04 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id m1so25624244lfg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 01 Feb 2016 08:55:04 -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=BGwpHQAEabSnlk+/oFOOIzbJO+3BwsDB0B1mmaLZkqw=;
b=oqptTRdtUEf8e94gS3zOxYdDFqiDdACPmX3wCuUJQmj9efI7N+ApBGRrYWwRkyfEoy
KlRFxR1GltJdKoGCQovjb/rNbAISi5sSxDquHFM+jtoI3Jw9YTOc/vIsjg+3XGnGK1nH
U7hwLJFjnFxYDoyMXsp3KqsXLD/X9KkN7/5DZEI62BS+aegkLoPJUTlPUjC/6AmSOdl0
/7McH7NQT8TIO7sMvjF4GnHzvQUTw10zZP46P7gu+dXcT+qUxREKvA//1z7Xj2jmlSJt
GUibx/mMnZ4s//OFfZVwA0xb06J4XR1YhERKNTat1qhShMT7mR2qv8zcy5d6G1V8+F78
Gv4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=BGwpHQAEabSnlk+/oFOOIzbJO+3BwsDB0B1mmaLZkqw=;
b=U4hsN7v8lGT2s9PF7V2ooWUIHyHnoRmgMD/Qrl5pzaeBM/byYvqXjuXdd5cCCWXaJI
O5NO/bczETQ35mFCaWaE8Aie8hM20A7lSmpDftnnu9krz51lD0XoC/Qzwc478HvEpHnq
CO7jjqql7wt6O5hfPGSfHd+DzEcdnMdxo+vqsVdewxxmlld+JG18qx6f9dDvNBmTyL+u
YYgElKdoIIenf8jc7vPgb6HR23s4PRPbv8bdL6vsyfThVJTbOOenEWjTpFxnRPcZGfeP
4mWh3QG5YgDG2flkyMO7UyskreRNaKL2eUje13iqCIy87AJs1hr4/Fi7kc6P2vTXDkAL
gU4w==
X-Gm-Message-State: AG10YOTGcS9O5wevikVDt7dFlZbKr81da74QD/e0CAEwPjW3jZfXCXBF7T7gRjQDsT3t7Ay1HsSlh7lznMTTdg==
MIME-Version: 1.0
X-Received: by 10.25.40.139 with SMTP id o133mr7256872lfo.10.1454345703178;
Mon, 01 Feb 2016 08:55:03 -0800 (PST)
Received: by 10.115.4.134 with HTTP; Mon, 1 Feb 2016 08:55:03 -0800 (PST)
In-Reply-To: <20160128185124.GA5140@savin.petertodd.org>
References: <20160128185124.GA5140@savin.petertodd.org>
Date: Mon, 1 Feb 2016 17:55:03 +0100
Message-ID: <CAPg+sBgH0SegmFemRPA1BdAjgM=u3SZK=FDkZkbpuobEUQ1YHw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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] Segwit Upgrade Procedures & Block Extension Data
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: Mon, 01 Feb 2016 16:55:05 -0000
On Thu, Jan 28, 2016 at 7:51 PM, Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> A few notes on upgrade procedures associated with segregated witnesses:
> While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for
> the above problem, the obvious thing to do is to add a new service bit
> such as NODE_SEGWIT, and/or bump the protocol version, and for outgoing
> peers only connect to peers with segwit support.
Agree, I've merged the changes to switch to a service bit instead.
We'll need further changes to prefer connecting to segwit nodes.
> Segwit isn't going to be the last thing that adds new block data. For
> example, my own prev-block-proof proposal(3) requires that blocks commit
> to another tree, which itself is calculated using a nonce that must be
> passed along with the block data. (U)TXO commitments are another
> possible future example.
> Unfortunately, this means that the next soft-fork upgrade to add
> additional data will have the above relaying problem all over again!
> Even a minimal upgrade adding a new commitment - like my
> prev-block-proof proposal - needs to at least add another nonce for
> future upgrades. In addition to having to upgrade full nodes, this also
> requires systems like the relay network to upgrade, even though they may
> not themselves otherwise need to care about the contents of blocks.
Those are good arguments for making the witness data more extensible.
>
> A more subtle implication of this problem is how do you handle parallel
> upgrades, as proposed by BIP9? Splitting the P2P network into
> non-upgraded nodes, and a much smaller group of upgraded nodes, is bad
> enough when done every once in a awhile. How does this look with more
> frequent upgrades, not necessarily done by teams that are working
> closely with each other?
I don't expect that changes that add more data to be relayed with
blocks will be frequent, though I certainly agree there may be some.
> Proposal: Unvalidated Block Extension Data
> ==========================================
(snip)
This will need a backward-incompatible change to the current segwit
change anyway, so at the risk of more bikeshedding, let me propose
going a bit further:
* The coinbase scriptSig gets a second number push (similar to the
current BIP34 height push), which pushes a number O. O is a byte
offset inside the coinbase transaction (excluding its witness data)
that points to a 32-byte hash H. This is more flexible and more
compact than what we have now (a suggestion by jl2012).
* H is the root of a Merkle tree, whose leaves are the hashes of the
coinbase witness's stack items.
* Item 0 of the coinbase witness stack must be 32 bytes, and must be
equal to the witness tree root.
* No further restrictions on the rest of the stack items; these can be
used for future commitments.
> A significant design consideration is that if arbitrary data can be
> added, it is very likely that miners will make use of that ability for
> non-Bitcoin purposes; we've already run into problems deploying segwit
> itself because of pools using the coinbase space for advertising and
> merge-mining. Avoiding this problem is easiest with a merkelized
> key:value mapping, with the ability to use collision-resistant ID's as
> keys (e.g. UUID).
I agree with the concern, but I don't really understand how this idea solves it.
--
Pieter
|
