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
|
Return-Path: <jaejoon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 32F48BB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 00:05:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5187FFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Apr 2017 00:05:18 +0000 (UTC)
Received: by mail-wm0-f53.google.com with SMTP id w64so2919566wma.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Apr 2017 17:05:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=pz8mq2c60gevKeVJb+E+Ouz1WnS92jCKRry2UWHG3B4=;
b=IjI+DfMYLlSzVBr2RCNrPoraiBCcJm+XemYyGy8NnCNAhF53DR0+Gte6g6U4J5VdUX
POyLQS2B6VsWn8+xPYbK6x8CWeVlc/MrkqsrTfkVDGpFEB8DTqiSjxN6J6NCrB5ZH24F
R2xeGy+mT1FC1rNWbWPE/BWR6QRmB6jLvuaK3FeDOcAtqU6sza5Vesgo8mIbphvlUV5e
oWEItnz5cgC4RwIX5jRVMefWqCdyFdAJqhciUIwtJ9yCM4vOYH3Cx4L6y8c/bnc3j60k
ZsR3vJrLBVXASwoybEc4+9et1rdw0t6RiUNSrbmoYZ7xkevAkT9v0FAEb2+7M/bHxyez
olAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=pz8mq2c60gevKeVJb+E+Ouz1WnS92jCKRry2UWHG3B4=;
b=EV2xVojH/Ykd0ffqqMV8Zzy7FXFHhf6Eo7owPutXAzwrYoG0Jarr6HpHhxm8S9FYyc
f7r2VUiLdSrPKy9mTIbBK3vos87y4wTZbwI1KNxcGZe/toZiuldVUfSaMQO4/oDNeN20
gAAFK9it3sNxh5DPdKovQ3m35No4ksSVn4Mh6E5pcFjXD3VsmXkbIae4r59Eg2nezK8a
EGF7aI5a7DCajh+QqeO94xmWJLJHbH4o12p6WmsgXDQ8zOg+DhoS3HOcjTUHUT0s3Go+
+6LT1To1Z4YEgdZxlE4noGayXk2KHK0G/3CNyBrYdu52MqceSnKJXzeVf98E+27nl2+0
RTGg==
X-Gm-Message-State: AN3rC/6O71Iz3CI92W96B8RR+eE4Da5aGSE5THIOd8ALd4AABRtquPt3
onTLlhaRBczzv8CTkMAv2XsFdOQbMnwH
X-Received: by 10.28.212.67 with SMTP id l64mr1460428wmg.76.1491609916850;
Fri, 07 Apr 2017 17:05:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.134.243 with HTTP; Fri, 7 Apr 2017 17:05:16 -0700 (PDT)
In-Reply-To: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
From: Jimmy Song <jaejoon@gmail.com>
Date: Fri, 7 Apr 2017 19:05:16 -0500
Message-ID: <CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11469e583cca81054c9c7f20
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 08 Apr 2017 00:39:08 +0000
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Sat, 08 Apr 2017 00:05:19 -0000
--001a11469e583cca81054c9c7f20
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 then is modified so that bits 16 to 23 are now no longer
usable.
On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon@gmail.com> wrote:
> Hey everyone, This is an idea that I had about Segwit and Gregory's
> proposal from yesterday that I wanted to run by everyone on this list. I'=
m
> not at all sure what this would mean for non-upgraded nodes on the networ=
k
> and would like feedback on that. This is not a formal BIP as it's a
> modification to a previously submitted one, but I'm happy to formalize it
> if it would help.
> ----------------------------------------
> MotivationOne of the interesting aspects of Gregory Maxwell=E2=80=99s pro=
posal is
> that it only precludes the covert version of ASICBoost. He specifically
> left the overt version alone.
>
> Overt ASICBoost requires grinding on the version bits of the Block header
> instead of the Merkle Root. This is likely more efficient than the Merkle
> Root grinding (aka covert ASICBoost) and requires way less resources
> (much less RAM, SHA256 calculations, no tx shuffling, etc).
>
> If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (Segwit) an=
d add a
> slight modification, this should, in theory, make ASICBoost a lot more
> useful to miners and appeal to their financial interests.
> The Modification
>
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> are used for BIP9 signaling. We change the version bits to a nonce-space =
so
> the miners can use it for overt ASICBoost. The 32-bits are now moved over
> to the Coinbase transaction as part of the witness commitment. The witnes=
s
> commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being us=
ed
> as the version bits in the block header previously. The witness commitmen=
t
> becomes required as per Gregory Maxwell=E2=80=99s proposal.
> Reasoning
>
> First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> much more costly and overt ASICBoost is now encouraged.
>
> Second, we can make this change relatively quickly. Most of the Segwit
> testing stays valid and this change can be deployed relatively quickly.
>
> Note on SPV clients
>
> Currently Segwit stores the witness commitment in the Coinbase tx, so
> lightweight clients will need to get the Coinbase tx + Merkle proof to
> validate segwit transactions anyway. Putting block version information in
> the Coinbase tx will not impose an extra burden on upgraded light clients=
.
>
--001a11469e583cca81054c9c7f20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've gotten feedback from Adam Back that you actually =
don't need all 32 bits in the header for overt ASICBoost, so I'm mo=
difying my proposal. Of the 32-bit version field, bits 16 to 23 are reserve=
d for miners, the witness commitment stays as defined in BIP-141 except tha=
t it's now required. BIP9 then is modified so that bits 16 to 23 are no=
w no longer usable.</div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <span dir=3D"ltr"><<a=
href=3D"mailto:jaejoon@gmail.com" target=3D"_blank">jaejoon@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><h3 na=
me=3D"d843" class=3D"m_-1233224201548509828gmail-graf m_-123322420154850982=
8gmail-graf--h3"><span style=3D"font-weight:normal"><font size=3D"2">Hey ev=
eryone,=C2=A0</font></span></h3><h3 name=3D"d843" class=3D"m_-1233224201548=
509828gmail-graf m_-1233224201548509828gmail-graf--h3"><span style=3D"font-=
weight:normal"><font size=3D"2">This is an idea that I had about Segwit and=
Gregory's proposal from yesterday that I wanted to run by everyone on =
this list. I'm not at all sure what this would mean for non-upgraded no=
des on the network and would like feedback on that. This is not a formal BI=
P as it's a modification to a previously submitted one, but I'm hap=
py to formalize it if it would help.</font></span></h3><div><span style=3D"=
font-weight:normal"><font size=3D"2">------------------------------<wbr>---=
-------</font></span></div><h3 name=3D"d843" class=3D"m_-123322420154850982=
8gmail-graf m_-1233224201548509828gmail-graf--h3"><span style=3D"font-weigh=
t:normal"><font size=3D"2">Motivation</font></span></h3><h3 name=3D"d843" c=
lass=3D"m_-1233224201548509828gmail-graf m_-1233224201548509828gmail-graf--=
h3"><span style=3D"font-weight:normal"><font size=3D"2">One of the interest=
ing aspects of Gregory Maxwell=E2=80=99s proposal is that it only precludes=
the <span class=3D"m_-1233224201548509828gmail-markup--em m_-1233224201548=
509828gmail-markup--p-em">covert</span> version of ASICBoost. He specifical=
ly left the <span class=3D"m_-1233224201548509828gmail-markup--em m_-123322=
4201548509828gmail-markup--p-em">overt</span> version alone.<br></font></sp=
an></h3><p name=3D"416c" class=3D"m_-1233224201548509828gmail-graf m_-12332=
24201548509828gmail-graf--p"><span class=3D"m_-1233224201548509828gmail-mar=
kup--em m_-1233224201548509828gmail-markup--p-em">Overt</span> ASICBoost re=
quires grinding on the version bits of the Block header instead of the Merk=
le Root. This is likely more efficient than the Merkle Root grinding (aka <=
span class=3D"m_-1233224201548509828gmail-markup--em m_-1233224201548509828=
gmail-markup--p-em">covert</span> ASICBoost) and requires way less resource=
s (much less RAM, SHA256 calculations, no tx shuffling, etc).</p><p name=3D=
"26c8" class=3D"m_-1233224201548509828gmail-graf m_-1233224201548509828gmai=
l-graf--p">If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (S=
egwit) and add a slight modification, this should, in theory, make ASICBoos=
t a lot more useful to miners and appeal to their financial interests.=C2=
=A0</p><h3 name=3D"49b1" class=3D"m_-1233224201548509828gmail-graf m_-12332=
24201548509828gmail-graf--h3"><font size=3D"2" style=3D"font-weight:normal"=
>The Modification</font></h3><p name=3D"d82f" class=3D"m_-12332242015485098=
28gmail-graf m_-1233224201548509828gmail-graf--p">Currently, the version bi=
ts (currently 4 bytes, or 32 bits) in the header are used for BIP9 signalin=
g. We change the version bits to a nonce-space so the miners can use it for=
<span class=3D"m_-1233224201548509828gmail-markup--em m_-12332242015485098=
28gmail-markup--p-em">overt</span> ASICBoost. The 32-bits are now moved ove=
r to the Coinbase transaction as part of the witness commitment. The witnes=
s commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being us=
ed as the version bits in the block header previously. The witness commitme=
nt becomes required as per Gregory Maxwell=E2=80=99s proposal.</p><h3 name=
=3D"bf2c" class=3D"m_-1233224201548509828gmail-graf m_-1233224201548509828g=
mail-graf--h3"><font size=3D"2" style=3D"font-weight:normal">Reasoning</fon=
t></h3><p name=3D"7083" class=3D"m_-1233224201548509828gmail-graf m_-123322=
4201548509828gmail-graf--p">First, this brings ASICBoost out into the open.=
<span class=3D"m_-1233224201548509828gmail-markup--em m_-12332242015485098=
28gmail-markup--p-em">Covert</span> ASICBoost becomes much more costly and =
<span class=3D"m_-1233224201548509828gmail-markup--em m_-123322420154850982=
8gmail-markup--p-em">overt</span> ASICBoost is now encouraged.</p><p name=
=3D"e25f" class=3D"m_-1233224201548509828gmail-graf m_-1233224201548509828g=
mail-graf--p">Second, we can make this change relatively quickly. Most of t=
he Segwit testing stays valid and this change can be deployed relatively qu=
ickly.</p><p name=3D"b417" class=3D"m_-1233224201548509828gmail-graf m_-123=
3224201548509828gmail-graf--p">Note on SPV clients</p><p name=3D"b417" clas=
s=3D"m_-1233224201548509828gmail-graf m_-1233224201548509828gmail-graf--p">=
Currently Segwit stores the witness commitment in the Coinbase tx, so light=
weight clients will need to get the Coinbase tx + Merkle proof to validate =
segwit transactions anyway. Putting block version information in the Coinba=
se tx will not impose an extra burden on upgraded light clients.<br></p></d=
iv>
</blockquote></div><br></div>
--001a11469e583cca81054c9c7f20--
|
