BIP146: change title and add NULLDUMMY rules

2 files changed, 27 insertions, 8 deletions

diff --git a/README.mediawiki b/README.mediawiki
index 26c65f0..070c9dc 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -513,7 +513,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Draft
 |-
 | [[bip-0146.mediawiki|146]]
-| Low S values signatures
+| Dealing with signature malleability
 | Pieter Wuille, Johnson Lau
 | Standard
 | Draft
diff --git a/bip-0146.mediawiki b/bip-0146.mediawiki
index f57aa21..c92c54e 100644
--- a/bip-0146.mediawiki
+++ b/bip-0146.mediawiki
@@ -1,6 +1,6 @@
 <pre>
   BIP: 146
-  Title: Low S values signatures
+  Title: Dealing with signature malleability
   Author: Pieter Wuille <pieter.wuille@gmail.com>
           Johnson Lau <jl2012@xbt.hk>
   Status: Draft
@@ -10,22 +10,40 @@
 
 ==Abstract==
 
-This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to using low S values.
+This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability for common transaction types.
 
 
 ==Motivation==
 
-ECDSA signatures are inherently malleable as taking the negative of the number S inside (modulo the curve order) does not invalidate it. This is a nuisance malleability vector as any relay node on the network may transform the signature, with no access to the relevant private keys required. For non-segregated witness transactions, this 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]).
+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]).
 
-To fix this 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). The value S in signatures must be between <code>0x1</code> and <code>0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0</code> (inclusive). If S is too high, simply replace it by <code>S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S</code>.
+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:
+
+# '''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.
+
+# '''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.
+
+This document specifies new rules to fix the aforesaid signature malleability.
 
 
 ==Specification==
 
-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]).
+To fix signature malleability, the following new rules are applied:
+
+
+===LOW_S===
+
+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]).
 
 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).
 
+A high S value in signature could be trivially replaced by <code>S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S</code>.
+
+
+===NULLDUMMY===
+
+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.
+
 
 ==Deployment==
 
@@ -38,15 +56,16 @@ For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch t
 
 ==Compatibility==
 
-The reference client has produced compatible signatures since v0.9.0, and the requirement to have low S value signatures has been enforced as a 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. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability.
+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.
 
 
 ==Implementation==
 
-An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8514
+An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8533
 
 
 ==Footnotes==
+
 <references />