BIP 0322: Difference between revisions
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/19c429ee2831d898/bip-0322.mediawiki |
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/edffe529056f6dfd/bip-0322.mediawiki |
||
Line 78: | Line 78: | ||
vout[0].scriptPubKey = OP_RETURN | vout[0].scriptPubKey = OP_RETURN | ||
A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation. | A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation once it has been signed. | ||
=== Full (Proof of Funds) === | === Full (Proof of Funds) === | ||
Line 124: | Line 124: | ||
## The version of <code>to_sign</code> must be 0 or 2. | ## The version of <code>to_sign</code> must be 0 or 2. | ||
## The use of NOPs reserved for upgrades is forbidden. | ## The use of NOPs reserved for upgrades is forbidden. | ||
## The use of segwit versions greater than | ## The use of segwit versions greater than 1 are forbidden. | ||
## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state. | ## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state. | ||
# Let ''T'' by the nLockTime of <code>to_sign</code> and ''S'' be the nSequence of the first input of <code>to_sign</code>. Output the state ''valid at time T and age S''. | # Let ''T'' by the nLockTime of <code>to_sign</code> and ''S'' be the nSequence of the first input of <code>to_sign</code>. Output the state ''valid at time T and age S''. |
Revision as of 15:38, 15 December 2021
This page describes a BIP (Bitcoin Improvement Proposal). |
Please do not modify this page. This is a mirror of the BIP from the source Git repository here. |
BIP: 322 Layer: Applications Title: Generic Signed Message Format Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 Status: Draft Type: Standards Track Created: 2018-09-10 License: CC0-1.0
Abstract
A standard for interoperable signed messages based on the Bitcoin Script format, either for proving fund availability, or committing to a message as the intended recipient of funds sent to the invoice address.
Motivation
The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations.
Types of Signatures
This BIP specifies three formats for signing messages: legacy, simple and full. Additionally, a variant of the full format can be used to demonstrate control over a set of UTXOs.
Legacy
New proofs should use the new format for all invoice address formats, including P2PKH.
The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format.
Simple
A simple signature consists of a witness stack, consensus encoded as a vector of vectors of bytes, and base64-encoded. Validators should construct to_spend
and to_sign
as defined below, with default values for all fields except that
message_hash
is a BIP340-tagged hash of the message, as specified belowmessage_challenge
into_spend
is set to the scriptPubKey being signed withmessage_signature
into_sign
is set to the provided simple signature.
and then proceed as they would for a full signature.
Full
Full signatures follow an analogous specification to the BIP-325 challenges and solutions used by Signet.
Let there be two virtual transactions to_spend
and to_sign
.
The to_spend
transaction is:
nVersion = 0 nLockTime = 0 vin[0].prevout.hash = 0000...000 vin[0].prevout.n = 0xFFFFFFFF vin[0].nSequence = 0 vin[0].scriptSig = OP_0 PUSH32[ message_hash ] vin[0].scriptWitness = [] vout[0].nValue = 0 vout[0].scriptPubKey = message_challenge
where message_hash
is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = BIP0322-signed-message
, and message_challenge
is the to be proven (public) key script.
The to_sign
transaction is:
nVersion = 0 or as appropriate (e.g. 2, for time locks) nLockTime = 0 or as appropriate (for time locks) vin[0].prevout.hash = to_spend.txid vin[0].prevout.n = 0 vin[0].nSequence = 0 or as appropriate (for time locks) vin[0].scriptWitness = message_signature vout[0].nValue = 0 vout[0].scriptPubKey = OP_RETURN
A full signature consists of the base64-encoding of the to_sign
transaction in standard network serialisation once it has been signed.
Full (Proof of Funds)
A signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a full signature as above, with the following modifications.
message_challenge
is unused and shall be set toOP_TRUE
- Similarly,
message_signature
is then empty. - All outputs that the signer wishes to demonstrate control of are included as additional inputs of
to_sign
, and their witness and scriptSig data should be set as though these outputs were actually being spent.
Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys.
Detailed Specification
For all signature types, except legacy, the to_spend
and to_sign
transactions must be valid transactions which pass all consensus checks, except of course that the output with prevout 000...000:FFFFFFFF
does not exist.
Verification
A validator is given as input an address A (which may be omitted in a proof-of-funds), signature s and message m, and outputs one of three states
- valid at time T and age S indicates that the signature has set timelocks but is otherwise valid
- inconclusive means the validator was unable to check the scripts
- invalid means that some check failed
Verification Process
Validation consists of the following steps:
- Basic validation
- Compute the transaction
to_spend
from m and A - Decode s as the transaction
to_sign
- If s was a full transaction, confirm all fields are set as specified above; in particular that
to_sign
has at least one input and its first input spends the output of to_spendto_sign
has exactly one output, as specified above
- Confirm that the two transactions together satisfy all consensus rules, except for
to_spend
's missing input, and except that nSequence ofto_sign
's first input and nLockTime ofto_sign
are not checked.
- Compute the transaction
- (Optional) If the validator does not have a full script interpreter, it should check that it understands all scripts being satisfied. If not, it should stop here and output inconclusive.
- Check the **required rules**:
- All signatures must use the SIGHASH_ALL flag.
- The use of
CODESEPARATOR
orFindAndDelete
is forbidden. LOW_S
,STRICTENC
andNULLFAIL
: valid ECDSA signatures must be strictly DER-encoded and have a low-S value; invalid ECDSA signature must be the empty pushMINIMALDATA
: all pushes must be minimally encodedCLEANSTACK
: require that only a single stack element remains after evaluationMINIMALIF
: the argument ofIF
/NOTIF
must be exactly 0x01 or empty push- If any of the above steps failed, the validator should stop and output the invalid state.
- Check the **upgradeable rules**
- The version of
to_sign
must be 0 or 2. - The use of NOPs reserved for upgrades is forbidden.
- The use of segwit versions greater than 1 are forbidden.
- If any of the above steps failed, the validator should stop and output the inconclusive state.
- The version of
- Let T by the nLockTime of
to_sign
and S be the nSequence of the first input ofto_sign
. Output the state valid at time T and age S.
Signing
Signers who control an address A who wish to sign a message m act as follows:
- They construct
to_spend
andto_sign
as specified above, using the scriptPubKey of A formessage_challenge
and tagged hash of m asmessage_hash
. - Optionally, they may set nLockTime of
to_sign
or nSequence of its first input. - Optionally, they may add any additional outputs to
to_sign
that they wish to prove control of. - They satisfy
to_sign
as they would any other transaction.
They then encode their signature, choosing either simple or full as follows:
- If they added no inputs to
to_sign
, left nSequence and nLockTime at 0, and A is a Segwit address (either pure or P2SH-wrapped), then they may base64-encodemessage_signature
- Otherwise they must base64-encode
to_sign
.
Compatibility
This specification is backwards compatible with the legacy signmessage/verifymessage specification through the special case as described above.
Reference implementation
TODO
Acknowledgements
Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others for their feedback on the specification.
References
- Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html
Copyright
This document is licensed under the Creative Commons CC0 1.0 Universal license.
Test vectors
TODO