Abstract

A standard for interoperable generic signed messages based on the Bitcoin Script format.

Motivation

The current message signing standard only works for P2PKH (1...) addresses. By extending it to use a Bitcoin Script based approach, it could be made more generic without causing a too big burden on implementers, who most likely have access to Bitcoin Script interpreters already.

Specification

A new structure SignatureProof is added, which is a simple serializable scriptSig & witness container.

Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds".

Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD)

Let sighash = sha256(sha256(scriptPubKey || pre-image))

Purpose: ProveFunds

The "ProveFunds" purpose generates a sighash and a scriptPubKey from a transaction, an output index, and a message. For multiple simultaneous proofs, it also requires access to the ordered list of proofs. It emits a VALID verification result code unless otherwise stated.

Let txid be the transaction ID of the transaction, and vout be the output index corresponding to the index of the output being spent

Compatibility

This specification is not backwards compatible with the legacy signmessage/verifymessage specification. However, legacy addresses (1...) may be used in this implementation without any problems.

Rationale

^Why support multiple proofs? In particular with proof of funds, it is non-trivial to check a large number of individual proofs (one per UTXO) for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.

^Why track duplicates? Because a 3-entry proof is not proving 3 inputs unless they are all distinct

^Synced up or not? A normal verifier would use a synced up node. An auditor checking records from a client that were submitted in the past want to use a node that is synced up to the block corresponding to the proof, or the proof will fail, even if it may have been valid at the time of creation.

^Why not just the UTXO data? We want the verifier to be able to challenge the prover with a custom message to sign, or anyone can reuse the POF proof for a set of UTXO:s once they have seen it, and the funds have not yet been spent