From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 21 Apr 2026 04:45:19 -0700 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wF9Xa-0006ru-EJ for bitcoindev@gnusha.org; Tue, 21 Apr 2026 04:45:19 -0700 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7dbc09d4e43sf8933769a34.1 for ; Tue, 21 Apr 2026 04:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776771912; x=1777376712; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=t/Jkl98IK9ecyRsAQUD1pJRVR9RQsrk0mJz4pzmmoaw=; b=eDilcispdQGbdILsjI+3ScTW35BthUpmdNuziu9ZROXsp+CsdyiBTKd/K685bpHN+H aZ39G8uoYHBPSamv7oh/8vaewUbY3Gzpko4qGCEDFCYBDfVxw+NG/GcaIMIC0yKp+rcH G7vXbGAagtRmdU/wH6WDZbHuhjISJGVR7V5lep8vrxV8BfqFk0JjJizjnyYShqYR4vzh e6IE6EmrdC/nfO8aiSEUoj+//AvTyBPhpkULG7sWGEFhTxV3g7o1+NVcr5gOnnU3/UvH /JHjAVQMFIWqWf1dLmTaaD9Ugd8Azkth4XQs/Lf4JKxtwh084KpVZ0zjnbHsp2svJ00v O5qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776771912; x=1777376712; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=t/Jkl98IK9ecyRsAQUD1pJRVR9RQsrk0mJz4pzmmoaw=; b=dUp+IA8Odz9mgK81uKvOWusgx7wNbC1ubV+R5JdPYEWEnjypqZimaZo76eeEp1+NLu 1Ncx4pqZDhFrdiU+vUnPPYIyDNDZjkEb3s/qbKCdU8USmK3V+6JLP8dPQRXtca4HHsQA SR8m/mQFbIp2IBoMItud69S6HnC5fdnIbBe/vxU3UQFaq8JhD/5xGgQcIe9f7ygqpoDz vuQ+mT/i1JAYCF9VwI5KbvjKRu7nOHtGAJcTXOwOvfnRi7Okqhh8BpMANCY/WHP5xdYB DipmF+LvZ/Idda0tkzmkrwRAYzhf4APDP7131gQyg+ae0LHr3WheCE7qCnhhzypabRYa zewQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776771912; x=1777376712; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=t/Jkl98IK9ecyRsAQUD1pJRVR9RQsrk0mJz4pzmmoaw=; b=pVO+GIRn14bb6PF60ULLh8qMlsgZ7nASRb/o0f44r+ZKuoLACPCa/Pj8MGHl3LX458 HZkuToEe+7asP+WVJ8aslNoFd9k5QPZ1cuETJ6xWAOulVKQmTa5WXMQqmdgWO9Mhze4X 96KoPfh3HoiWlxnO13TSWzeogN1OYHzUZ3ws39SE2O8IZBeXYqK37TX+1U6EVUB1p0/g 3+BEBMPmIEYryVcTpOz4BZXl54bwHSQkuY3zVbqtauZSOvRqs6UQCDn7SqIfiegO435h aBpJfxU2VrmuKjULcThTY90pFh+QKihefz7xrbPE1SKB674MbcGS9UI236DItBTCOa8r S4BQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9g5J/QHaHKp551XJNbEqVDiFT4zr71Ih58pGE8Lra4Ts6Vr26ytJJTGgjb9U94ZetzRk7fa/Tml1Du@gnusha.org X-Gm-Message-State: AOJu0YxIyXLzGvkduPKtKum/RNJr8Zg7Z6IwVauVNyiY/OasQ+sHnwHC UavA6Hfq0DBb3t7H5lNDPEQD2kcUQKY7r7CK7CK4Xe9GU4fK0q/vyzbL X-Received: by 2002:a05:6820:4288:b0:694:857a:5a78 with SMTP id 006d021491bc7-694857a5ad6mr3367179eaf.8.1776771912202; Tue, 21 Apr 2026 04:45:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIAs9GRB8XdX4fpuUV08CyMEIEqhXrkUg/9JBN4axNVdw==" Received: by 2002:a05:6870:b4a1:b0:423:2560:d341 with SMTP id 586e51a60fabf-4280bece4a7ls2130621fac.0.-pod-prod-06-us; Tue, 21 Apr 2026 04:45:06 -0700 (PDT) X-Received: by 2002:a05:6808:1b20:b0:479:dc74:3696 with SMTP id 5614622812f47-479dc743c3emr2978828b6e.7.1776771906440; Tue, 21 Apr 2026 04:45:06 -0700 (PDT) Received: by 2002:a05:690c:3687:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7baf5aa5779ms7b3; Tue, 21 Apr 2026 02:16:07 -0700 (PDT) X-Received: by 2002:a05:690c:385:b0:79f:3715:1980 with SMTP id 00721157ae682-7b9ecefbddamr184081447b3.12.1776762964778; Tue, 21 Apr 2026 02:16:04 -0700 (PDT) Date: Tue, 21 Apr 2026 02:16:04 -0700 (PDT) From: Oliver To: Bitcoin Development Mailing List Message-Id: <6dc35b8a-e837-4fc9-9a17-ca29204bf738n@googlegroups.com> In-Reply-To: References: <2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an@googlegroups.com> Subject: [bitcoindev] Re: BIP-322: Add type prefix, change PoF serialization, PSBT-based signing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1386710_266236314.1776762964345" X-Original-Sender: gugger@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_1386710_266236314.1776762964345 Content-Type: multipart/alternative; boundary="----=_Part_1386711_2145812048.1776762964345" ------=_Part_1386711_2145812048.1776762964345 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 good question. I did ask myself the same thing and then slightly leaned toward adding it= =20 to the input that directly references the TXID that contains the message=20 hash. But I don't have strong opinions either way, so a global field would=20 definitely also work. > how does a parser that ingests PSBTs generically distinguish a BIP-322=20 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/518dc68dcd3d8793c66128638cc61f60c6007e= eb/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= =20 signed but the additional checks I propose also help to make sure it's a=20 well-formed and valid BIP-322 PSBT. > Worth noting because it suggests "signer context" deserves to be a=20 first-class concern in PSBT design broadly. Yes, that's something I noticed in another project as well. A more generic= =20 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=E2=80=AFPM 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 laye= r=20 > 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 propert= y=20 > of the whole `to_sign` transaction, not of input 0 specifically. Placing = it=20 > there works but creates an implicit convention that the first input carri= es=20 > 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=20 > generically distinguish a BIP-322 proof-of-funds from a regular transacti= on=20 > PSBT? Is 0x21 on the first input sufficient as discriminant, or does this= =20 > need an explicit marker? > > > The problem you identify =E2=80=94 signer sees a zero-value-to-OP_RETURN= =20 > transaction with no idea they're signing a message =E2=80=94 extends beyo= nd BIP-322=20 > to any multi-party PSBT workflow where the signer lacks semantic context.= =20 > I've been working on the same gap from a different angle with BTSL [1][2]= .=20 > Different mechanism, same problem. Worth noting because it suggests "sign= er=20 > context" deserves to be a first-class concern in PSBT design broadly. > > Cheers, > > Thomas > > [1] https://github.com/tsua0002/btsl-standard=20 > > [2] https://btsl-playground.vercel.app > > Le lundi 20 avril 2026 =C3=A0 09:26:14 UTC+2, Oliver a =C3=A9crit : > >> Dear mailing list >> >> I've started an implementation of BIP-322 in Go ([1]), and during=20 >> implementation I noticed >> that a number of open questions remain. >> >> I believe that these open questions and the "Draft" status are=20 >> contributing reasons for the >> BIP not being widely implemented. >> I do see demand for generic message signing in discussions and pull=20 >> 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= =20 >> variants. >> - Change the encoding format of the "Proof of Funds" variant to include= =20 >> 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=20 >> attempt decoding both >> initially proposed formats to detect which one a signature used is=20 >> cumbersome, potentially >> error prone and requires careful implementation. >> Introducing a simple fixed-length (for easy detection and parsing)=20 >> human-readable prefix that >> is simply prepended to the base64-encoded signature should make detectio= n=20 >> quite straightforward >> in code and also make it easy to distinguish a BIP-322 signature from a= =20 >> legacy one. >> The proposed prefixes are: `smp`, `ful`, `pof` for the 'simple', 'full'= =20 >> and 'Proof of Funds' >> variants respectively. >> Because there already are implementations of BIP-322 out there, I also= =20 >> added a backward >> compatibility clause for existing implementations. Observing that many o= f=20 >> the implementations >> I found and looked at only produce signatures of the 'simple' variant, a= n=20 >> 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= =20 >> UTXOs. While the >> selection and purpose of the UTXOs (e.g., completeness or unspent status= )=20 >> remain out of scope >> of the BIP, it is my opinion that it should at least be possible to=20 >> validate (offline) that >> the witness of a BIP-322 `to_sign` transaction is valid, should be part= =20 >> of the specification. >> However, validating the witness of an additional input requires its UTXO= =20 >> information. >> Instead of coming up with a custom encoding for the UTXO information in= =20 >> addition to the >> full `to_sign` transaction, I realized that a finalized PSBT contains=20 >> exactly the information >> we require: The full transaction, the witness and/or signature scripts= =20 >> and the (Non-)Witness >> UTXO fields. A finalized PSBT also must not contain fields that may be= =20 >> detrimental to privacy, >> like internal keys, xPubs or script information. >> Therefore, I propose that the encoding format for the "Proof of Funds"= =20 >> variant should be the >> full, base64-encoded PSBT of the `to_sign` transaction, but in the=20 >> "finalized" state as >> described in BIP-174. >> Because non-witness inputs require the whole previous transaction to be= =20 >> present, I also added >> a size optimization that allows this field to be reused between inputs i= f=20 >> 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= =20 >> 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_,=20 >> their intent is to sign >> a _message_. Signing software and devices should be able to show that=20 >> fact in their user >> interface, as a BIP-322 transaction would look unusual to a user when=20 >> 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= =20 >> the first input of >> the PSBT-wrapped `to_sign` transaction that contains the full message to= =20 >> be signed. A signing >> device or software can then detect and present such a message-signing=20 >> PSBT in an appropriate >> way to the user. >> The detection and signature producing procedure is also explained in=20 >> detail in my proposed >> BIP body. >> >> >> The above changes are the most notable changes, but my Pull Request to= =20 >> the BIP ([2]) also >> addresses additional discussion points raised in Bitcoin Core PRs and=20 >> previous mailing list >> discussions: >> - Clarify intent and terminology of the BIP, make it clear what it can'= t=20 >> 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 o= n=20 >> 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 >> > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 6dc35b8a-e837-4fc9-9a17-ca29204bf738n%40googlegroups.com. ------=_Part_1386711_2145812048.1776762964345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 h= ave strong opinions either way, so a global field would definitely also wor= k.

