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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B8D3D4A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Dec 2015 08:46:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 339EB149
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Dec 2015 08:46:51 +0000 (UTC)
Received: by ioc74 with SMTP id 74so51768452ioc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 09 Dec 2015 00:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=o+VJsUR/PU/URKY4tCd1i7eydj7kF3EoXkU990mzM4I=;
b=0kHJH+UMgM2HB+JzeAsolSlhyV2WGMMFmZCZWfN7P0iPcHJ7aWksfb3ypcKD5sRoH3
6ZRi1C/H352xrESS2eNqton1V7/czazGPBhsyFNASNsrNQc2dzr9gVspdfeMCtS60qTf
phipr9DYqc8c/k1u51k7uKhmJhDc2CPBlGedJgjzVpsRM6DS5Bha5J/KHsnmxFCogSCz
XirbPzjvG6Njo4/bN5UaLGYkNR58mCSwc+9VtZRrXCsK/oFVj0a6URQAlw3VLlI6aQSE
9NCBWW+omXXnLPlNr8tPHYWmyPfGo9oNFsBui1W3VcC4GbweKDCEIZg4T0Ac/fSZTsy9
G5LQ==
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:from:date
:message-id:subject:to:cc:content-type;
bh=o+VJsUR/PU/URKY4tCd1i7eydj7kF3EoXkU990mzM4I=;
b=G6z+MwIgpAyU16L5BRrB4PmpjFWT0JaZ+xIxMQV8J4BH7RriukzYRX4KW/rNpg1McH
EkwUiUSHvcgfd3MJgqexQmUjfn9oIdbwALKusQ9Ebo/WjslVEKCsw5exUv/pfLBDxxNk
+5usG1gs+vG7HADXtTmamC+Yfzf/hD1djXvS4O7uCdLtmU4hm6NPd/8szS7N1QxIrIit
Ycg5pGED6m8K7BeOLqtV/FPy+yRghzB5nv79lxcJZh9nFvBwVP0dBnqhLBT655ii6dz4
beX/BVBV+oHsbwa9AHpWON59ZZCYVxEhDzNrPzYMIp6KOxyhmkPQfum196UVc6rpln7Z
NhLA==
X-Gm-Message-State: ALoCoQlK/FVThU8odBB4Iu4SYdsjqRF8dYlL+8MzZgVeFzyNVbHxliGcoLvxf0NhPCt9QWizagb9pdvkAOGAeGVOW5m9TdqWLQ==
X-Received: by 10.107.44.81 with SMTP id s78mr4814735ios.159.1449650810617;
Wed, 09 Dec 2015 00:46:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.133.217 with HTTP; Wed, 9 Dec 2015 00:46:31 -0800 (PST)
X-Originating-IP: [202.83.241.113]
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>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Wed, 9 Dec 2015 16:46:31 +0800
Message-ID: <CAOG=w-vgY_6JwRYjoSnYjfULu0hspwC1E0uccB_--OHgoZd96A@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary=001a113971609d94e9052673218b
X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB,
URIBL_BLACK autolearn=no 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 08:46:52 -0000
--001a113971609d94e9052673218b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
My apologies for the apparent miscommunication earlier. It is of interest
to me that the soft-fork be done which is necessary to put a commitment in
the most efficient spot possible, in part because that commitment could be
used for other data such as the merged mining auxiliary blocks, which are
very sensitive to proof size.
Perhaps we have a different view of how the commitment transaction would be
generated. Just as GBT doesn't create the coinbase, it was my expectation
that it wouldn't generate the commitment transaction either -- but
generation of the commitment would be easy, requiring either the coinbase
txid 100 blocks back, or the commitment txid of the prior transaction (note
this impacts SPV mining). The truncation shouldn't be an issue because the
commitment txn would not be part of the list of transactions selected by
GBT, and in any case the truncation would change the witness data which
changes the commitment.
On Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 9, 2015 at 7:54 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
> > From this question one could think that when you said "we can do the
> > cleanup hardfork later" earlier you didn't really meant it. And that
> > you will oppose to that hardfork later just like you are opposing to
> > it now.
> > As said I disagree that making a softfork first and then move the
> > commitment is less disruptive (because people will need to adapt their
> > software twice), but if the intention is to never do the second part
> > then of course I agree it would be less disruptive.
> > How long after the softfork would you like to do the hardfork?
> > 1 year after the softfork? 2 years? never?
>
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113971609d94e9052673218b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>My apologies for the apparent miscommunication earlie=
r. It is of interest to me that the soft-fork be done which is necessary to=
put a commitment in the most efficient spot possible, in part because that=
commitment could be used for other data such as the merged mining auxiliar=
y blocks, which are very sensitive to proof size.<br><br></div>Perhaps we h=
ave a different view of how the commitment transaction would be generated. =
Just as GBT doesn't create the coinbase, it was my expectation that it =
wouldn't generate the commitment transaction either -- but generation o=
f the commitment would be easy, requiring either the coinbase txid 100 bloc=
ks back, or the commitment txid of the prior transaction (note this impacts=
SPV mining). The truncation shouldn't be an issue because the commitme=
nt txn would not be part of the list of transactions selected by GBT, and i=
n any case the truncation would change the witness data which changes the c=
ommitment.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Dec 9, 2015 at 7:=
54 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:<br>
> From this question one could think that when you said "we can do =
the<br>
> cleanup hardfork later" earlier you didn't really meant it. A=
nd that<br>
> you will oppose to that hardfork later just like you are opposing to<b=
r>
> it now.<br>
> As said I disagree that making a softfork first and then move the<br>
> commitment is less disruptive (because people will need to adapt their=
<br>
> software twice), but if the intention is to never do the second part<b=
r>
> then of course I agree it would be less disruptive.<br>
> How long after the softfork would you like to do the hardfork?<br>
> 1 year after the softfork? 2 years? never?<br>
<br>
</span>I think it would be logical to do as part of a hardfork that moved<b=
r>
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.<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>
--001a113971609d94e9052673218b--
|
