From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 20 Apr 2026 00:26:21 -0700 Received: from mail-oi1-f184.google.com ([209.85.167.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wEj1Q-0008Mq-Lj for bitcoindev@gnusha.org; Mon, 20 Apr 2026 00:26:21 -0700 Received: by mail-oi1-f184.google.com with SMTP id 5614622812f47-4793e70895csf3422404b6e.2 for ; Mon, 20 Apr 2026 00:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776669974; x=1777274774; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=lVcdrQuTF0HiFhJAGNd/VmcnGKOAA5mpFxxCXDYATUQ=; b=YMY7V+9okYucnXulxzSCaXRjLOItX84dSLqOxUJYYQQndwzNY9FqW6ONJT7xty447/ CDGLrH/TX5wOHivAr349i6+7FrgvT0b3Ka6igGijKSggCAhzbl18muECogwuAg8y8HHq E6uRltryPCM3jhu9IxN5ArxvwxqNI1ui6JgW3KQQebpOYhAlNoA70+fHeyOKma8oCPLz WwI1LMC9P5zwRYXijkA1BG4OVzd19HK5aF7EzkJ1O+r71x2amRFvCut59f//y6QNCBdd oBbVNnA8p/Imfj2t20YEeYIXlXJ5GYmyQ6/k0YSejGK9z5Ic4wIOEin4z9id+lILs0aH f+Cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776669974; x=1777274774; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=lVcdrQuTF0HiFhJAGNd/VmcnGKOAA5mpFxxCXDYATUQ=; b=H3EIdltP5tQshbw7G29pGeB0geaiAyr3Wpd4TmoOrHJ2nFTjA8AZ2NHo8r8D5yjnLV lVHD42bYy7sZDaprM7y39OYdB60KXLJGSTgnWjdzfkbcsiuTczMZvx5D+DqAsIr64/3n MOGF/y28h4bQKuzsj+3K+55T+J6LL7yPCpiZcM1FPxNKUrdFYxRtTHMZIBMgUN7uBv1i 4DXt5HYN9Xz/l0+dHVRJk2o3d0Oup+C0XVlq8JePPnCq27yHFJNNLJzMtmjNrT6nuK0C Ae8BFzVjF3aA1hEbeHFLmc0uTrPDMktFf004AA473LvQKsEZHLb1bKAw7tw4jsWaodGy TjBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776669974; x=1777274774; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=lVcdrQuTF0HiFhJAGNd/VmcnGKOAA5mpFxxCXDYATUQ=; b=bvrw/BtPh36ehzQbj6fHqlNJIDOcfi/0sjfxBKC14kkUhrqt3eEyo0JHivAjT6t7NU uhePRnZ6n+oJTVYro68VLyYUSY9p3J5n90T2K3Sfq3L1PtWup9McpEuelya/PFYJMnug py+FgJteJCU0l8Cm1Yd0dAT0JWTmrqrgXICYnOLwGnoPlOsu9a7iuD/yps2kFnaejXOh gEhndt9GgovRvdDN0s8bydIDN5uzE4mk4+PB3AsLzTgCDD/u6nUwKvmyrc3BJr88jFJ4 rCc2mwlFJdyCxHlbyTs2JP6p/X4Dp1f2r406WztPyJkc8X+73VQ9Xm9gOroHwoEQ5yGI jZIg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ+WeBPFe7tsImSK4yXQ9kXppE010q87WWBAB+vhJRPjQANbEZXGecHY2Xu6jzVk99ByJAq8EtUIgnrC@gnusha.org X-Gm-Message-State: AOJu0Yy63YFuwiYGhziwdIxvwhwjXT5RxvX/w8mVhjjSo7ajG6T9ENBR X+7V0T/GVPxXPczqddehZWbmM/n4niDn6Kb4wQoGlAlJBApgID5zytQP X-Received: by 2002:a05:6808:23c6:b0:467:15dc:b329 with SMTP id 5614622812f47-4799c8f1157mr8114261b6e.12.1776669974037; Mon, 20 Apr 2026 00:26:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJEM2vcb7FdV8F82H11e5Nyq8IZKqQhWGEQD8EP3NkXlQ==" Received: by 2002:a05:6870:204d:b0:42c:d87:fc11 with SMTP id 586e51a60fabf-42c0d8839d7ls152657fac.1.-pod-prod-03-us; Mon, 20 Apr 2026 00:26:09 -0700 (PDT) X-Received: by 2002:a05:6808:220f:b0:472:cd4c:c36f with SMTP id 5614622812f47-4799c873bb6mr6336585b6e.3.1776669969069; Mon, 20 Apr 2026 00:26:09 -0700 (PDT) Received: by 2002:a05:690c:3687:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7baf5aa5779ms7b3; Mon, 20 Apr 2026 00:22:11 -0700 (PDT) X-Received: by 2002:a05:690c:c4f9:b0:7b2:1bf1:801b with SMTP id 00721157ae682-7b9ece7a516mr127555067b3.5.1776669730716; Mon, 20 Apr 2026 00:22:10 -0700 (PDT) Date: Mon, 20 Apr 2026 00:22:10 -0700 (PDT) From: Oliver To: Bitcoin Development Mailing List Message-Id: <2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an@googlegroups.com> Subject: [bitcoindev] BIP-322: Add type prefix, change PoF serialization, PSBT-based signing MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_687738_289190050.1776669730266" 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_687738_289190050.1776669730266 Content-Type: multipart/alternative; boundary="----=_Part_687739_1115113426.1776669730266" ------=_Part_687739_1115113426.1776669730266 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_687739_1115113426.1776669730266 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear mailing list

I've started an implementation of BIP-322 in G= o ([1]), and during implementation I noticed
that a number of open que= stions remain.

I believe that these open questions and the "Draf= t" status are contributing reasons for the
BIP not being widely implem= ented.
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:
=C2=A0- Introduce a human-readable prefix to distinguish the three signat= ure variants.
=C2=A0- Change the encoding format of the "Proof of Fund= s" variant to include UTXO information.
=C2=A0- Introduce a new PSBT f= ield for for PSBT-based message signing.

Let me explain the deta= ils and reasoning behind the changes:


Human-readable prefi= x
------

As in an earlier discussion ([3]), not having a pr= efix and needing to attempt decoding both
initially proposed formats t= o detect which one a signature used is cumbersome, potentially
error p= rone and requires careful implementation.
Introducing a simple fixed-l= ength (for easy detection and parsing) human-readable prefix that
is s= imply prepended to the base64-encoded signature should make detection quite= straightforward
in code and also make it easy to distinguish a BIP-32= 2 signature from a legacy one.
The proposed prefixes are: `smp`, `ful`= , `pof` for the 'simple', 'full' and 'Proof of Funds'
variants respect= ively.
Because there already are implementations of BIP-322 out there,= I also added a backward
compatibility clause for existing implementat= ions. 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., completenes= s 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 wit= ness of a BIP-322 `to_sign` transaction is valid, should be part of the spe= cification.
However, validating the witness of an additional input req= uires its UTXO information.
Instead of coming up with a custom encodin= g for the UTXO information in addition to the
full `to_sign` transacti= on, 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 o= r script information.
Therefore, I propose that the encoding format fo= r the "Proof of Funds" variant should be the
full, base64-encoded PSBT= of the `to_sign` transaction, but in the "finalized" state as
describ= ed in BIP-174.
Because non-witness inputs require the whole previous t= ransaction to be present, I also added
a size optimization that allows= this field to be reused between inputs if more than one input
referen= ces 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 sign= ature for the `to_sign` transaction from each signer.
However, althoug= h a signer produces a signature for a _transaction_, their intent is to sig= n
a _message_. Signing software and devices should be able to show tha= t 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 i= nto an OP_RETURN output).
I propose to add a new field (PSBT_IN_GENERI= C_SIGNED_MESSAGE, 0x21) to the first input of
the PSBT-wrapped `to_sig= n` 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 pr= oducing procedure is also explained in detail in my proposed
BIP body.=


The above changes are the most notable changes, but my Pu= ll Request to the BIP ([2]) also
addresses additional discussion point= s raised in Bitcoin Core 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 body
=C2=A0 =C2=A0[2] contains links to the relev= ant discussions).
=C2=A0- Add extensive test vectors for all the varia= nts.
=C2=A0- Propose the status to move to "Complete".
=C2=A0- Of= fer 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 B= IPs PR ([2]).

Oli


[1]: https://github.com/btcsu= ite/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 &= 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/2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an%40googlegroups.com.
------=_Part_687739_1115113426.1776669730266-- ------=_Part_687738_289190050.1776669730266--