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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 202D992
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jul 2016 19:28:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s37.web-hosting.com (s37.web-hosting.com [198.54.114.154])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85101171
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jul 2016 19:27:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xbt.hk;
s=default;
h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:
Mime-Version:Subject; bh=vPQpPyExsGEE1Ojtt0+zDnWfNT9jVj6O/jMavxdbgTE=;
b=kHsd
R6aagbTvvsXJOqxvPc5SxE7TJurU/2ePkj2ZeCcKCmWsu4BVv67fjfCqbl2Yoe+EdhKGtU/GSlXg0
ITOOVbIF3eTbgGfCLfDHbu5QA1V1H8b/q7q9IR6dbQClPJTIj9+g+h6ixdh58rtS1VwWzMeXTREqv
MmvuVWTgs4t2UhcXUm37y0j1x/twFUyGnXeLnZ/V/opNnFqhDhO6sTsByat8nhsUWdwUW8ZwvBuce
DUOmt1b5tRWMFhbyqmNbcMmiQls6UQNWsQC6v0knvbhDhbQ5lJH5EkN/QMC5ZoD8eKHgPp1D1S+mO
SRdjo3pZ/rxBEGuwHL70UX5XKlC5Ow==;
Received: from 119246245241.ctinets.com ([119.246.245.241]:58724
helo=[10.8.8.2])
by server37.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.86_1) (envelope-from <jl2012@xbt.hk>)
id 1bJQa5-003J1U-UD; Sat, 02 Jul 2016 15:27:58 -0400
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <20160702184350.GA16656@fedora-21-dvm>
Date: Sun, 3 Jul 2016 03:20:42 +0800
Message-Id: <9E7B8E07-4F98-42DD-8A35-C55DAF78271F@xbt.hk>
References: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
<20160702184350.GA16656@fedora-21-dvm>
To: Peter Todd <pete@petertodd.org>
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server37.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server37.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Authenticated-Sender: server37.web-hosting.com: jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
T_DKIM_INVALID 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] 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 19:28:00 -0000
--Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
>=20
>>> the fact that we do this has a rather odd result: a transaction =
spending 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 =
unknown witness program as any-one-can-spend without looking at the =
witness, as 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.
It is trivial to softfork a new rule to require the witness must not be =
empty for a witness output. However, does it really make the code =
simpler?
>=20
> 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
Actually I would like to see even shorter hash and pubkey to be used. =
Storing 1 BTC for a few months does not really require the security =
level of P2PKH.
>=20
>>> we haven=E2=80=99t explicitly ensured that signatures for the new =
signature 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 =
bytes
> 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 =
message
> being signed with the "Bitcoin Signed Message:\n" magic string.
>=20
In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes =
(hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, =
the bytes following would be zero, as you proposed)
In the original sig, first 4 bytes in nVersion, next 4 bytes is number =
of inputs, and the next 32 bytes is a txid.
For a signature to be valid for both schemes, the last 28 bytes of the =
hashPrevouts 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 suggest would not be helpful at all.
--Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQGcBAEBCgAGBQJXeBW6AAoJEO6eVSA0viTSoeoL/1xRq3zPc4Q9HMKwNNH/apAw
zdxIgmNTCMrX30DYg2Bs0xjBYRmuRegj6vGMHHXHNW1n5PLhR5ejY0jbUJOUAXww
M9zu6f7Hm3PTBkIL6U4kPk1090Y0ce6rGDY9DzSfmXwfyl90bbNDyCfHAVPZc2b5
oQM9qPiyj/X86od6EAa3fKp2/yWwpt553MoOlhxKi+m05zkMCUeyya7QYOsApz84
nZWerSXrZokqzOppOknVp8MVbDCHrVAyr++iQIAA02tHRTF01CFM3JvzdUFOUqmL
kZdG65UiauUhJo6/O/Njv2/D9Le2nrGlPULY2lesuO4a0JkvvgijgJkTUyUKnLmS
5VCWhYDNX0kmdL5lTIg1mLdZZQIVZ0GLzN3J0J9ua+K63BPafAeJap7SAUPty1+F
PTDXQphkRYCY1hve0iz5lMRnkFXvBVhPdwMLpDE489Nb/TYp5dm7Qls+SKcy6ils
+o4x3b9ps2f5isF4iJy9sWsyQQCRlDaGK6tJ9e2qZA==
=gGIw
-----END PGP SIGNATURE-----
--Apple-Mail=_63351BE0-83AA-4ABE-BC2F-BCA34BF423D8--
|
