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
|
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 102C41BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 4 Jul 2016 23:27:21 +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 E8486A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 4 Jul 2016 23:27:19 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u64NRIr6087894;
Tue, 5 Jul 2016 00:27:18 +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 u64NRG7g003221
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Tue, 5 Jul 2016 00:27:17 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id A654D40087;
Mon, 4 Jul 2016 23:24:59 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 82D3B2032A; Mon, 4 Jul 2016 19:27:15 -0400 (EDT)
Date: Mon, 4 Jul 2016 19:27:15 -0400
From: Peter Todd <pete@petertodd.org>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20160704232715.GA21569@fedora-21-dvm>
References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
<20160702184350.GA16656@fedora-21-dvm>
<9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: d8f5fe7d-423e-11e6-bcde-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgcUEkAYAgsB AmAbW1ReUlp7WGQ7 bghPaBtcak9QXgdq
T0pMXVMcUQNsf352 AUkeUhpwdQQIeX93 ZkAsCngNWRIvchJg
RkxXQHAHZDJmdTJM BBVFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYA9S TgxFF18MQEsUTHYA Rx1KNjIpBkADXDgo
Zzc8K0IdF08Ven07 K0c6EVUWUVcpBwJB Hl0FCj4RH1QdSjBj MQRWUSYA
X-Authentic-SMTP: 61633532353630.1038: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
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.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: Mon, 04 Jul 2016 23:27:21 -0000
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 03, 2016 at 03:20:42AM +0800, Johnson Lau wrote:
> >>> the fact that we do this has a rather odd result: a transaction spend=
ing a witness output with an unknown version is valid even if the transacti=
on doesn=E2=80=99t have any witnesses!
> >>=20
> >> I don=E2=80=99t see any reason to have such check. We simply leave unk=
nown witness program as any-one-can-spend without looking at the witness, a=
s described in BIP141.
> >=20
> > 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.
>=20
> It is trivial to softfork a new rule to require the witness must not be e=
mpty for a witness output. However, does it really make the code simpler?
The Bitcoin Core codebase, no, but it does reduce the number of special cas=
es
other codebases have to contend with.
Probably not worth changing now, but it was I think a weird design choice to
make.
> > 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=
_might_
> > need 256-bit security. But we do want to special-case pubkeys to save a=
few
> > bytes.=E2=80=9D
>=20
> Actually I would like to see even shorter hash and pubkey to be used. Sto=
ring 1 BTC for a few months does not really require the security level of P=
2PKH.
How short? 128 bits? 80 bits? 64 bits?
It's hard to know what's the point where you're going to risk massive losses
due to theft... and as we've seen with the DAO, those kinds of losses can l=
ead
to very undesirable pressure for devs to act as a central authority and
intervene.
> >>> we haven=E2=80=99t explicitly ensured that signatures for the new sig=
nature 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.
> >=20
> > Nope. The problem is it might not be a hash collission, if the actual b=
ytes
> > signed can be interpreted in two different ways, by different types of
> > signature hashes.
> >=20
> > This is the same reason the signmessage functionality prepends the mess=
age
> > being signed with the "Bitcoin Signed Message:\n" magic string.
> >=20
>=20
> In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrev=
outs) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes fo=
llowing would be zero, as you proposed)
>=20
> In the original sig, first 4 bytes in nVersion, next 4 bytes is number of=
inputs, and the next 32 bytes is a txid.
>=20
> For a signature to be valid for both schemes, the last 28 bytes of the ha=
shPrevouts must also be the first 28 bytes of a valid txid. This is already=
impossible. And this is just one of the many collisions required. In such =
case SHA256 would be insecure and adding a zero after the nVersion as you s=
uggest would not be helpful at all.
Why isn't this carefully documented in the BIPs then?
Again, as I said in my summary:
In a number of places we either have a belt, or suspenders, when given =
the
importance of this code we=E2=80=99d rather have both a belt and suspen=
ders.
Tagged hashing is an excellent way to absolutely sure that signatures can't=
be
reused in different contexts; if it happens to be overkill in a specific
context, the overhead of hashing another few bytes is trivial; the gain of
being absolutely sure you haven't missed a vulnerability can't be easily
dismissed.
Equally, I think in most cases simply XORing the digest obtained by hashing
with a magic tag prior to using it (e.g. by signing it) should be sufficient
for signature applications, and the overhead of doing that is ~zero.
Essentially you can think of the magic tag that's XORed with the raw digest=
as
making clear the intent of the signature: "this is why I think I'm signing =
this
digest"
However, the XOR option does have one potentially big downside in other
contexts, like general use in committed data structures: it's incompatible =
with
timestamping schemes like OpenTimestamps that rely on all operations being
cryptographically secure.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJXevDQAAoJEGOZARBE6K+yTbMH/jR3n+36qcYSD1knvABYJjIp
gr+9O2u0E82MFH5PMAuaD+ycuFPbgYleeh7gajrdMRdL2pgUzjERCVj29miaAHZw
BnRTUJmjazZiDa82Upsra8KWDkKvRuHyzpBP6ceUkGJSgkwlnwvwVFJDvm21Gi0B
aOe0e6wRdV/YH4Ix/pdZOUgQ1lojIw+4EPGjXtnbTdH9fhB5TyTC6QbltgmNPCUl
1MXYZOX3lI98Gip7L/l4SA22o62/kh8rqE9pASfwZVL9zI7zOmb5VLV4SvvMfzgO
kOL0mZiWKHUO055s0/wShUDtXguZSafcAxkuWYjBLZ+mxukz80Jh31Dp4GF32bE=
=1cb+
-----END PGP SIGNATURE-----
--PEIAKu/WMn1b1Hv9--
|
