You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-0146.mediawiki
+69-13Lines changed: 69 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,27 +1,27 @@
1
1
<pre>
2
2
BIP: 146
3
-
Title: Dealing with signature malleability
4
-
Author: Pieter Wuille <pieter.wuille@gmail.com>
5
-
Johnson Lau <jl2012@xbt.hk>
3
+
Title: Dealing with signature encoding malleability
4
+
Author: Johnson Lau <jl2012@xbt.hk>
5
+
Pieter Wuille <pieter.wuille@gmail.com>
6
6
Status: Draft
7
7
Type: Standards Track
8
8
Created: 2016-08-16
9
9
</pre>
10
10
11
11
==Abstract==
12
12
13
-
This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability for common transaction types.
13
+
This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding.
14
14
15
15
16
16
==Motivation==
17
17
18
18
Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the <code>txid</code> and invalidate any unconfirmed child transactions. Although the <code>txid</code> of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vector will change the <code>wtxid</code> and may reduce the efficiency of compact block relay ([https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP152]).
19
19
20
-
Since the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in the signature passed to ECDSA verification opcodes:
20
+
Since the enforcement of Strict DER signatures ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]), there are 2 remaining known sources of malleability in ECDSA signatures:
21
21
22
22
# '''Inherent ECDSA signature malleability''': ECDSA signatures are inherently malleable as taking the negative of the number S inside (modulo the curve order) does not invalidate it.
23
23
24
-
# '''Inputs ignored by scripts''': The (unnecessary) extra stack element consumed by <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> is not inspected in any manner, and could be replaced with any value.
24
+
# '''Malleability of failing signature''': If a signature failed to validate in <code>OP_CHECKSIG</code> or <code>OP_CHECKMULTISIG</code>, a <code>FALSE</code> would be returned to the stack and the script evaluation would continue. The failing signature may take any value, as long as it follows all the rules described in BIP66.
25
25
26
26
This document specifies new rules to fix the aforesaid signature malleability.
27
27
@@ -35,33 +35,89 @@ To fix signature malleability, the following new rules are applied:
35
35
36
36
We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). Every signature passed to <code>OP_CHECKSIG</code><ref>Including pay-to-witness-public-key-hash (P2WPKH) described in BIP141</ref>, <code>OP_CHECKSIGVERIFY</code>, <code>OP_CHECKMULTISIG</code>, or <code>OP_CHECKMULTISIGVERIFY</code>, to which ECDSA verification is applied, MUST use a S value between <code>0x1</code> and <code>0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0</code> (inclusive) with strict DER encoding (see [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]).
37
37
38
-
These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the Low S value check, the entire script evaluates to false immediately. If the signature is valid DER with low S value, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to Low S value check).
38
+
If a signature passing to ECDSA verificationdoes not pass the Low S value check and is not an empty byte array, the entire script evaluates to false immediately.
39
39
40
40
A high S value in signature could be trivially replaced by <code>S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S</code>.
41
41
42
42
43
-
===NULLDUMMY===
43
+
===NULLFAIL===
44
44
45
-
The extra stack element consumed by <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> MUST be the empty byte array (the result of <code>OP_0</code>). Anything else makes the script evaluate to false immediately.
45
+
If an <code>OP_CHECKSIG</code> is trying to return a <code>FALSE</code> value to the stack, we require that the relevant signature must be an empty byte array.
46
+
47
+
If an <code>OP_CHECKMULTISIG</code> is trying to return a <code>FALSE</code> value to the stack, we require that all signatures passing to this <code>OP_CHECKMULTISIG</code> must be empty byte arrays, even the processing of some signatures might have been skipped due to early termination of the signature verification.
48
+
49
+
Otherwise, the entire script evaluates to false immediately.
50
+
51
+
52
+
==Examples==
53
+
54
+
The following examples combine the LOW_S and NULLFAIL rules.
55
+
56
+
Notation:
57
+
58
+
CO : curve order = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
59
+
HCO : half curve order = CO / 2 = 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0
60
+
P1, P2 : valid, serialized, public keys
61
+
S1L, S2L : valid low S value signatures using respective keys P1 and P2 (1 ≤ S ≤ HCO)
62
+
S1H, S2H : signatures with high S value (otherwise valid) using respective keys P1 and P2 (HCO < S < CO)
63
+
F : any BIP66-compliant non-empty byte array but not a valid signature
64
+
65
+
These scripts will return a <code>TRUE</code> to the stack as before:
66
+
67
+
S1L P1 CHECKSIG
68
+
0 S1L S2L 2 P1 P2 2 CHECKMULTISIG
69
+
70
+
These scripts will return a <code>FALSE</code> to the stack as before:
71
+
72
+
0 P1 CHECKSIG
73
+
0 0 0 2 P1 P2 2 CHECKMULTISIG
74
+
75
+
These previously <code>TRUE</code> scripts will fail immediately under the new rules:
76
+
77
+
S1H P1 CHECKSIG
78
+
0 S1H S2L 2 P1 P2 2 CHECKMULTISIG
79
+
0 S1L S2H 2 P1 P2 2 CHECKMULTISIG
80
+
0 S1H S2H 2 P1 P2 2 CHECKMULTISIG
81
+
82
+
These previously <code>FALSE</code> scripts will fail immediately under the new rules:
83
+
84
+
F P1 CHECKSIG
85
+
0 S2L S1L 2 P1 P2 2 CHECKMULTISIG
86
+
0 S1L F 2 P1 P2 2 CHECKMULTISIG
87
+
0 F S2L 2 P1 P2 2 CHECKMULTISIG
88
+
0 S1L 0 2 P1 P2 2 CHECKMULTISIG
89
+
0 0 S2L 2 P1 P2 2 CHECKMULTISIG
90
+
0 F 0 2 P1 P2 2 CHECKMULTISIG
91
+
0 0 F 2 P1 P2 2 CHECKMULTISIG
46
92
47
93
48
94
==Deployment==
49
95
50
-
This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9] using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.
96
+
This BIP will be deployed by "version bits" [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki BIP9]. Details TBD.
51
97
52
98
For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
53
99
54
-
For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).
100
+
For Bitcoin testnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).
55
101
56
102
57
103
==Compatibility==
58
104
59
-
The reference client has produced compatible signatures since v0.9.0, and NULLDUMMY and LOW_S have been enforced as relay policy by the reference client since v0.10.0 and v0.11.1 respectively. As of August 2016, very few transactions violating the requirement are being added to the chain. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement.
105
+
The reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.
106
+
107
+
Scripts with failing <code>OP_CHECKSIG</code> or <code>OP_CHECKMULTISIG</code> rarely happen on the chain. The NULLFAIL rule has been enforced as relay policy by the reference client since v0.13.1.
108
+
109
+
Users MUST pay extra attention to these new rules when designing exotic scripts.
60
110
61
111
62
112
==Implementation==
63
113
64
-
An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8533
114
+
Implementations for the reference client is available at:
0 commit comments