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
|
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 32DD9E8E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Jun 2018 17:03:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53E27708
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 1 Jun 2018 17:03:12 +0000 (UTC)
Received: from [10.8.0.110] (n218103136198.netvigator.com [218.103.136.198])
by mx.zohomail.com with SMTPS id 1527872589325816.2413556873471;
Fri, 1 Jun 2018 10:03:09 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <C3ED56D2-CB1F-4DE5-AB43-F826705806FB@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_90831A1C-79FF-4CF4-852D-908EEE61C6A4"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sat, 2 Jun 2018 01:03:05 +0800
In-Reply-To: <CAMZUoKms85DhtS1mN70nq4LSY7QtXym6E4_yvQk5Q0tizkVwEQ@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
References: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk>
<CAMZUoKms85DhtS1mN70nq4LSY7QtXym6E4_yvQk5Q0tizkVwEQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-ZohoMailClient: External
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,UC_GIBBERISH_OBFU 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] SIGHASH2 for version 1 witness programme
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, 01 Jun 2018 17:03:13 -0000
--Apple-Mail=_90831A1C-79FF-4CF4-852D-908EEE61C6A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On 1 Jun 2018, at 11:03 PM, Russell O'Connor <roconnor@blockstream.io> =
wrote:
>=20
>=20
>=20
> On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
> Double SHA256 of the serialization of:
>=20
> Should we replace the Double SHA256 with a Single SHA256? There is no =
possible length extension attack here. Or are we speculating that there =
is a robustness of Double SHA256 in the presence of SHA256 breaking?
>=20
> I suggest putting `sigversion` at the beginning instead of the end of =
the format. Because its value is constant, the beginning of the SHA-256 =
computation could be pre-computed in advance. Furthermore, if we make =
the `sigversion` exactly 64-bytes long then the entire first block of =
the SHA-256 compression function could be pre-computed.
>=20
> Can we add CHECKSIGFROMSTACK or do you think that would go into a =
separate BIP?
I think it=E2=80=99s just a tradition to use double SHA256. One reason =
we might want to keep dSHA256 is a blind signature might be done by =
giving only the single SHA256 hash to the signer. At the same time, a =
non-Bitcoin signature scheme might use SHA512-SHA256. So a blind signer =
could distinguish the message type without learning the message.
sigversion is a response to Peter Todd=E2=80=99s comments on BIP143: =
https://petertodd.org/2016/segwit-consensus-critical-code-review#bip143-tr=
ansaction-signature-verification =
<https://petertodd.org/2016/segwit-consensus-critical-code-review#bip143-t=
ransaction-signature-verification>
I make it a 0x01000000 at the end of the message because the last 4 =
bytes has been the nHashType in the legacy/BIP143 protocol. Since the =
maximum legacy nHashType is 0xff, no collision could ever occur.
Putting a 64-byte constant at the beginning should also work, since a =
collision means SHA256 is no longer preimage resistance. I don=E2=80=99t =
know much about SHA256 optimisation. How good it is as we put a 64-byte =
constant at the beginning, while we also make the message 64-byte =
longer?
For CHECKSIGFROMSTACK (CSFS), I think the question is whether we want to =
make it as a separate opcode, or combine that with CHECKSIG. If it is a =
separate opcode, I think it should be a separate BIP. If it is combined =
with CHECKSIG, we could do something like this: If the bit 10 of =
SIGHASH2 is set, CHECKSIG will pop one more item from stack, and =
serialize its content with the transaction digest. Any thought?
--Apple-Mail=_90831A1C-79FF-4CF4-852D-908EEE61C6A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 1 Jun 2018, at 11:03 PM, Russell O'Connor <<a =
href=3D"mailto:roconnor@blockstream.io" =
class=3D"">roconnor@blockstream.io</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><br class=3D""><div class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via =
bitcoin-dev <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.<wbr =
class=3D"">linuxfoundation.org</a>></span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class=3D"">
Double SHA256 of the serialization of:<br =
class=3D""></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">Should we replace the Double SHA256 with a Single =
SHA256? There is no possible length extension attack here. =
Or are we speculating that there is a robustness of Double SHA256 in the =
presence of SHA256 breaking?<br class=3D""><br class=3D""></div><div =
class=3D"">I suggest putting `sigversion` at the beginning instead of =
the end of the format. Because its value is constant, the =
beginning of the SHA-256 computation could be pre-computed in =
advance. Furthermore, if we make the `sigversion` exactly 64-bytes =
long then the entire first block of the SHA-256 compression function =
could be pre-computed.<br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">Can we add CHECKSIGFROMSTACK or do you =
think that would go into a separate BIP?<br =
class=3D""></div></div></div></div>
</div></blockquote></div><br class=3D""><div class=3D"">I think it=E2=80=99=
s just a tradition to use double SHA256. One reason we might want to =
keep dSHA256 is a blind signature might be done by giving only the =
single SHA256 hash to the signer. At the same time, a non-Bitcoin =
signature scheme might use SHA512-SHA256. So a blind signer could =
distinguish the message type without learning the message.</div><div =
class=3D""><br class=3D""></div><div class=3D"">sigversion is a response =
to Peter Todd=E2=80=99s comments on BIP143: <a =
href=3D"https://petertodd.org/2016/segwit-consensus-critical-code-review#b=
ip143-transaction-signature-verification" =
class=3D"">https://petertodd.org/2016/segwit-consensus-critical-code-revie=
w#bip143-transaction-signature-verification</a></div><div class=3D""><br =
class=3D""></div><div class=3D"">I make it a 0x01000000 at the end of =
the message because the last 4 bytes has been the nHashType in the =
legacy/BIP143 protocol. Since the maximum legacy nHashType is 0xff, no =
collision could ever occur.</div><div class=3D""><br class=3D""></div><div=
class=3D"">Putting a 64-byte constant at the beginning should also =
work, since a collision means SHA256 is no longer preimage resistance. I =
don=E2=80=99t know much about SHA256 optimisation. How good it is as we =
put a 64-byte constant at the beginning, while we also make the message =
64-byte longer?</div><div class=3D""><br class=3D""></div><div =
class=3D"">For CHECKSIGFROMSTACK (CSFS), I think the question is whether =
we want to make it as a separate opcode, or combine that with CHECKSIG. =
If it is a separate opcode, I think it should be a separate BIP. If it =
is combined with CHECKSIG, we could do something like this: If the bit =
10 of SIGHASH2 is set, CHECKSIG will pop one more item from stack, and =
serialize its content with the transaction digest. Any =
thought?</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div></body></html>=
--Apple-Mail=_90831A1C-79FF-4CF4-852D-908EEE61C6A4--
|
