BIP-322: Add type prefix, change PoF serialization, PSBT-based signing
Oliver
I've started an implementation of BIP-322 in Go ([1]), and during implementation I noticed
that a number of open questions remain.
I believe that these open questions and the "Draft" status are contributing reasons for the
BIP not being widely implemented.
I do see demand for generic message signing in discussions and pull requests, though, so I'm
taking a shot at helping to move the BIP forward ([2]).
In short, I'm proposing three major changes:
- Introduce a human-readable prefix to distinguish the three signature variants.
- Change the encoding format of the "Proof of Funds" variant to include UTXO information.
- Introduce a new PSBT field for for PSBT-based message signing.
Let me explain the details and reasoning behind the changes:
Human-readable prefix
------
As in an earlier discussion ([3]), not having a prefix and needing to attempt decoding both
initially proposed formats to detect which one a signature used is cumbersome, potentially
error prone and requires careful implementation.
Introducing a simple fixed-length (for easy detection and parsing) human-readable prefix that
is simply prepended to the base64-encoded signature should make detection quite straightforward
in code and also make it easy to distinguish a BIP-322 signature from a legacy one.
The proposed prefixes are: `smp`, `ful`, `pof` for the 'simple', 'full' and 'Proof of Funds'
variants respectively.
Because there already are implementations of BIP-322 out there, I also added a backward
compatibility clause for existing implementations. Observing that many of the implementations
I found and looked at only produce signatures of the 'simple' variant, an implementation may
assume the 'simple' format if it doesn't detect a valid prefix.
Encoding format of the "Proof of Funds" variant
------
The "Proof of Funds" variant allows attesting spendability of specific UTXOs. While the
selection and purpose of the UTXOs (e.g., completeness or unspent status) remain out of scope
of the BIP, it is my opinion that it should at least be possible to validate (offline) that
the witness of a BIP-322 `to_sign` transaction is valid, should be part of the specification.
However, validating the witness of an additional input requires its UTXO information.
Instead of coming up with a custom encoding for the UTXO information in addition to the
full `to_sign` transaction, I realized that a finalized PSBT contains exactly the information
we require: The full transaction, the witness and/or signature scripts and the (Non-)Witness
UTXO fields. A finalized PSBT also must not contain fields that may be detrimental to privacy,
like internal keys, xPubs or script information.
Therefore, I propose that the encoding format for the "Proof of Funds" variant should be the
full, base64-encoded PSBT of the `to_sign` transaction, but in the "finalized" state as
described in BIP-174.
Because non-witness inputs require the whole previous transaction to be present, I also added
a size optimization that allows this field to be reused between inputs if more than one input
references the same previous transaction.
New PSBT field for PSBT-based message signing
------
When creating a signature for a multisig address script, it makes sense to use a PSBT to get
a signature for the `to_sign` transaction from each signer.
However, although a signer produces a signature for a _transaction_, their intent is to sign
a _message_. Signing software and devices should be able to show that fact in their user
interface, as a BIP-322 transaction would look unusual to a user when presented as such
(spending a zero-value output into an OP_RETURN output).
I propose to add a new field (PSBT_IN_GENERIC_SIGNED_MESSAGE, 0x21) to the first input of
the PSBT-wrapped `to_sign` transaction that contains the full message to be signed. A signing
device or software can then detect and present such a message-signing PSBT in an appropriate
way to the user.
The detection and signature producing procedure is also explained in detail in my proposed
BIP body.
The above changes are the most notable changes, but my Pull Request to the BIP ([2]) also
addresses additional discussion points raised in Bitcoin Core PRs and previous mailing list
discussions:
- Clarify intent and terminology of the BIP, make it clear what it can't prove (the PR body
[2] contains links to the relevant discussions).
- Add extensive test vectors for all the variants.
- Propose the status to move to "Complete".
- Offer myself to be a deputy to BIP-322 as described in BIP-3.
I'm looking forward to your feedback and to further discussion here or on the BIPs PR ([2]).
Oli
[1]: https://github.com/btcsuite/btcd/pull/2521
[2]: https://github.com/bitcoin/bips/pull/2141
[3]: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/NsFQcCcaCAAJ
Thomas Suau
Hi Oli,
Concept ACK on the direction. Good to see this this moving forward.
I work on PSBT tooling (author of BTSL [1], a declarative validation layer for multi-party PSBT workflows) so the PSBT parts caught my attention.
On PSBT_IN_GENERIC_SIGNED_MESSAGE (0x21)
Why a per-input field rather than global? The signed message is a property of the whole `to_sign` transaction, not of input 0 specifically. Placing it there works but creates an implicit convention that the first input carries transaction-wide metadata. Was there a reason to avoid PSBT_GLOBAL_*?
On Proof of Funds as finalized PSBT
Clean choice. One question: how does a parser that ingests PSBTs generically distinguish a BIP-322 proof-of-funds from a regular transaction PSBT? Is 0x21 on the first input sufficient as discriminant, or does this need an explicit marker?
The problem you identify — signer sees a zero-value-to-OP_RETURN transaction with no idea they're signing a message — extends beyond BIP-322 to any multi-party PSBT workflow where the signer lacks semantic context. I've been working on the same gap from a different angle with BTSL [1][2]. Different mechanism, same problem. Worth noting because it suggests "signer context" deserves to be a first-class concern in PSBT design broadly.
Cheers,
Thomas
[1] https://github.com/tsua0002/btsl-standard
[2] https://btsl-playground.vercel.app
Oliver
thomas s.
Hi Oli,
Thanks for the detailedd reply and for the detection section — the five checks are solid, especially the cryptographic binding via to_spend.txid in in check 4.
On the per-input vs global question: since you're open to either, I'd argue for a global field (PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE).
The message text isn't data required to satisfy input 0's script — it's semantic context about what the whole transaction represents. That maps cleanly to the global/per-input split in BIP-174: global fields carry transaction-wide metadata, per-input fields carry what's needed to sign that specific input.
Putting it on input 0 works mechanically but sets a precedent where transaction-level metadata lives on an arbitrary input by convention. A global field avoids that and keeps the detection logic just as simple — check 1 moves from input-level to global-level, everything else stays the same.
Thomas
--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/qd6BNz9gxCk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6dc35b8a-e837-4fc9-9a17-ca29204bf738n%40googlegroups.com.