Comment on page
Vertical: Bitcoin protocol
Title: Deterministic bitcoin commitments
Author: Dr Maxim Orlovsky <[email protected]>
Type: Standards Track
Finalized: not yet
Related standards: LNPBP-1, 2, 4, 7, 9, 92
The proposal provides standard mechanism for creating, structuring & verifying deterministic bitcoin commitments ("anchoring") to multiple extra-transaction data (client-side-validated etc).
Miltiple protocols may commit to external (non-transaction and non-blockchain) data by constructing a special data structure called anchor and committing to its content inside transaction input or output.
A party needing to commit to multiple data coming from distinct protocols MUST follow the algorithm:
- 1.Construct LNPBP-4 multi-message commitment;
- 2.Deterministically define transaction input or output which will contain the final commitment. This algorithm is not a part of the current specification and must be defined at upper protocol level (see for instance LNPBP-10).
- 3.Run commitment embedding procedure:
- If commitment will be placed into transaction output, construct extra-transaction proof using procedure from LNPBP-2; fail algorithm if the LNPBP-2 requirements can't be fulfilled.
- If commitment will be placed into transaction input, construct extra-transaction proof using procedure from LNPBP-92; fail algorithm if the LNPBP-92 requirements can't be fulfilled.
- 4.Construct anchor data structure (see below), encode it and persist the data as long as it will be required to provide proofs of the commitment.
If algorithm failed the party creating commitment MAY change the structure of the transaction and try to repeat the commitment procedure.
The verification process runs by repeating steps of the commitment protocol using the information provided during the reveal phase and verifying the result is equal to the provided proofs. If the commitment procedure fails at any of the steps, the verification procedure MUST also fail.
Ahcnor consists of the following fields, serialized according to the strict serialization rules (see LNPBP-7):
txid: 32-byte transaction id
commitment: a commutment block structure from LNPBP-4
proof: a deterministic commitment proof which has the same structure for both LNPBP-2 and LNPBP-92 commitment:
original_pubkey: original 33-byte value of the pubkey before tweak; for pay-to-signature (LNPBP-92) tweaks this is
Rvalue generated from a nonce. BIP-340 keys MUST be encoded as 33 byte value having first byte
script_info: an enum, encoded with a first byte representing enum variant
0x00 = SinglePubkey: always used by LNPBP-92 and by LNPBP-2 commitments based on P2PK, P2PKH, P2WPKH, legacy SegWit v0 P2WPKH-in-P2SH, P2TR with key spending only (self-tweaked), OP_RETURN and other bare script outputs.
0x01 = LockScript: a Bitcoin script source which knowledge is required to satisfy spending for pre-SegWit P2SH, native SegWit v0 P2WSH. The enum variant byte MUST be followed by a strict-encoded representation of binary script data. This script MUST match
redeemScriptfor P2SH and
0x02 = WrappedWitnessScript: Bitcoin script source which knowledge is required to satisfy spending for legacy (P2SH-wrapped) SegWit v0, P2WSH-in-P2SH outputs (and, potentially, fututre SegWit versions). The enum variant byte MUST be followed by a strict-encoded representation of binary script data. This script MUST match
witnessScriptfor P2WSH; for P2SH wrapped version it also must be a
0x03 = TaprootScript: a Merkle root of the script spending path of the taproot output or a value of a tweak applied to the internal taproot key if and only if this tweak is not a self-tweak. Must be followed by exatly 32 bytes (without length prefix) of the tweak data in little endinan order.
The list of
script_infovariants is non-exhaustive. If a future version of script info varian byte is met the deserialization of anchor data MUST fail with explicit error and the anchor MUST not be verified.
If the anchor data does not match the provided script pubkey (for instance, being encoded as P2WSH-in-P2SH instead of P2WSH) the verifying party MUST fail verification even if other option is satisfied with other (non-specified) encoding.
Anchor data contain extra information which is not required for the DBC validation and represents additional proofs for non-DBC validation procedures. This information is contained in
commitmentfield of the anchor data structure containing LNPBP-4 multi-message commitment entrypy value, used for proving the absense of some specific protocol within the commitment tree. This information MAY be discarded for privacy reasons when the anchor data are passed to a third-party with a special conceal procedure as described in LNPBP-4 and LNPBP-9 standards.
TaprootScript) for Taproot outputs having no script path spending conditions (i.e. self-tweaked keys) instead of
SinglePubkey) will result in storing additional 32 bytes on the client side per each output of this type, while providing no privacy gains: a user hacing access to the anchor data can always make sure that the value of the script tweak is equal to the self-tweak and still acquire knowledge that the output does not contain a script path spending condition.
P2WSH-in-P2SH require its own script info variant (
WrappedWitnessScript) since this allows to simplify verification algorithm by avoiding trying multiple script encodings (native P2SH and legacy P2WSH-in-P2SH). This does not reduce forward compatibility: we may have 252 more variants for script info value, which is exceeds a possible number of future bitcoin script pubkey encoding (15 possible future witness values).
If the implementation differs from the spec, the spec has a higher priority.
This document is licensed under the Creative Commons CC0 1.0 Universal license.