From: Oliver <gugger@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] BIP-322: Add type prefix, change PoF serialization, PSBT-based signing
Date: Mon, 20 Apr 2026 00:22:10 -0700 (PDT) [thread overview]
Message-ID: <2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 5251 bytes --]
Dear mailing list
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
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5935 bytes --]
next reply other threads:[~2026-04-20 7:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 7:22 Oliver [this message]
2026-04-20 14:47 ` [bitcoindev] " Thomas Suau
2026-04-21 9:16 ` Oliver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an@googlegroups.com \
--to=gugger@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox