* [bitcoindev] BIP-322: Add type prefix, change PoF serialization, PSBT-based signing
@ 2026-04-20 7:22 Oliver
2026-04-20 14:47 ` [bitcoindev] " Thomas Suau
0 siblings, 1 reply; 3+ messages in thread
From: Oliver @ 2026-04-20 7:22 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: BIP-322: Add type prefix, change PoF serialization, PSBT-based signing
2026-04-20 7:22 [bitcoindev] BIP-322: Add type prefix, change PoF serialization, PSBT-based signing Oliver
@ 2026-04-20 14:47 ` Thomas Suau
2026-04-21 9:16 ` Oliver
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Suau @ 2026-04-20 14:47 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7165 bytes --]
------------------------------
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
Le lundi 20 avril 2026 à 09:26:14 UTC+2, Oliver a écrit :
> 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/fa1ca8ae-385a-4f16-85c2-544f8667b00en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8524 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* [bitcoindev] Re: BIP-322: Add type prefix, change PoF serialization, PSBT-based signing
2026-04-20 14:47 ` [bitcoindev] " Thomas Suau
@ 2026-04-21 9:16 ` Oliver
0 siblings, 0 replies; 3+ messages in thread
From: Oliver @ 2026-04-21 9:16 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8751 bytes --]
Hi Thomas
Thank you for your feedback and questions!
Whether the new PSBT field should be on the input or a global field is a
good question.
I did ask myself the same thing and then slightly leaned toward adding it
to the input that directly references the TXID that contains the message
hash.
But I don't have strong opinions either way, so a global field would
definitely also work.
> how does a parser that ingests PSBTs generically distinguish a BIP-322
proof-of-funds from a regular transaction PSBT?
I did add a section that covers detection to the BIP, see
https://github.com/bitcoin/bips/blob/518dc68dcd3d8793c66128638cc61f60c6007eeb/bip-0322.mediawiki#user-content-PSBT_signer
I made it as strict as possible to minimize the chance of a false positive.
The 0x21 field is a good indication that the PSBT contains a message to be
signed but the additional checks I propose also help to make sure it's a
well-formed and valid BIP-322 PSBT.
> Worth noting because it suggests "signer context" deserves to be a
first-class concern in PSBT design broadly.
Yes, that's something I noticed in another project as well. A more generic
approach to "signer context" would definitely be a useful endeavor.
Thanks for the links, I'll take a look when I find some time.
Oli
On Monday, April 20, 2026 at 4:50:15 PM UTC+2 Thomas Suau wrote:
> ------------------------------
>
> 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
>
> Le lundi 20 avril 2026 à 09:26:14 UTC+2, Oliver a écrit :
>
>> 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/6dc35b8a-e837-4fc9-9a17-ca29204bf738n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10872 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-04-21 11:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-04-20 7:22 [bitcoindev] BIP-322: Add type prefix, change PoF serialization, PSBT-based signing Oliver
2026-04-20 14:47 ` [bitcoindev] " Thomas Suau
2026-04-21 9:16 ` Oliver
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox