- Bitcoin & Blockchain/
- P2P Network Overview/
- BCH Specification/
- Historical Upgrades
- May 2021 Upgrade
- Multiple OP_RETURNs
- Accept more tx in mempool
- ASERT DAA
- November 2020 Upgrade
- May 2020 Upgrade
- SigCheck protection
- November 2019 Upgrade
- Schnorr multisig
- Segwit Recovery
- May 2019 Upgrade
- November 2018 Upgrade
- Schnorr signatures
- May 2018 Upgrade
- Reenable Opcodes
- November 2017 Upgrade
- Bitcoin Cash
- Tx signing digest
- BIP 152
- BIP 133
- BIP 9
- Mempool message
- Block Versions
- Protocol Versions
- Transaction Versions
Bitcoin Cash Protocol Upgrades
BIP: 66 Layer: Consensus (soft fork) Title: Strict DER signatures Author: Pieter Wuille <firstname.lastname@example.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0066 Status: Final Type: Standards Track Created: 2015-01-10 License: BSD-2-Clause
This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding.
This BIP is licensed under the 2-clause BSD license.
Bitcoin’s reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin’s block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software.
One specifically critical area is the encoding of signatures. Until recently, OpenSSL’s releases would accept various deviations from the DER standard and accept signatures as valid. When this changed in OpenSSL 1.0.0p and 1.0.1k, it made some nodes reject the chain.
This document proposes to restrict valid signatures to exactly what is mandated by DER, to make the consensus rules not depend on OpenSSL’s signature parsing. A change like this is required if implementations would want to remove all of OpenSSL from the consensus code.
Every signature passed to
OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, must be encoded using strict DER encoding (see further).
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 IsValidSignatureEncoding check below, the entire script evaluates to false immediately. If the signature is valid DER, 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 IsValidSignatureEncoding).
DER encoding reference
The following code specifies the behaviour of strict DER checking. Note that this function tests a signature byte vector which includes the 1-byte sighash flag that Bitcoin adds, even though that flag falls outside of the DER specification, and is unaffected by this proposal. The function is also not called for cases where the length of sig is 0, in order to provide a simple, short and efficiently-verifiable encoding for deliberately invalid signatures.
DER is specified in https://www.itu.int/rec/T-REC-X.690/en .
Notation: P1 and P2 are valid, serialized, public keys. S1 and S2 are valid signatures using respective keys P1 and P2. S1’ and S2’ are non-DER but otherwise valid signatures using those same keys. F is any invalid but DER-compliant signature (including 0, the empty string). F’ is any invalid and non-DER-compliant signature.
- S1’ P1 CHECKSIG fails (changed)
- S1’ P1 CHECKSIG NOT fails (unchanged)
- F P1 CHECKSIG fails (unchanged)
- F P1 CHECKSIG NOT can succeed (unchanged)
- F’ P1 CHECKSIG fails (unchanged)
- F’ P1 CHECKSIG NOT fails (changed)
- 0 S1’ S2 2 P1 P2 2 CHECKMULTISIG fails (changed)
- 0 S1’ S2 2 P1 P2 2 CHECKMULTISIG NOT fails (unchanged)
- 0 F S2’ 2 P1 P2 2 CHECKMULTISIG fails (unchanged)
- 0 F S2’ 2 P1 P2 2 CHECKMULTISIG NOT fails (changed)
- 0 S1’ F 2 P1 P2 2 CHECKMULTISIG fails (unchanged)
- 0 S1’ F 2 P1 P2 2 CHECKMULTISIG NOT can succeed (unchanged)
Note that the examples above show that only additional failures are required by this change, as required for a soft forking change.
We reuse the double-threshold switchover mechanism from BIP 34, with the same thresholds, but for nVersion = 3. The new rules are in effect for every block (at height H) with nVersion = 3 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 3. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 3, nVersion = 2 blocks become invalid, and all further blocks enforce the new rules.
The requirement to have signatures that comply strictly with DER has been enforced as a relay policy by the reference client since v0.8.0, and very few transactions violating it are being added to the chain as of January 2015. 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 (see BIP 62).
An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/5713 .
This document is extracted from the previous BIP62 proposal, which had input from various people, in particular Greg Maxwell and Peter Todd, who gave feedback about this document as well.
- Subsequent to the network-wide adoption and enforcement of this BIP, the author disclosed that strict DER signatures provided an indirect solution to a consensus bug he had previously discovered.