> how does a parser that ingests PSBTs gen= erically distinguish a BIP-322 proof-of-funds from a regular transaction PS= BT?

I did add a section that covers detection to= the BIP, see
https://github.com/bitcoin/bips/blob/518dc68dcd3d87= 93c66128638cc61f60c6007eeb/bip-0322.mediawiki#user-content-PSBT_signer

I made it as strict as possible to minimize the chan= ce 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 propos= e 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 app= roach 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=E2=80= =AFPM 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 lay= er for multi-party PSBT workflows) so the PSBT parts caught my attention.

On PSBT_IN_GENERIC_SIGNED_MESSAGE (0x21)

Why a per-input field r= ather than global? The signed message is a property of the whole `to_sign` = transaction, not of input 0 specifically. Placing it there works but create= s an implicit convention that the first input carries transaction-wide meta= data. 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 generic= ally 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 =E2=80=94 signer sees a zero-value-to-OP_RETURN= transaction with no idea they're signing a message =E2=80=94 extends b= eyond BIP-322 to any multi-party PSBT workflow where the signer lacks seman= tic context. I've been working on the same gap from a different angle w= ith BTSL [1][2]. Different mechanism, same problem. Worth noting because it= suggests "signer context" deserves to be a first-class concern i= n PSBT design broadly.

