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
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CF63ED0E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 16:18:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com
[209.85.213.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0BC6F143
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 16:18:49 +0000 (UTC)
Received: by vkha189 with SMTP id a189so118562789vkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 08:18:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=F/pOk1gam2+89c2y3/rBZdpzqdhOXQmnH+RXZnkjnaU=;
b=qQVEsDgNq/VPVohMCooCMBO34C8FmPHZHkdr21nqWRZ6pLieg6ItcMMUCHc/kCCzwN
xKb1aKQ6a07ZDN3lOgAgIe84/FMgJwi6u1Srd8mcnJPVepiTROdNXAjjaUEoxVJLTS/i
zd7OaJccSd0qYMon/3O2fG6dmayfDmIe0lkLrJeEbMvyO9VBsTxk9I0kUAl7+msLvmO5
fTlC0LhXQBSynoBIVHbFvNNWne+QUohz27n153+Zxo3GBEh6I8wvhaSDAj5BaF+5e8CI
XglYDe1fTOqjaiuDuGhqiJIoJ1kHB42nb6Wd9c/NSCZqZ7G6cG0LG53IzR70g9XU4wsf
9R+Q==
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=F/pOk1gam2+89c2y3/rBZdpzqdhOXQmnH+RXZnkjnaU=;
b=gJGlY2UoDTWeG0VbjPEA+gTeiTyXrfcjoz5ApP+KqF2Q/Oc1D8lx/zTXUbc0nVXnL+
b5w5DECGSHZZlXHQYjbk/9+uEecY0JsbWEfG99YZjCI7C1z7yx/6+xl0IDLBcdFPrQ5t
RslEdfZI6+RiKMOcCdSnMtK/z/HKqXyPWOJHMVHGH1hXNWISngXcbLbnL7kYmqcArfmp
4XOEE8tSyd6P3N5kR7jKK9lZ2pDUF+tF6bPztBbNJfNCXC/zrOAq5BlqeF8K+rvNbO02
7pP4iXaR04hDp1VHG7lgje8wMKEsPoYRaKNZWLAN4X3ZD6K0DHbZakjyxYMkB44UVWoi
u9MA==
X-Gm-Message-State: ALoCoQlaDapb9xzaG6dyzB5hONPxpTyr3V4dPriBr6SB/N29d6/QwskPzlzIHd9RZRgwJ1OCf6KsQ9Omz6U1Oh+yq9+h/6ke9A==
MIME-Version: 1.0
X-Received: by 10.31.140.199 with SMTP id o190mr14959567vkd.63.1449850729241;
Fri, 11 Dec 2015 08:18:49 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Fri, 11 Dec 2015 08:18:48 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Fri, 11 Dec 2015 08:18:48 -0800 (PST)
In-Reply-To: <CABsx9T1pLtOaGOVpVs8URAwpbb884htkrFLWtX8-2gGpS6gPWw@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>
<CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com>
<CABsx9T1i50Gvxj18W=n2mYGNpsMrSkDT26CdA3aQqT5FFN86yw@mail.gmail.com>
<CAAS2fgSxpSat3VOje3-C4zgaRUVJVx-eRJbSYJqhvfR5SvCDwA@mail.gmail.com>
<CAF_2MyUJMdJyh7FKq6UYCtwJZQ59i-pnWT_tFEK5EQx65iwHDQ@mail.gmail.com>
<CAAS2fgS-jjEVeHf_LErppTadtAaSeBum+KiGHpoo=Jz5BZArsQ@mail.gmail.com>
<CABm2gDq4f0ettDhh14jZ0zztSwSJ0Z=KDEeMTOJxTHF8VV+KXw@mail.gmail.com>
<CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@mail.gmail.com>
<CABsx9T1pLtOaGOVpVs8URAwpbb884htkrFLWtX8-2gGpS6gPWw@mail.gmail.com>
Date: Fri, 11 Dec 2015 17:18:48 +0100
Message-ID: <CABm2gDp4+V2-Gu3XTcmRxFy_KCfxrptjhmXBxjf04Kdi5Bf+2A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=001a11425b20b1b19c0526a1adad
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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 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: Fri, 11 Dec 2015 16:18:50 -0000
--001a11425b20b1b19c0526a1adad
Content-Type: text/plain; charset=UTF-8
On Dec 9, 2015 5:40 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> I think it would be logical to do as part of a hardfork that moved
>> commitments generally; e.g. a better position for merged mining (such
>> a hardfork was suggested in 2010 as something that could be done if
>> merged mining was used), room for commitments to additional block
>> back-references for compact SPV proofs, and/or UTXO set commitments.
>> Part of the reason to not do it now is that the requirements for the
>> other things that would be there are not yet well defined. For these
>> other applications, the additional overhead is actually fairly
>> meaningful; unlike the fraud proofs.
>
>
> So just design ahead for those future uses. Make the merkle tree:
>
>
> root_in_block_header
> / \
> tx_data_root other_root
> / \
> segwitness_root reserved_for_future_use_root
This is basically what I meant by
struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}
but my design doesn't calculate other_root as it appears in your tree (is
not necessary).
Since stop requiring bip34 (height in coinbase) is also a hardfork (and a
trivial one) I suggested to move it at the same time. But thinking more
about it, since BIP34 also elegantly solves BIP30, I would keep the height
in the coinbase (even if we move it to the extented header tree as well for
convenience).
That should be able to include future consensus-enforced commitments (extra
back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus
data (merged mining data, miner-published data).
Greg Maxwell suggested to move those later and I answered fair enough. But
thinking more about it, if the extra commitments field is extensible, we
don't need to move anything now, and therefore we don't need for those
designs (extra back-refs for compact proofs, txo/utxo commitments, etc) to
be ready to deploy a hardfork segregated witness: you just need to make
sure that your format is extensible via softfork in the future.
I'm therefore back to the "let's better deploy segregated witness as a
hardfork" position.
The change required to the softfork segregated witnesses implementation
would be relatively small.
Another option would be to deploy both parts (sw and the movement from the
coinbase to the extra header) at the same time but with different
activation conditions, for example:
- For sw: deploy as soon as possible with bip9.
- For the hardfork codebase to extra header movement: 1 year grace + bip9
for later miner upgrade confirmation.
--001a11425b20b1b19c0526a1adad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Dec 9, 2015 5:40 PM, "Gavin Andresen" <<a href=3D"mailto:ga=
vinandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br>
><br>
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:<br>
>><br>
>> I think it would be logical to do as part of a hardfork that moved=
<br>
>> commitments generally; e.g. a better position for merged mining (s=
uch<br>
>> a hardfork was suggested in 2010 as something that could be done i=
f<br>
>> merged mining was used), room for commitments to additional block<=
br>
>> back-references for compact SPV proofs, and/or UTXO set commitment=
s.<br>
>> Part of the reason to not do it now is that the requirements for t=
he<br>
>> other things that would be there are not yet well defined. For the=
se<br>
>> other applications, the additional overhead is actually fairly<br>
>> meaningful; unlike the fraud proofs.<br>
><br>
><br>
> So just design ahead for those future uses. Make the merkle tree:<br>
><br>
><br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root_in_block_header<b=
r>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0/ =C2=A0 =C2=A0 =C2=A0\<br>
> =C2=A0 tx_data_root =C2=A0 =C2=A0 =C2=A0other_root<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2=A0 =C2=A0 \<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 segwitness_root =C2=A0 =C2=A0 reserved_for=
_future_use_root</p>
<p dir=3D"ltr">This is basically what I meant by</p>
<p dir=3D"ltr">struct hashRootStruct<br>
{<br>
uint256 hashMerkleRoot;<br>
uint256 hashWitnessesRoot;<br>
uint256 hashextendedHeader;<br>
}</p>
<p dir=3D"ltr">but my design doesn't calculate other_root as it appears=
in your tree (is not necessary).</p>
<p dir=3D"ltr">Since stop requiring bip34 (height in coinbase) is also a ha=
rdfork (and a trivial one) I suggested to move it at the same time. But thi=
nking more about it, since BIP34 also elegantly solves BIP30, I would keep =
the height in the coinbase (even if we move it to the extented header tree =
as well for convenience).<br>
That should be able to include future consensus-enforced commitments (extra=
back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus =
data (merged mining data, miner-published data).<br>
Greg Maxwell suggested to move those later and I answered fair enough. But =
thinking more about it, if the extra commitments field is extensible, we do=
n't need to move anything now, and therefore we don't need for thos=
e=C2=A0 designs (extra back-refs for compact proofs, txo/utxo commitments, =
etc) to be ready to deploy a hardfork segregated witness: you just need to =
make sure that your format is extensible via softfork in the future.</p>
<p dir=3D"ltr">I'm therefore back to the "let's better deploy =
segregated witness as a hardfork" position.<br>
The change required to the softfork segregated witnesses implementation wou=
ld be relatively small.</p>
<p dir=3D"ltr">Another option would be to deploy both parts (sw and the mov=
ement from the coinbase to the extra header) at the same time but with diff=
erent activation conditions, for example:</p>
<p dir=3D"ltr">- For sw: deploy as soon as possible with bip9.<br>
- For the hardfork codebase to extra header movement: 1 year grace + bip9 f=
or later miner upgrade confirmation.<br>
</p>
--001a11425b20b1b19c0526a1adad--
|
