From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 20 Apr 2026 07:50:22 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wEpx7-0005Zj-PH for bitcoindev@gnusha.org; Mon, 20 Apr 2026 07:50:22 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-40eee5d10c5sf4743124fac.0 for ; Mon, 20 Apr 2026 07:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776696615; x=1777301415; 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=DG341vLuEPhMdvHSL2Y/LEC/CqDeNoZOrqaPID9qONs=; b=KRGio2n3RY23oM+LomO6HoDJhbqvM+BdJEBMIxHvy8hApldLlM07sy8Gs7QyP99Ufd dER0w1cbTKOmY6zAwB5ppJ9FOIgDdwOSKuKUcBh4bRM0tpExcJ4zoiP+RDhsPHruQfos +LfOaZUFIWVkPfqwKAgOB1f2krSm4GpVwgS2go9K6bhM3yj6nF97VBIfNO4nN24ZxUbv R2ciLvGxK6GmUmgvNdZrnj8WnncBIfdIPmpnLILyBI9IVKFKYw63pVXefnnB9I+C2bha zzuEyKx/hoKlm1W0E+2AMyySqNaCbGhc2r51HLMw+ZWZytYPT3DGV4mWPMzsk3Zd2H2z 3MpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776696615; x=1777301415; 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=DG341vLuEPhMdvHSL2Y/LEC/CqDeNoZOrqaPID9qONs=; b=T+mLmJBREwVlJD8vkHeaaNz5t+nqpGfP5XRKFslAnm8LqaZx7zzTz6kqFkn1GwjJzO G+Mwe3PnR7GsM9QWfYojAyPu8iDN0G4zP5e0FoR3kkQmmNuPuAS1lqjV6v/3gNBKYWqY eOb4bn9DunYanZ3QcSr6hAzHpDXXkbyfDzBqQhwf3TEaDUYOrt+hsfz1Fqk2kUrUCJ8N o80QKlupyY7ATqn/J5EXQXWaNZKKjDr93stAFZLwW9UyzgYjOAHLjNhkNGiXze7mSFXO YYdwBfUvkkTarMzkvwodyqdNt5Tk+LejHYK1HHDTmkoaYYfD4QkCsvj5BbUESpVln6O0 cgXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776696615; x=1777301415; 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=DG341vLuEPhMdvHSL2Y/LEC/CqDeNoZOrqaPID9qONs=; b=fS8A9GB8yVLkEZutyB97jGYlmEEWIXR1uBTv+mWPy/+nl7Y9SluQ5PxGwCuDeaxYlV SahZdpTZcvZMi6CC05J9uNLgVRzlI6TPxsmN8oN29jBaBU0r31EmzQtGYe9zHWtv7pym oBe6+mdUOP1a/Fs2/ProH1GyIPbHoCmMDrVMqx2F2aNQHXvowHM+igKmtLgJ34ZjI/1I 4i0k3jhte48fCPzTkoJmBhhEMhRHTK9z/F4sdC5JYMr2ROdNN18pyAXrIexl0wrEtt5D JL4tF9gIdN8yBG4ESef/BGAWsRY4R6x4AJI6OBpZ25VmCn7aEbb7OrZNSC8mKkqN+mWn R8HA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/6YVVqLr/V+9HsHFtM5HTPfvb3YabGiY0H30rCcxSgC7z3sOmk1Ll4qVDyCVp7Y2GlW/outswU9ZmW@gnusha.org X-Gm-Message-State: AOJu0YxOrCJGf9RiiibryYXb9igW/KaoLnzf9vroJoWHsJSX8FVw2BNs ESlpyBxjrfnTCAPgQSqbGCL02A3ChF0efMvQJUHv7c9itdGzjyLH1cxl X-Received: by 2002:a05:6820:220a:b0:692:65c1:f900 with SMTP id 006d021491bc7-69462eb9901mr7829509eaf.32.1776696614113; Mon, 20 Apr 2026 07:50:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiI0X8AZkbyhHIt/Cf1YmYlj2KIJqiVd8TDrWwh5T4sZ2g==" Received: by 2002:a05:6871:14c:b0:41c:64c3:46be with SMTP id 586e51a60fabf-4280c4cdcd4ls2494366fac.1.-pod-prod-07-us; Mon, 20 Apr 2026 07:50:08 -0700 (PDT) X-Received: by 2002:a05:6808:221c:b0:45c:9384:3626 with SMTP id 5614622812f47-4799cb465aemr7036716b6e.47.1776696608696; Mon, 20 Apr 2026 07:50:08 -0700 (PDT) Received: by 2002:a05:690c:3687:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7baf5aa5779ms7b3; Mon, 20 Apr 2026 07:47:12 -0700 (PDT) X-Received: by 2002:a05:690c:60c1:b0:7a1:c90b:2dd3 with SMTP id 00721157ae682-7b9ed002da8mr153199167b3.43.1776696431220; Mon, 20 Apr 2026 07:47:11 -0700 (PDT) Date: Mon, 20 Apr 2026 07:47:10 -0700 (PDT) From: Thomas Suau To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an@googlegroups.com> 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_49500_1170885671.1776696430575" X-Original-Sender: tomeclair@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_49500_1170885671.1776696430575 Content-Type: multipart/alternative; boundary="----=_Part_49501_1898819139.1776696430575" ------=_Part_49501_1898819139.1776696430575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ------------------------------ 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= =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 property= =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 carries= =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 transaction= =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 beyond= 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 "signer= =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 detection= =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 of= =20 > the implementations > I found and looked at only produce signatures of the 'simple' variant, an= =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 o= f=20 > 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 an= d=20 > 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 if= =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 t= o=20 > 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_, thei= r=20 > intent is to sign > a _message_. Signing software and devices should be able to show that fac= t=20 > 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 th= e=20 > 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 PSB= T=20 > 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 th= e=20 > 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 on= =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/= fa1ca8ae-385a-4f16-85c2-544f8667b00en%40googlegroups.com. ------=_Part_49501_1898819139.1776696430575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 beyon= d 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 suggest= s "signer context" deserves to be a first-class concern in PSBT design broa= dly.

