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
228
229
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 87BF771
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jul 2016 18:44:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com
[62.13.148.98])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 91F9D122
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jul 2016 18:44:27 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u62IiPPh009672;
Sat, 2 Jul 2016 19:44:25 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u62IiOib071123
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 2 Jul 2016 19:44:25 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id EAA3040122;
Sat, 2 Jul 2016 18:42:08 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id DA1FF20341; Sat, 2 Jul 2016 14:43:50 -0400 (EDT)
Date: Sat, 2 Jul 2016 14:43:50 -0400
From: Peter Todd <pete@petertodd.org>
To: Johnson Lau <jl2012@xbt.hk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160702184350.GA16656@fedora-21-dvm>
References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
In-Reply-To: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: ffdfb195-4084-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgAUEkAYAgsB AmAbWl1eVFl7W2Y7 bghPaBtcak9QXgdq
T0pMXVMcUQNqeEV+ X0weVRhzdQYIeX13 bUYsCCYPChZ7fENg
Rk5cEXAHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYA9S TgxFF18MQEsUTHYA Rx1KNjIpBkADXDgo
Zzc8K0IdF08Ven07 K0c6EVUWUVcpBwJB Hl0FCj4RH1QdSjBj MQRWUSYA
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of
Segwit by Peter Todd
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, 02 Jul 2016 18:44:28 -0000
--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 29, 2016 at 12:22:45AM +0800, Johnson Lau via bitcoin-dev wrote:
> Thanks for Peter Todd=E2=80=99s detailed report:
> https://petertodd.org/2016/segwit-consensus-critical-code-review
>=20
> I have the following response.
>=20
> >Since the reserve value is only a single, 32-byte value, we=E2=80=99re s=
etting ourselves up for the same problem again7.
>=20
> Please note that unlimited space has been reserved after the witness comm=
itment:
>=20
> block.vtx[0].vout[o].scriptPubKey.size() >=3D 38
>=20
> Which means anything after 38 bytes has no consensus meaning. Any new co=
nsensus critical commitments/metadata could be put there. Anyway, there is =
no efficient way to add a new commitment with softfork.
Sure - equally you could say you could add additional commitments as other
coinbase txouts.
My point is that the extensible commitment - specifically the thing describ=
ed
in the BIP - can't be easily used for the purpose of extending segwit due t=
o a
design flaw.
> > the fact that we do this has a rather odd result: a transaction spendin=
g a witness output with an unknown version is valid even if the transaction=
doesn=E2=80=99t have any witnesses!
>=20
> I don=E2=80=99t see any reason to have such check. We simply leave unknow=
n witness program as any-one-can-spend without looking at the witness, as d=
escribed in BIP141.
It will lead to a special case in code that does things with witness
transactions, as we can spend a witness output without a witness.
> > Bizzarely segwit has an additonal pay-to-witness-pubkey-hashP2WPKH that=
lets you use a 160-bit (20 byte) commitment=E2=80=A6=E2=80=A6
>=20
> Since ~90% of current transactions are P2PKH, we expect many people will =
keep using this type of transaction in the future. P2WPKH gives the same le=
vel of security as P2PKH, and smaller scriptPubKey.
>=20
> >give users the option instead to choose to accept the less secure 160-bi=
t commitment if their use-case doesn=E2=80=99t need the full 256-bit securi=
ty level
>=20
> This is actually discussed on the mailing list. P2WSH with multi-sig is s=
ubject to birthday attack, and therefore 256-bit is used to provide 128-bit=
security. P2WPKH is used as single sig and therefore 160-bit is enough.
I'm aware of that - there are many P2SH scripts where birthday attacks are =
not
an issue. In fact, _most_ usage of P2SH right now - multifactor wallets -
doesn't have a birthday attack problem.
> >Secondly, if you are going to give a 160-bit commitment option, you don=
=E2=80=99t need the extra level of indirection in the P2SH case: just make =
the segwit redeemScript be: <version> <serialized witness script>
>=20
> Something wrong here? In P2WPKH, the witness is <sig> <pubkey>
Huh? That still another level of indirection.
Anyway, the right argument against my proposal for pay-to-pubkey-hash
functionality, is that taking into account the witness discount, my proposa=
l is
slightly less efficient. In P2WPKH in P2SH the witness program in the
redeemScript is 22 bytes:
<1-byte version> <1-byte length> <20 byte pubkey hash>
And the witness len(sig) + 34 bytes:
<sig> <1 byte length> <33 bytes pubkey>
Taking into account the discount, that results in 22*4 + 34 + len(sig) =3D =
122 bytes + len(sig)
My proposal would have a 37 byte redeemScript:
<1-byte version> <1-byte witness script length> {<1-byte pubkey length>=
<33 byte pubkey> OP_CHECKSIG}
and a len(sig) length witness:
<sig>
Taking into account the discount, that results in 37*4 + len(sig) =3D 148 b=
ytes + len(sig)
Meanwhile for any more complex script, you'd certainly want to use the 256-=
bit
hash instead, due to the witness discount.
This suggests an obvious alternative: let users choose to use 160-bit secur=
ity,
and make 256-bit and 160-bit witness programm commitments just be different
hash functions. P2PKH functionality implemented this way would be a single
extra byte vs. special-casing it.
Thus you could summarize the argument for the P2PKH special case as "We don=
't
want to make it possible to use 160-bit commitments for multisig, which _mi=
ght_
need 256-bit security. But we do want to special-case pubkeys to save a few
bytes."
> >The only downside is the serialized witness script is constrained to 520=
bytes max
>=20
> 520 is the original limit. BIP141 tries to mimic the existing behaviour a=
s much as possible. Anyway, normally nothing in the current scripts should =
use a push with more than 75 bytes
No, you're quite confused at my point: the witness script is otherwise
constrained to 10,000 bytes, as the first item in the witness is special-ca=
sed
for version 0 to be not be subject to the 520 byte rule.
> >we haven=E2=80=99t explicitly ensured that signatures for the new signat=
ure hash can=E2=80=99t be reused for the old signature hash
>=20
> How could that be? That=E2=80=99d be a hash collision.
Nope. The problem is it might not be a hash collission, if the actual bytes
signed can be interpreted in two different ways, by different types of
signature hashes.
This is the same reason the signmessage functionality prepends the message
being signed with the "Bitcoin Signed Message:\n" magic string.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJXeAtjAAoJEGOZARBE6K+yDSIH/3FOj9uRwgav5+rGc8KkX82t
Gtkr5O6iQvf4pkd3GruUiwR5fKCGoTy6NU//NizlAW8uvNoQT3k9b3dm/CpPHMA/
mblXxEloYUxTdA/34E9fscBmWXRXv+ecWnnt+6aWFtrb681ccyf5PRqe60kIpc0r
wk7dw1wq/2Q/fM97CZTfUdP4qfMaZ9pu9DFDzv4s9SojrBdu/wh4EpNLXm6eWGMI
5kdxJe79RObvKHmRLni7XkDGpGJ+i5+DX7biaMefQcvZF8/2F5blpAAnerIvp95/
i+BSqI4Xgpxyn0bw5ttpezJB5SDOtlVZdxOpmrzxOhE4GahIzu1XwemF41zwZ8g=
=1H3Q
-----END PGP SIGNATURE-----
--3MwIy2ne0vdjdPXF--
|
