------------------------------

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.