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
|
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 4B4EAAB9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Apr 2017 20:06:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D7C7106
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Apr 2017 20:06:41 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id w64so241720wma.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Apr 2017 13:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=4BhDtWG+ErbfVleCC7XA9reZ/Sj4coV2krwyXq98GpI=;
b=Zr2XyJtMiTPVWcB90ijAmbU0ot+fEtCJ7jQgNi+e1pVPeaiyvu85l//8bkVtalEpxD
vAOXPd3RWqZAT+U4LykvXWbW5422yVO6LOyrRdlFXR+jFu1mtvQBGDwS7GK+d73sxzJW
nz9K9XTVKbiNgTXJe7WsymEGlQfVv7nrhZEeJouaOoy6qMXqD82eAqtcOFL+lr+uPmi+
gmRqpDukKUjwaNc3MYCVjxRO0/lowj7UoslbNa6TKY0NOgwkQsREYnSRK8+pSGGpKJxj
ntz6/nU+NnHUxZo0PYUG0s5RM5m7aiTyJFKjHjoe7gZj0S6OcN65ZlE6CMEvmPM3U4bf
cibg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=4BhDtWG+ErbfVleCC7XA9reZ/Sj4coV2krwyXq98GpI=;
b=reKStZRTxAV8wO0PBWv/tH6vk++IHZqcjplVBDM/pqejmb2h9cy7j2aFGwCrkBr31Y
E5EUgVG3Lf74ssbg1vfLBFPmUblEUrXjDeyGVG6cwHfBlMNQRTKUSbCTs+xcCOPct/H0
Zl9d4LB/PoDodcHIQXUmy4V6wyR2uGI9HWbUP7VYWtnhqfCqy2vY1akaqA6ehmYx4ywe
uu+sYtJCsyRZHx/P5VLyyw970MILV+63eIsNDZCq31ZctrDHWi6zZApzy9MvceP1tQ8z
aYLxU7UYDC2S1ExOyIWts32lDziJuC4h2P5+DAfS52g7pzUeF9a4/zUlkOeAAgVmdiV1
oHBg==
X-Gm-Message-State: AN3rC/7qsZGJO5t9R8SgQWz0L6Qz9WbZDnWfrLurO8UucPhTJsO+Hpjz
9o3E5FANeBRREtgM6aZgDKUP4BoTAXWr7kA=
X-Received: by 10.28.163.68 with SMTP id m65mr842371wme.19.1491595600103; Fri,
07 Apr 2017 13:06:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.134.243 with HTTP; Fri, 7 Apr 2017 13:06:39 -0700 (PDT)
From: Jimmy Song <jaejoon@gmail.com>
Date: Fri, 7 Apr 2017 15:06:39 -0500
Message-ID: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114cd954e48fa2054c9929ae
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: Fri, 07 Apr 2017 20:41:10 +0000
Subject: [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: Fri, 07 Apr 2017 20:06:42 -0000
--001a114cd954e48fa2054c9929ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 network
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 propo=
sal 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) and =
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 witness
commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used
as the version bits in the block header previously. The witness commitment
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.
--001a114cd954e48fa2054c9929ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><h3 name=3D"d843" class=3D"gmail-graf gmail-graf--h3"><spa=
n style=3D"font-weight:normal"><font size=3D"2">Hey everyone,=C2=A0</font><=
/span></h3><h3 name=3D"d843" class=3D"gmail-graf gmail-graf--h3"><span styl=
e=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 ev=
eryone on this list. I'm not at all sure what this would mean for non-u=
pgraded nodes on the network 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.</font></span></h3><div><span=
style=3D"font-weight:normal"><font size=3D"2">----------------------------=
------------</font></span></div><h3 name=3D"d843" class=3D"gmail-graf gmail=
-graf--h3"><span style=3D"font-weight:normal"><font size=3D"2">Motivation</=
font></span></h3><h3 name=3D"d843" class=3D"gmail-graf gmail-graf--h3"><spa=
n style=3D"font-weight:normal"><font size=3D"2">One of the interesting aspe=
cts of Gregory Maxwell=E2=80=99s proposal is that it only precludes the <sp=
an class=3D"gmail-markup--em gmail-markup--p-em">covert</span> version of A=
SICBoost. He specifically left the <span class=3D"gmail-markup--em gmail-ma=
rkup--p-em">overt</span> version alone.<br></font></span></h3><p name=3D"41=
6c" class=3D"gmail-graf gmail-graf--p"><span class=3D"gmail-markup--em gmai=
l-markup--p-em">Overt</span> ASICBoost requires grinding on the version bit=
s of the Block header instead of the Merkle Root. This is likely more effic=
ient than the Merkle Root grinding (aka <span class=3D"gmail-markup--em gma=
il-markup--p-em">covert</span> ASICBoost) and requires way less resources (=
much less RAM, SHA256 calculations, no tx shuffling, etc).</p><p name=3D"26=
c8" class=3D"gmail-graf gmail-graf--p">If we combine Gregory Maxwell=E2=80=
=99s proposal with BIP-141 (Segwit) and add a slight modification, this sho=
uld, in theory, make ASICBoost a lot more useful to miners and appeal to th=
eir financial interests.=C2=A0</p><h3 name=3D"49b1" class=3D"gmail-graf gma=
il-graf--h3"><font size=3D"2" style=3D"font-weight:normal">The Modification=
</font></h3><p name=3D"d82f" class=3D"gmail-graf gmail-graf--p">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 <span class=3D"gmail-markup--em gmail-markup--p-em">overt</s=
pan> ASICBoost. The 32-bits are now moved over to the Coinbase transaction =
as part of the witness commitment. The witness commitment goes from 38 byte=
s to 42 bytes, with the last 4 bytes being used as the version bits in the =
block header previously. The witness commitment becomes required as per Gre=
gory Maxwell=E2=80=99s proposal.</p><h3 name=3D"bf2c" class=3D"gmail-graf g=
mail-graf--h3"><font size=3D"2" style=3D"font-weight:normal">Reasoning</fon=
t></h3><p name=3D"7083" class=3D"gmail-graf gmail-graf--p">First, this brin=
gs ASICBoost out into the open. <span class=3D"gmail-markup--em gmail-marku=
p--p-em">Covert</span> ASICBoost becomes much more costly and <span class=
=3D"gmail-markup--em gmail-markup--p-em">overt</span> ASICBoost is now enco=
uraged.</p><p name=3D"e25f" class=3D"gmail-graf gmail-graf--p">Second, we c=
an make this change relatively quickly. Most of the Segwit testing stays va=
lid and this change can be deployed relatively quickly.</p><p name=3D"b417"=
class=3D"gmail-graf gmail-graf--p">Note on SPV clients</p><p name=3D"b417"=
class=3D"gmail-graf gmail-graf--p">Currently Segwit stores the witness com=
mitment in the Coinbase tx, so lightweight clients will need to get the Coi=
nbase tx + Merkle proof to validate segwit transactions anyway. Putting blo=
ck version information in the Coinbase tx will not impose an extra burden o=
n upgraded light clients.<br></p></div>
--001a114cd954e48fa2054c9929ae--
|
