summaryrefslogtreecommitdiff
path: root/ad/5ea76001c899bf7fbb30609392c1ef4d4c1994
blob: ff70a380ffc313f55ef8cba7d8a7a140b7d5f918 (plain)
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
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
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 54302FA8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 31 May 2018 18:35:49 +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 26F806BA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 31 May 2018 18:35:47 +0000 (UTC)
Received: from [10.8.0.110] (n218103136198.netvigator.com [218.103.136.198])
	by mx.zohomail.com with SMTPS id 1527791745425244.38591135414094;
	Thu, 31 May 2018 11:35:45 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk>
Date: Fri, 1 Jun 2018 02:35:41 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
Subject: [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: Thu, 31 May 2018 18:35:49 -0000

Since 2016, I have made a number of proposals for the next generation of =
script. Since then, there has been a lot of exciting development on this =
topic. The most notable ones are Taproot and Graftroot proposed by =
Maxwell. It seems the most logical way is to implement MAST and other =
new script functions inside Taproot and/or Graftroot. Therefore, I =
substantially simplified my earlier proposal on SIGHASH2. It is a =
superset of the existing SIGHASH and the BIP118 SIGHASH_NOINPUT, with =
further flexibility but not being too complicated. It also fixes some =
minor problems that we found in the late stage of BIP143 review. For =
example, the theoretical (but not statistical) possibility of having =
same SignatureHash() results for a legacy and a witness transaction. =
This is fixed by padding a constant at the end of the message so =
collision would not be possible.

A formatted version and example code could be found here:
https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
https://github.com/jl2012/bitcoin/commits/sighash2


=3D=3D=3D=3D=3D=3D=3D=3D

BIP: YYY
  Layer: Consensus (soft fork)
  Title: Signature checking operations in version 1 witness program
  Author: Johnson Lau <jl2012@xbt.hk>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0YYY
  Status: Draft
  Type: Standards Track
  Created: 2017-07-19
  License: BSD-3-Clause


*Abstract

This BIP defines signature checking operations in version 1 witness =
program.

*Motivation

Use of compact signatures to save space.

More SIGHASH options, more flexibility

*Specification

The following specification is applicable to OP_CHECKSIG and =
OP_CHECKSIGVERIFY in version 1 witness program.

**Public Key Format

The pubic key MUST be exactly 33 bytes.

If the first byte of the public key is a 0x02 or 0x03, it MUST be a =
compressed public key. The signature is a Schnorr signature (To be =
defined separately)

If the first byte of the public key is neither 0x02 nor 0x03, the =
signature is assumed valid. This is for future upgrade.

**Signature Format

The following rules apply only if the first byte of the public key is a =
0x02 or 0x03.

If the signature size is 64 to 66 byte, it MUST be a valid Schnorr =
signature or the script execution MUST fail (cf. BIP146 NULLFAIL). The =
first 32-byte is the R value in big-endian. The next 32-byte is the S =
value in big-endian. The remaining data, if any, denotes the hashtype in =
little-endian (0 to 0xffff).

hashtype MUST be minimally encoded. Any trailing zero MUST be removed.

If the signature size is zero, it is accepted as the "valid failing" =
signature for OP_CHECKSIG to return a FALSE value to the stack. (cf. =
BIP66)

The script execution MUST fail with a signature size not 0, 64, 65, or =
66-byte.

**New hashtype definitions

hashtype and the SignatureHash function are re-defined:

  Double SHA256 of the serialization of:
     1. nVersion (4-byte little endian)
     2. hashPrevouts (32-byte hash)
     3. hashSequence (32-byte hash)
     4. outpoint (32-byte hash + 4-byte little endian)
     5. scriptCode (serialized as scripts inside CTxOuts)
     6. nAmount (8-byte little endian)
     7. nSequence (4-byte little endian)
     8. hashOutputs (32-byte hash)
     9. nLocktime (4-byte little endian)
    10. nInputIndex (4-byte little endian)
    11. nFees (8-byte little endian)
    12. hashtype (4-byte little endian)
    13. sigversion (4-byte little endian for the fixed value 0x01000000)

The bit 0 to 3 of hashtype denotes a value between 0 and 15:

	=E2=80=A2 If the value is 1, the signature is invalid.
	=E2=80=A2 If the value is 3 or below, hashPrevouts is the hash =
of all input, same as defined in BIP143. Otherwise, it is 32-byte of =
0x0000......0000.
	=E2=80=A2 If the value is 7 or below, outpoint is the COutPoint =
of the current input. Otherwise, it is 36-byte of 0x0000......0000.
	=E2=80=A2 If the value is 0, hashSequence is the hash of all =
sequence, same as defined in BIP143. Otherwise, it is 32-byte of =
0x0000......0000.
	=E2=80=A2 If the value is even (including 0), nSequence is the =
nSequence of the current input. Otherwise, it is 0x00000000.
	=E2=80=A2 If the value is 6, 7, 10, 11, 14, or 15, nInputIndex =
is 0x00000000. Otherwise, it is the index of the current input.
	=E2=80=A2 If the value is 11 or below, nAmount is the value of =
the current input (same as BIP143). Otherwise, it is 0x0000000000000000.

The bit 4 and 5 of hashtype denotes a value between 0 and 3:

	=E2=80=A2 If the value is 0, hashOutputs is same as the =
SIGHASH_ALL case in BIP143 as a hash of all outputs.
	=E2=80=A2 If the value is 1, the signature is invalid.
	=E2=80=A2 If the value is 2, hashOutputs is same as the =
SIGHASH_SINGLE case in BIP143 as a hash of the matching output. If a =
matching output does not exist, hashOutputs is 32-byte of =
0x0000......0000.
	=E2=80=A2 If the value is 3, hashOutputs is 32-byte of =
0x0000......0000.
If bit 6 is set (SIGHASH2_NOFEE), nFees is 0x0000000000000000. =
Otherwise, it is the fee paid by the transaction.
If bit 7 is set (SIGHASH2_NOLOCKTIME), nLockTime is 0x00000000. =
Otherwise, it is the transaction nLockTime.

If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x00000000. Otherwise, =
it is the transaction nVersion.

If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. =
Otherwise, it is same as described in BIP143.

Bits 10 to 15 are reserved and ignored, but the signature still commits =
to their value as hashtype.

hashtype of 0 is also known as SIGHASH2_ALL, which covers all the =
available options. In this case the singnature MUST be exactly 64-byte.

hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing =
and is effectively forfeiting the right related to this public key to =
anyone.

*Rationale

**Signature Format

The current DER format is a complete waste of block space. The new =
format saves ~8 bytes per signature.

**New hashtype definitions

The default and most commonly used case is SIGHASH2_ALL. Making it zero =
size to save space. As a result, the bit flags are defined in a negative =
way (e.g. NOLOCKTIME)

Why decouple INPUT and SEQUENCE? Maybe you want NOINPUT but still have a =
relative lock-time?

Why some combinations are missing? To save some bits for useless flags. =
If you sign all inputs, you must know its index and value. If you sign =
only this input, you must know its value, but probably don't know its =
index in the input vector.

Why only allow signing all SEQUENCE if all INPUT are signed? It doesn't =
make much sense if you care about their sequence without even knowing =
what they are.

Why signing INPUTINDEX? Legacy and BIP143 SINGLE|ANYONECANPAY behaves =
differently for input index. Better make it explicit and optional.

Why signing FEE? Sometimes you don't sign all inputs / outputs but still =
want to make sure the fees amount is correct.

Putting NOVERSION and NOSCRIPTCODE in the second byte makes most =
signatures below 66 bytes:

	=E2=80=A2 NOVERSION: Currently the only use of transaction =
version is to enforce BIP68. It could be safely assumed that version 2 =
is used. The only case one would like to use NOVERSION is to make the =
signature compatible with some unknown new features that use a different =
transaction version.
	=E2=80=A2 NOSCRIPTCODE: It would be very rare if one could make =
a signature without knowing what the script is (at least they know the =
public key). The only scenario that a NOSCRIPTCODE is really needed is =
the public key being reused in different scripts, and the user wants to =
use a single signature to cover all these scripts.
Reserved bits: These bits are ignored but should normally be unset. =
Users MUST NOT set these bits until they are defined by a future =
proposal, or they might lose money.
Why sigversion? Make sure the message digest won't collide with SIGHASH =
schemes in the past (legacy and BIP143) and future (which will use a =
different sigversion).

*Examples

Equivalent SIGHASH2 value for other SIGHASH schemes:
Legacy/BIP143 ALL: 0 (commit to everything)
Legacy/BIP143 SINGLE with matching output: 0x62 (all input, one =
sequence, one output, no fee)
Legacy SINGLE without matching output: 0x3ff (Not exactly. Both =
signatures commit to nothing, but the legacy one is valid only without a =
matched output. Practically, they are both "wildcard" signatures that =
allow anyone to spend any related UTXO)
Legacy/BIP143 NONE: 0x72 (all input, one sequence, no output, no fee)
Legacy/BIP143 ANYONECANPAY|ALL: 0x46 (one input without index, one =
sequence, all output, no fee)
Legacy ANYONECANPAY|SINGLE with matching output: 0x64 (one input with =
index, one sequence, one output, no fee)
Legacy/BIP143 ANYONECANPAY|NONE: 0x76 (one input without index, one =
sequence, no output, no fee)
BIP143 SINGLE without matching output: 0x62 (all input, one sequence, no =
output, no fee)
BIP143 ANYONECANPAY|SINGLE with matching output: 0x66 (one input without =
index, one sequence, one output, no fee)
BIP143 ANYONECANPAY|SINGLE without matching output: 0x66 (one input =
without index, one sequence, no output, no fee)
BIP118 NOINPUT: 0x14b (no input but with value, no index, no sequence, =
no fee, no scriptcode)

Notes:

1. In legacy and BIP143 SIGHASH, only ALL but not other types implicitly =
commits to the fee paid.
2. Legacy SIGHASH always implicitly commits to the input value. BIP143 =
and BIP118 commits to that explicitly.
3. Legacy and BIP143 SIGHASH behaves differently in the case of SINGLE =
without matching output. In legacy SIGHASH it is a true "wildcard =
signature" that allows anyone to spend any related UTXO. In BIP143 such =
signature applies only to a specific UTXO.
4. BIP143 ANYONECANPAY never commits to the input index. Legacy =
ANYONECANPAY|SINGLE implicitly commits to the input index.

*Backward compatibility

This is a soft-fork.

*Deployment

Exact details TBD.

*Reference Implementation

https://github.com/jl2012/bitcoin/commits/sighash2 (To be updated)

*Copyright

This document is licensed as BSD 3-clause.=