Cheers,

Thomas

[1] https://= github.com/tsua0002/btsl-standard=C2=A0

[2] https://btsl-playground.vercel.app


Le lundi 20 av= ril 2026 =C3=A0 09:26:14 UTC+2, Oliver a =C3=A9crit=C2=A0:
Dear mailing list

I've star= ted an implementation of BIP-322 in Go ([1]), and during implementation I n= oticed
that a number of open questions remain.

I believe that the= se open questions and the "Draft" status are contributing reasons= for the
BIP not being widely implemented.
I do see demand for generi= c message signing in discussions and pull requests, though, so I'm
t= aking a shot at helping to move the BIP forward ([2]).

In short, I&#= 39;m proposing three major changes:
=C2=A0- Introduce a human-readable p= refix to distinguish the three signature variants.
=C2=A0- Change the en= coding format of the "Proof of Funds" variant to include UTXO inf= ormation.
=C2=A0- 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 discus= sion ([3]), not having a prefix and needing to attempt decoding both
ini= tially proposed formats to detect which one a signature used is cumbersome,= potentially
error prone and requires careful implementation.
Introdu= cing a simple fixed-length (for easy detection and parsing) human-readable = prefix that
is simply prepended to the base64-encoded signature should m= ake detection quite straightforward
in code and also make it easy to dis= tinguish a BIP-322 signature from a legacy one.
The proposed prefixes ar= e: `smp`, `ful`, `pof` for the 'simple', 'full' and 'Pr= oof of Funds'
variants respectively.
Because there already are im= plementations of BIP-322 out there, I also added a backward
compatibilit= y clause for existing implementations. Observing that many of the implement= ations
I found and looked at only produce signatures of the 'simple&= #39; variant, an implementation may
assume the 'simple' format i= f it doesn't detect a valid prefix.


