From 47b050ac98969054848db7caa4a55a19aaf3a20f Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Fri, 17 Oct 2014 14:00:46 -0700 Subject: [PATCH 01/10] Instead of repeating some problem names, give the rules meaningful ones --- bip-0062.mediawiki | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 9d5bfe572f..5acf5fc8be 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -38,13 +38,13 @@ The first six and part of the seventh can be fixed by extra consensus rules, but ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Canonically encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. -# '''Non-push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. -# '''Push operations in scriptSig of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. -# '''Zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. -# '''Inherent ECDSA signature malleability''' 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). See reference: [[#low-s-values-in-signatures|Low S values in signatures]]. -# '''Superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. -# '''Inputs ignored by scripts''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false. +# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Only push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. +# '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. +# '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. +# '''Require low S in ECDSA signatures''' 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). See reference: [[#low-s-values-in-signatures|Low S values in signatures]]. +# '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. +# '''Inputs ignored by scripts are 0''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false. ===Block validity=== From bb863dc6d83db63dc36a8d290bab09d566a75c4c Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Sun, 26 Oct 2014 00:44:23 -0700 Subject: [PATCH 02/10] BIP62 rule 6 and P2SH Clarify that BIP62 rule 6 (clean stack) only applies after potential P2SH redeemscript evaluation. Applying it before the redeemscript evaluation means that every P2SH script will fail it, as P2SH by definition uses an unclean stack (to specify the redeemscript inputs). --- bip-0062.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 5acf5fc8be..06a328c668 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -43,7 +43,7 @@ Seven extra rules are introduced, to combat exactly the seven first sources of m # '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. # '''Require low S in ECDSA signatures''' 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). See reference: [[#low-s-values-in-signatures|Low S values in signatures]]. -# '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. +# '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. For P2SH scripts, this check is only done after the redeemscript evaluation, not after the actual script evaluation. # '''Inputs ignored by scripts are 0''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false. ===Block validity=== From 72475226e76b6de1068bd050bc13685dfcdc855b Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Tue, 4 Nov 2014 23:38:27 -0800 Subject: [PATCH 03/10] Clarify that correct hashtypes are not required. --- bip-0062.mediawiki | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 06a328c668..c564ea46a5 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -38,7 +38,7 @@ The first six and part of the seventh can be fixed by extra consensus rules, but ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding, though the hashtype byte that follows it can be anything. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. # '''Only push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. @@ -63,18 +63,20 @@ Below is a summary of the effects on signatures, their encoding and data pushes. The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S. -The constraints on the value R is unchanged w.r.t. ECDSA, and can be between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (inclusive). +The constraints on the value R is unchanged w.r.t. ECDSA, and can be between 0x1 and 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (inclusive). ====DER encoding==== For reference, here is how to encode signatures correctly in DER format. -0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type] +0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] * total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte. * R-length: 1-byte length descriptor of the R value that follows. * R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required. * S-length: 1-byte length descriptor of the S value that follows. * S: arbitrary-length big-endian encoded S value. The same rules apply as for R. -* sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed). + +The DER signature is followed by a 1-byte hashtype flag, which is Bitcoin-specific and not part of DER. + This is already enforced by the reference client as of version 0.8.0 (only as relay policy, not as a consensus rule). This rule, combined with the low S requirement above, results in S-length being at most 32 (and R-length at most 33), and the total signature size being at most 72 bytes (and on average 71.494 bytes). From 3b9d5df9f10a0e31cafe56df51ae461c50f380b5 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Tue, 4 Nov 2014 23:42:21 -0800 Subject: [PATCH 04/10] Use v2 transactions instead of v3, and apply the optional rules only to exactly v2. --- bip-0062.mediawiki | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index c564ea46a5..a92ae993ae 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -48,12 +48,12 @@ Seven extra rules are introduced, to combat exactly the seven first sources of m ===Block validity=== -To introduce these new rules in the network, we add both v3 blocks and v3 transactions. v2 is skipped for transactions to keep the version numbers between transaction and block rules in sync. v2 transactions are treated identically to v1 transactions. +To introduce these new rules in the network, we add both v3 blocks and v2 transactions. The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated: -* All transactions in v3 blocks are required to follow rules #1-#2. -* v3 (and higher) transactions in v3 blocks are required to follow rules #3-#7 as well. +* All transactions in v3 blocks are required to follow rules #1 and #2. +* v2 transactions in v3 blocks are required to follow rules #3-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block. -When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 (and v2) transactions remain valid forever. +When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 transactions remain valid forever. ===References=== @@ -108,6 +108,6 @@ In particular, note that zero could be encoded as (01 80) (negative zero) if usi ==Compatibility== -'''Relay of transactions''' A new node software version is released which makes v3 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v3 transaction is also unaffected. +'''Relay of transactions''' A new node software version is released which makes v2 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v2 transaction is also unaffected. -'''Wallet updates''' As v3 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v3 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software. +'''Wallet updates''' As v2 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v2 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software. From 7eaf5714c3a288a015b8dd5d04cde80758751923 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Wed, 5 Nov 2014 00:14:52 -0800 Subject: [PATCH 05/10] typo --- bip-0062.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index a92ae993ae..2aee1f96ba 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -110,4 +110,4 @@ In particular, note that zero could be encoded as (01 80) (negative zero) if usi '''Relay of transactions''' A new node software version is released which makes v2 transactions standard, and relays them when their scriptSigs satisfy the above rules. Relaying of v1 transactions is unaffected. A v1 transaction spending an output created by a v2 transaction is also unaffected. -'''Wallet updates''' As v2 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to confirm to the new rules of course, but using v2 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software. +'''Wallet updates''' As v2 transactions are non-standard currently, it is not possible to start creating them immediately. Software can be checked to comply to the new rules of course, but using v2 should only start when a significant part of the network's nodes has upgraded to compatible code. Its intended meaning is "I want this transaction protected from malleability", and remains a choice of the wallet software. From ea0795b10627164dff837310072e6e50daf0cd4a Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Sat, 8 Nov 2014 08:46:07 -0800 Subject: [PATCH 06/10] Strict DER is also required for non-evaluated CHECKMULTISIG inputs --- bip-0062.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 2aee1f96ba..74db2e8432 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -38,11 +38,11 @@ The first six and part of the seventh can be fixed by extra consensus rules, but ===New rules=== Seven extra rules are introduced, to combat exactly the seven first sources of malleability listed above: -# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding, though the hashtype byte that follows it can be anything. Doing a verification with a non-DER signature makes the entire script evaluate to False (not just the signature verification). See reference: [[#der-encoding|DER encoding]]. +# '''Require DER encoded ECDSA signatures''' An ECDSA signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY must be encoded using strict DER encoding, though the hashtype byte that follows it can be anything. Doing a verification with any non-DER signature passed to it makes the entire script evaluate to False, even when an invalid signature is encountered before (which would otherwise make the opcode evaluate to False, but not necessarily the entire script). See reference: [[#der-encoding|DER encoding]]. # '''Only push operations in scriptSig''' Only data pushes are allowed in scriptSig. Evaluating any other operation makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''No push operations of non-standard size type''' The smallest possible push operation must be used when possible. Pushing data using an operation that could be encoded in a shorter way makes the script evaluate to false. See reference: [[#push-operators|Push operators]]. # '''No zero-padded number pushes''' Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: [[#numbers|Numbers]]. -# '''Require low S in ECDSA signatures''' 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). See reference: [[#low-s-values-in-signatures|Low S values in signatures]]. +# '''Require low S in ECDSA signatures''' We require that the S value inside all ECDSA signatures passed to any of the CHECKSIG operators is at most the curve order divided by 2 (essentially restricting this value to its lower half range). See reference: [[#low-s-values-in-signatures|Low S values in signatures]]. # '''No superfluous scriptSig operations''' scriptPubKey evaluation will be required to result in a single non-zero value. If any extra data elements remain on the stack, the script evaluates to false. For P2SH scripts, this check is only done after the redeemscript evaluation, not after the actual script evaluation. # '''Inputs ignored by scripts are 0''' The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0). Anything else makes the script evaluate to false. From 8d7acb2d5ec451ba59f41aad120749ed9a62b0de Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Sun, 9 Nov 2014 01:18:29 -0500 Subject: [PATCH 07/10] Add signature reordering to list of malleability sources --- bip-0062.mediawiki | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 74db2e8432..75406a185f 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -31,7 +31,8 @@ Several sources of malleability are known: # '''Inputs ignored by scripts''' If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored. # '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing. # '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs. -The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself). +# '''Signature reordering''' If a signature is valid for more than one pubkey, for instance due to a CHECKMULTISIG where two or more of the keys are equivalent, the order of signatures can be changed. +The first six and part of the seventh can be fixed by extra consensus rules, but the last three can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself). ==Specification== From 439f1fffb5b30224848cd3a2f7013a35ff222f16 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Sun, 9 Nov 2014 03:35:27 -0800 Subject: [PATCH 08/10] Make rule 2 non-mandatory --- bip-0062.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 75406a185f..346b91f767 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -51,8 +51,8 @@ Seven extra rules are introduced, to combat exactly the seven first sources of m To introduce these new rules in the network, we add both v3 blocks and v2 transactions. The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of the past 1000 blocks are v3, a new consensus rule is activated: -* All transactions in v3 blocks are required to follow rules #1 and #2. -* v2 transactions in v3 blocks are required to follow rules #3-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block. +* All transactions in v3 blocks are required to follow rule #1. +* v2 transactions in v3 blocks are required to follow rules #2-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block. When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 transactions remain valid forever. From e25e2a179e3988bcf63464a76619f6c829700ce3 Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Sun, 9 Nov 2014 03:38:32 -0800 Subject: [PATCH 09/10] At 95%, the new rules apply to old blocks --- bip-0062.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 346b91f767..0c70a34355 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -54,7 +54,7 @@ The same mechanism as in BIP 0034 is used to introduce v3 blocks. When 75% of th * All transactions in v3 blocks are required to follow rule #1. * v2 transactions in v3 blocks are required to follow rules #2-#7 as well. Transactions with version 1 or a version higher than 2 do not have this requirement, even when in a v3 block. -When 95% of the past 1000 blocks are v3 or higher, v2 blocks become invalid entirely. Note however that v1 transactions remain valid forever. +When 95% of the past 1000 blocks are v3 or higher, the above rules start applying for every block, and v3 for blocks loses special meaning, so it can be reused. Note however that v1 transactions remain valid forever. ===References=== From 492d090c1c752f009b7a7fc456ae19767834b01c Mon Sep 17 00:00:00 2001 From: Pieter Wuille Date: Sun, 9 Nov 2014 04:10:44 -0800 Subject: [PATCH 10/10] Problem 10 is also under control of the script creator --- bip-0062.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0062.mediawiki b/bip-0062.mediawiki index 0c70a34355..efcebae1d2 100644 --- a/bip-0062.mediawiki +++ b/bip-0062.mediawiki @@ -32,7 +32,7 @@ Several sources of malleability are known: # '''Sighash flags based masking''' Sighash flags can be used to ignore certain parts of a script when signing. # '''New signatures by the sender''' The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs. # '''Signature reordering''' If a signature is valid for more than one pubkey, for instance due to a CHECKMULTISIG where two or more of the keys are equivalent, the order of signatures can be changed. -The first six and part of the seventh can be fixed by extra consensus rules, but the last three can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself). +The first six and part of the seventh can be fixed by extra consensus rules, but the last three can't. Not being able to fix #7 and #10 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable. However, when restricted to using a safe set of output scripts, extra consensus rules can make spending transactions optionally non-malleable (if the spender chooses to; as he can always bypass #8 and #9 himself). ==Specification==