clarify what is meant by "BIP 62" compliance

[kristovatlas]

At some point, it would be helpful to clarify what we mean by BIP 62 compliance.

The BIP has been withdrawn and parts of it may are probably not applicable to the privacy goal we're attempting to measure. If we don't know exactly what we're looking for, it's also unlikely that wallet providers know what is meant by BIP 62 compliance.

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

It would be great if we could enumerate these points. If we can, I think I can write a tool to test compliance, comparable to: http://www.openbitcoinprivacyproject.org/bip69-test/

[kristovatlas]

I'm fine with can-kicking this to 4th edition milestone, but wonder if @dcousens already has some insight into this.

[kristovatlas]

Checklist:

• ECDSA Signatures are strict DER encoded, per BIP 66; unlikely that any wallets are not adhering to this as it's been a relay policy for 1.5 years. Reference about DER: https://wiki.openssl.org/index.php/DER Also the "DER encoding" section of this document outlines how to do proper DER encoding
• Scripts that uses push operations must adhere to the rules outlined in the "Push operators" section of this document
• 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.
• 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.
  • 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
• scriptPubKey evaluation results in a single non-zero value, with no extra data elements remaining on the stack
• The (unnecessary) extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY must be the empty byte array (the result of OP_0)

[kristovatlas]

After thoroughly reading BIP 62, I think it's fairly clear. I would find it useful to create a tool to fact-check developers who may get this wrong, though, since most wallet providers are using libraries to build transactions and may not understand all of these details.

[kristovatlas]

An existing tool for DER encoding: https://github.com/bitcoinjs/bip66 via @dcousens