Encoding format of the &= quot;Proof of Funds" variant
------

The "Proof of Funds= " variant allows attesting spendability of specific UTXOs. While theselection 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 leas= t be possible to validate (offline) that
the witness of a BIP-322 `to_si= gn` 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 i= n addition to the
full `to_sign` transaction, I realized that a finalize= d 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" varia= nt should be the
full, base64-encoded PSBT of the `to_sign` transaction,= but in the "finalized" state as
described in BIP-174.
Beca= use non-witness inputs require the whole previous transaction to be present= , I also added
a size optimization that allows this field to be reused b= etween inputs if more than one input
references the same previous transa= ction.


New PSBT field for PSBT-based message signing
------
When creating a signature for a multisig address script, it makes sen= se to use a PSBT to get
a signature for the `to_sign` transaction from e= ach signer.
However, although a signer produces a signature for a _trans= action_, their intent is to sign
a _message_. Signing software and devic= es should be able to show that fact in their user
interface, as a BIP-32= 2 transaction would look unusual to a user when presented as such
(spend= ing a zero-value output into an OP_RETURN output).
I propose to add a ne= w 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 si= gned. A signing
device or software can then detect and present such a me= ssage-signing PSBT in an appropriate
way to the user.
The detection a= nd signature producing procedure is also explained in detail in my proposed=
BIP body.


The above changes are the most notable changes, bu= t my Pull Request to the BIP ([2]) also
addresses additional discussion = points raised in Bitcoin Core PRs and previous mailing list
discussions:=
=C2=A0- Clarify intent and terminology of the BIP, make it clear what i= t can't prove (the PR body
=C2=A0 =C2=A0[2] contains links to the re= levant discussions).
=C2=A0- Add extensive test vectors for all the vari= ants.
=C2=A0- Propose the status to move to "Complete".
=C2= =A0- 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 o= n the BIPs PR ([2]).

Oli


[1]: https://github.com/btcsuite/btcd/pull/252= 1
[2]: ht= tps://github.com/bitcoin/bips/pull/2141
[3]: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/NsFQcCc= aCAAJ

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6dc35b8a-e837-4fc9-9a17-ca29204bf738n%40googlegroups.com.
------=_Part_1386711_2145812048.1776762964345-- ------=_Part_1386710_266236314.1776762964345--