Cheers,

Thomas

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

[2] https://bt= sl-playground.vercel.app


Le lundi 20 avril 2026 =C3=A0 09:26:14 UTC+2, Oliv= er a =C3=A9crit=C2=A0:
Dear mailing list

I've started an implementation of BI= P-322 in Go ([1]), and during implementation I noticed
that a number of = open questions remain.

I believe that these open questions and the &= quot;Draft" status are contributing reasons for the
BIP not being w= idely implemented.
I do see demand for generic message signing in discus= sions 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:
=C2=A0- Introduce a human-readable prefix to distinguish the th= ree signature variants.
=C2=A0- Change the encoding format of the "= Proof of Funds" variant to include UTXO information.
=C2=A0- Introd= uce a new PSBT field for for PSBT-based message signing.

Let me expl= ain the details and reasoning behind the changes:


Human-readable= prefix
------

As in an earlier discussion ([3]), not having a pr= efix 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 pr= epended to the base64-encoded signature should make detection quite straigh= tforward
in code and also make it easy to distinguish a BIP-322 signatur= e from a legacy one.
The proposed prefixes are: `smp`, `ful`, `pof` for = the 'simple', 'full' and 'Proof of Funds'
varian= ts respectively.
Because there already are implementations of BIP-322 ou= t there, I also added a backward
compatibility clause for existing imple= mentations. Observing that many of the implementations
I found and looke= d at only produce signatures of the 'simple' variant, an implementa= tion may
assume the 'simple' format if it doesn't detect a v= alid prefix.


Encoding format of the "Proof of Funds" v= ariant
------

The "Proof of Funds" variant allows attes= ting 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, s= hould be part of the specification.
However, validating the witness of a= n additional input requires its UTXO information.
Instead of coming up w= ith 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 signat= ure scripts and the (Non-)Witness
UTXO fields. A finalized PSBT also mus= t not contain fields that may be detrimental to privacy,
like internal k= eys, xPubs or script information.
Therefore, I propose that the encoding= format for the "Proof of Funds" variant should be the
full, b= ase64-encoded PSBT of the `to_sign` transaction, but in the "finalized= " state as
described in BIP-174.
Because non-witness inputs requ= ire the whole previous transaction to be present, I also added
a size op= timization 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 signa= ture 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, alt= hough a signer produces a signature for a _transaction_, their intent is to= sign
a _message_. Signing software and devices should be able to show t= hat fact in their user
interface, as a BIP-322 transaction would look un= usual to a user when presented as such
(spending a zero-value output int= o an OP_RETURN output).
I propose to add a new field (PSBT_IN_GENERIC_SI= GNED_MESSAGE, 0x21) to the first input of
the PSBT-wrapped `to_sign` tra= nsaction that contains the full message to be signed. A signing
device o= r software can then detect and present such a message-signing PSBT in an ap= propriate
way to the user.
The detection and signature producing proc= edure is also explained in detail in my proposed
BIP body.


Th= e above changes are the most notable changes, but my Pull Request to the BI= P ([2]) also
addresses additional discussion points raised in Bitcoin Co= re PRs and previous mailing list
discussions:
=C2=A0- Clarify intent = and terminology of the BIP, make it clear what it can't prove (the PR b= ody
=C2=A0 =C2=A0[2] contains links to the relevant discussions).
=C2= =A0- Add extensive test vectors for all the variants.
=C2=A0- Propose th= e status to move to "Complete".
=C2=A0- Offer myself to be a d= eputy to BIP-322 as described in BIP-3.

I'm looking forward to y= our 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/bi= ps/pull/2141
[3]: https://groups= .google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/NsFQcCcaCAAJ
<= /div>

--
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/fa1ca8ae-385a-4f16-85c2-544f8667b00en%40googlegroups.com.
------=_Part_49501_1898819139.1776696430575-- ------=_Part_49500_1170885671.1776696430575--