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
|
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 47F86CDD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Dec 2015 16:40:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9FC98171
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Dec 2015 16:40:36 +0000 (UTC)
Received: by lfs39 with SMTP id 39so38580015lfs.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 09 Dec 2015 08:40:35 -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=g2WZxPQf2/e/t42w1k+vzVxEWcdXu/cSx6A66+w7+JM=;
b=tOGHkVEbdRpV3lcJDYiSEYH4+xS7iFHRnre5fdWJ2w3T5PNRIEVftQYiTMtFukJUad
4J6oavUEpKCNfYNKGdeq9UDH3eZDwum61dT1kpO0L2jIXwk2v4YRAOTbJ1P2HCD/2tBC
O85PXWQjSaPAH+wsm+QBG7CEae4Euzvz9S80qNhEqWs+jZX57LxFEyu0e0HC83OeEqfn
pw13zjLXUut2sZr3fkSV8L2El9jPTFxum6pqDQ2DJuAkAXC9wKbhHVgQ5Q5Sf60xFbrg
FaQss3ONDPKmfG/ztYz8SNyG16YM+5k8DFPrQqUFRIX6OClfKsx0C8LakamJJaJmny3W
cZ/A==
MIME-Version: 1.0
X-Received: by 10.25.27.147 with SMTP id b141mr2730644lfb.87.1449679234962;
Wed, 09 Dec 2015 08:40:34 -0800 (PST)
Received: by 10.25.22.95 with HTTP; Wed, 9 Dec 2015 08:40:34 -0800 (PST)
In-Reply-To: <CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@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>
Date: Wed, 9 Dec 2015 11:40:34 -0500
Message-ID: <CABsx9T1pLtOaGOVpVs8URAwpbb884htkrFLWtX8-2gGpS6gPWw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=001a11401350d6a136052679bfde
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 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: Wed, 09 Dec 2015 16:40:37 -0000
--001a11401350d6a136052679bfde
Content-Type: text/plain; charset=UTF-8
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
... where reserved_for_future_use is zero until some future block version
(or perhaps better, is just chosen arbitrarily by the miner and sent along
with the block data until some future block version).
That would minimize future disruption of any code that produced or consumed
merkle proofs of the transaction data or segwitness data, especially if the
reserved_for_future_use_root is allowed to be any arbitrary 256-bit value
and not a constant that would get hard-coded into segwitness-proof-checking
code.
--
--
Gavin Andresen
--001a11401350d6a136052679bfde
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <span dir=3D"lt=
r"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div id=3D":1lt" class=3D"a3s" style=3D"overflow:=
hidden">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 (such<br>
a hardfork was suggested in 2010 as something that could be done if<br>
merged mining was used), room for commitments to additional block<br>
back-references for compact SPV proofs, and/or UTXO set commitments.<br>
Part of the reason to not do it now is that the requirements for the<br>
other things that would be there are not yet well defined. For these<br>
other applications, the additional overhead is actually fairly<br>
meaningful; unlike the fraud proofs.<div class=3D"yj6qo ajU"><div id=3D":1m=
9" class=3D"ajR" tabindex=3D"0"></div></div></div></blockquote></div><br>So=
just design ahead for those future uses. Make the merkle tree:</div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div cl=
ass=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root_in=
_block_header</div><div class=3D"gmail_extra">=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\</di=
v><div class=3D"gmail_extra">=C2=A0 tx_data_root =C2=A0 =C2=A0 =C2=A0other_=
root</div><div class=3D"gmail_extra">=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 \</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0=
=C2=A0 segwitness_root =C2=A0 =C2=A0 reserved_for_future_use_root</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">... where rese=
rved_for_future_use is zero until some future block version (or perhaps bet=
ter, is just chosen arbitrarily by the miner and sent along with the block =
data until some future block version).</div><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra">That would minimize future disruption of a=
ny code that produced or consumed merkle proofs of the transaction data or =
segwitness data, especially if the reserved_for_future_use_root is allowed =
to be any arbitrary 256-bit value and not a constant that would get hard-co=
ded into segwitness-proof-checking code.</div><div class=3D"gmail_extra"><b=
r clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">--<br>=
Gavin Andresen<br></div><div class=3D"gmail_signature"><br></div>
</div></div>
--001a11401350d6a136052679bfde--
|
