From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Apr 2026 13:47:12 -0700 Received: from mail-qv1-f62.google.com ([209.85.219.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 1wHpKp-00015G-2g for bitcoindev@gnusha.org; Tue, 28 Apr 2026 13:47:12 -0700 Received: by mail-qv1-f62.google.com with SMTP id 6a1803df08f44-8954803bd74sf109986996d6.0 for ; Tue, 28 Apr 2026 13:47:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1777409225; cv=pass; d=google.com; s=arc-20240605; b=DCGX5K8XyJvKrMg41VBeibCYcwRJRYG2cGahEaTpNNP7rQ06bB+jLDySdrcKuZFCEd pcSSHsjNezTH6Uy1j7Ok8huOV30Shelrpu91QwNh533RNwCsRfOegY72tkLTQxQ0+qG8 JWbb7jSz6ev+zip3b043iTbWnZvAY1LTi5B8FYl09zyk9QjW08vnAXPuh1oBUD4hWfxp pwgl964qiWCklA0jHKl4GaJV79CB0Cs1F7v2Wwz1Ljy027xWFmWzKatms5oYD+jesAk4 gQSOwxwdRUBDoMGdXxsXI1clC23ZsZ1spv/SE4kPX0WVMcipATj9VMo03xg5cJ9yU/Gl QlEQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:references:to:cc:in-reply-to:date :subject:mime-version:message-id:from:sender:dkim-signature :dkim-signature; bh=m6RLpr6/vkG7pqI4ftdY8uWMYmWpZ0QVffSfVa9vIi0=; fh=LPXvPOOKciHWtF1i+aV84N9ceMYqQWL3Pnor/h9/ybs=; b=NXD9TCYBbz6nRHUnUAVg5m3JR526NEZmL41mo5iKFThjrI5TdUETjjaRZLFeA4BI6a zGGJJefDvAJT7fao84c8pRw2vN26CuTNNSVXfva0B2Ljmdf4zxKChmKkTMieIZhvvIiO tyUckQyW/aLwcEXhTbHlci5/WZCxm9zUxXjgmJHjQxDAlfpJHRVeRSxHVt0jTcspX0Er 4tZgaO629m4+LsBNLtZIPUCxokRvTKygy+BP0hd/VJDNuMS9BxbQ3hMZ36ysevNAPa2w AX+nLrl4VcpfXeKqDYKWCFvVSKdQ5Z53IcUzIuXC+sJuiZdFwyzTTC2y7vv1OT8dgoa9 rEzg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=cZ5gMDEg; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777409225; x=1778014025; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:references:to:cc:in-reply-to:date:subject :mime-version:message-id:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=m6RLpr6/vkG7pqI4ftdY8uWMYmWpZ0QVffSfVa9vIi0=; b=O1MIfA2+7CYbxOJEVUY6O6WWjsRhaH2I3LrPNwKrZMeHNBf8phGCqC8WfjAEJlLgG3 KUMboMvNQPIpKwya3xRlCW547BYqPTUR+hYm5hRszd8IkZVK3/WXCdztAGpG9//VgLzL SZUaS+U54aU9xRA1/Yfo6akUfCsfNtJbSlj0A+eO3ADx/9Umnk/M4BVFoqP8BmcnKF9b +iLQ+lE1WxADUIw10v8DkOi1G1lKdAqP7jkepvizZ7yz0ETEOoxhL26VFTAvOgpvlz9U mBFStj8ucThyLlGZfDe+AagJlw1hjZ1yYQl/oVuWc3timkYLOXWGbz/jpDpAIEDm5frJ o9BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777409225; x=1778014025; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:references:to:cc:in-reply-to:date:subject :mime-version:message-id:from:from:to:cc:subject:date:message-id :reply-to; bh=m6RLpr6/vkG7pqI4ftdY8uWMYmWpZ0QVffSfVa9vIi0=; b=bzkOlw7Cm9+07DecxexHdBE2oJMDfnkxLwbVXias0Rj52ChtnnOItf/Pa7rLzZ0jaV sMMGR72tr6QeAUaSV8kST3o0pJiTb2l9XVWfdjk25rC91KDwvNSQ40zQQjA+KDc1yHUv V6brZwzMkNFyb2s9DZN26nEMQn6E6py5Y+Cb0Z0Mholjaa4rmFgACdWhdOHPbSl/HQZ4 +JGCUbOvfLSvGaBzTP1VNWAWKDN1G2/cMwtiJOjfeHhnsVggVCYiWKDY5+T20oL71HZF OjDZwcZ1vp8YmEnCYF2Zr2BSFbo3U6qEA8/UmQLiMeO5MQCxLhNmak5qaQsb9Vs1ddm9 wshA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777409225; x=1778014025; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:references:to:cc:in-reply-to:date:subject :mime-version:message-id:from:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=m6RLpr6/vkG7pqI4ftdY8uWMYmWpZ0QVffSfVa9vIi0=; b=OEaYFLyTYTYKUbtc/KTWmcK1zVSecsdHqNrICQxabz59JbpBuRoab9VRAZGdUUKmkG HFc/FzTSKe1ryMhb6/9X+WML2IKUCetfPzivVmLAVod1JNXaHNCUw13r3PuYckihYadC PA+ak7/EULmlKhkpa9yLQsQa8KhDTO1f/+1MLrEFL8vphK46pSdG2UxDH4cGhnQ0KxZR voKGfeVrXZyNFIOS+ulyV33sQ2Tlm2/ajLjcagyAMdS+6RixWpmZoeFsgcZBP7Azif02 +X+5xL2q5QIWkgMpZ087dWXEDLh/AEaHkq+iGb0Lqyj6Eso68Sow1e8AMB50st/CHUMw zpWw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/+Cj9uwL9ta7dhPY7N/DIEsWCIMXaevxJgU2KD7ooZOOE3807ozBzp7MjQarfyGJjQ8DzzhDWBjdSD@gnusha.org X-Gm-Message-State: AOJu0YyUpJ6TMctx+VsQhPzZvBGivIV91YMGWQIs4fdr4Ya7Jods8Z6V Skp9vCzyCotPRdaPe2t210qe8N9F3+xE6sXZ41Ev/Pw8Owq+YpiTnrGe X-Received: by 2002:a05:6214:4e8f:b0:89c:d426:3cc9 with SMTP id 6a1803df08f44-8b3eddc3924mr17604186d6.35.1777409224627; Tue, 28 Apr 2026 13:47:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOqbTKevfxHZGBEEwlf8DBYJnDsgxHVH0MQ1X+zHcqHNw==" Received: by 2002:ac8:7d86:0:b0:50d:9c5a:dfd2 with SMTP id d75a77b69052e-50fb18350fals152526551cf.1.-pod-prod-08-us; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) X-Received: by 2002:a05:620a:2988:b0:8ed:847d:dea5 with SMTP id af79cd13be357-8f8f599b24bmr197677685a.37.1777409217487; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) Received: by 2002:a05:6402:3094:b0:672:bd1b:222f with SMTP id 4fb4d7f45d1cf-672c169bb1cmsa12; Tue, 21 Apr 2026 06:14:09 -0700 (PDT) X-Received: by 2002:a05:6402:c4e:b0:674:1f6e:3485 with SMTP id 4fb4d7f45d1cf-6741f6e3625mr6881042a12.27.1776777248105; Tue, 21 Apr 2026 06:14:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776777248; cv=none; d=google.com; s=arc-20240605; b=UpAkYcLWCNQsnSglWUv85Y5kMMaMGl7qNUPwDsSyVpswlflDn+n19J/tfbOaQOCW+H 7RZ3kynEW8Bgk6288qwUHoIgI7lXqzECMHYTr561UIl4/Jhshtx6mri5/CvFneJip+2s S8WkEHMKxkoPa9JLTsqWKKRce0ANkq31jLLYGP55NMIq/pjozT56ZxM4sPpXiy17HQZ8 kLYtbrIc0GmJqQnfy9vzetE7QrIVcvqfE4DUUhKB85ydhHgTjafxK5bZ6efiTopsSPI0 apUIBnZ72qnc7E/3sqMWt7ag8Do/J7clTtRHxaFbctSQgeF+2Pri6dlfQSDcGhOj50Mz TuOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:dkim-signature; bh=QBUdxACmK8ZiCjRiHcMSqYjPJMm4zgVGe2tCApMQp+0=; fh=93oZ55VFwNtW47W1Ev0uqvlCeExntCBK8PKr2laFIX8=; b=HDXL70orxctKReh87m7DKZsCc0kxDVbGD+83zo//iQyAGCA59abgIqGymoNSrU+J/G tD7TsO8WVsyfzCWS46M3o99tDoKvHqP9uOCxMmGy5iGoArjq5Cvn113qsMIRMl50Drgl FLncl8mEtOb8gWwNtJbfPW+wNv3LQGbce+pDuUWPKekgmu+voHs25KCDjpGg7TaAADrt PTOgCVJgsxCYLiiIHqgJhj0X63hmAZjZmBrcwkGAndpAqeFC5ILe471dXUjL2pIlBP6n WWKNVs3HrAwT6mS9mhg0PQzFbfNJBWe9jGB87SDxZe4lD8DEQ0sWjTmqilueIUGpaGhU mJTw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=cZ5gMDEg; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com. [2a00:1450:4864:20::32e]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-672c482821dsi251090a12.1.2026.04.21.06.14.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Apr 2026 06:14:08 -0700 (PDT) Received-SPF: pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) client-ip=2a00:1450:4864:20::32e; Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-483487335c2so43119825e9.2 for ; Tue, 21 Apr 2026 06:14:08 -0700 (PDT) X-Gm-Gg: AeBDievNpy0wm9fFWrAKf3PzzbFJ4nJP/j/LXb7F1ejnvWZIWEzOXbl5ULbUXDb8PU+ gToV0Hes9Gxg93LqvvIBV9TwPcAvXGjrfIcXnT7SuUd61gPzLDbFnsC+iFbqVF6xmONLccqIXs2 NrKgdmlzZ79aHvvdV3Zm5916VZsUvhWDYguxTrdRPXmcOwelFPW2chlrnIgvokC/ebMkzJWO827 YY5F+iX3Sq0O+qZn5AZK+VMi+kIiacJQae0Wm5DGPBrHWWGIdZhjcKhNW1sgLBX5WS6Lvzyo4Cn YgbK904ImGbtHs8VToYocXjxUUw4dPxn9E7NZGemmnnoPj8gqVh9J2I2m+DFTr8lZYgciw6dL2W IEE6YhxSSLhlwS1tcSahzE0Y05TACgD0iyGWkzVs480IBbvekas0liJgK+Hp+ol5kMUjidznh3s LS91UwOKgoFH4ADA+WfUlQq3omm8+VACranSDEUFogU+xSYzFyON7N7VxGUFDwvnlmBGxCARuiI A== X-Received: by 2002:a05:600d:b:b0:48a:56de:d63c with SMTP id 5b1f17b1804b1-48a56dedadfmr21553295e9.27.1776777247086; Tue, 21 Apr 2026 06:14:07 -0700 (PDT) Received: from smtpclient.apple ([2a01:e0a:2f0:5440:3992:9854:9ff0:9ac9]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fb767961sm111224935e9.16.2026.04.21.06.14.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2026 06:14:06 -0700 (PDT) From: "thomas s." Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2D488F5B-C204-4C0C-A6F8-7165A64E2052" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: [bitcoindev] BIP-322: Add type prefix, change PoF serialization, PSBT-based signing Date: Tue, 21 Apr 2026 15:13:55 +0200 In-Reply-To: <6dc35b8a-e837-4fc9-9a17-ca29204bf738n@googlegroups.com> Cc: Bitcoin Development Mailing List To: Oliver References: <2d8243b4-6c89-4d9a-b7d5-86cfc9ff875an@googlegroups.com> <6dc35b8a-e837-4fc9-9a17-ca29204bf738n@googlegroups.com> X-Mailer: Apple Mail (2.3864.400.21) X-Original-Sender: tomeclair@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=cZ5gMDEg; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --Apple-Mail=_2D488F5B-C204-4C0C-A6F8-7165A64E2052 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Oli, Thanks for the detailedd reply and for the detection section =E2=80=94 the = five checks are solid, especially the cryptographic binding via to_spend.tx= id in in check 4. On the per-input vs global question: since you're open to either, I'd argue= for a global field (PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE). The message text isn't data required to satisfy input 0's script =E2=80=94 = it's semantic context about what the whole transaction represents. That map= s cleanly to the global/per-input split in BIP-174: global fields carry tra= nsaction-wide metadata, per-input fields carry what's needed to sign that s= pecific input. Putting it on input 0 works mechanically but sets a precedent where transac= tion-level metadata lives on an arbitrary input by convention. A global fie= ld avoids that and keeps the detection logic just as simple =E2=80=94 check= 1 moves from input-level to global-level, everything else stays the same. Thomas > On 21 Apr 2026, at 11:16, Oliver wrote: >=20 > Hi Thomas >=20 > Thank you for your feedback and questions! >=20 > 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 h= ash. > But I don't have strong opinions either way, so a global field would defi= nitely also work. >=20 > > how does a parser that ingests PSBTs generically distinguish a BIP-322 = proof-of-funds from a regular transaction PSBT? >=20 > I did add a section that covers detection to the BIP, see > https://github.com/bitcoin/bips/blob/518dc68dcd3d8793c66128638cc61f60c600= 7eeb/bip-0322.mediawiki#user-content-PSBT_signer >=20 > I made it as strict as possible to minimize the chance of a false positiv= e. > The 0x21 field is a good indication that the PSBT contains a message to b= e signed but the additional checks I propose also help to make sure it's a = well-formed and valid BIP-322 PSBT. >=20 > > Worth noting because it suggests "signer context" deserves to be a firs= t-class concern in PSBT design broadly. >=20 > Yes, that's something I noticed in another project as well. A more generi= c approach to "signer context" would definitely be a useful endeavor. > Thanks for the links, I'll take a look when I find some time. >=20 > Oli >=20 > On Monday, April 20, 2026 at 4:50:15=E2=80=AFPM UTC+2 Thomas Suau wrote: >>=20 >> Hi Oli, >>=20 >> Concept ACK on the direction. Good to see this this moving forward. >>=20 >>=20 >> 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. >>=20 >> On PSBT_IN_GENERIC_SIGNED_MESSAGE (0x21) >>=20 >> Why a per-input field rather than global? The signed message is a proper= ty of the whole `to_sign` transaction, not of input 0 specifically. Placing= it there works but creates an implicit convention that the first input car= ries transaction-wide metadata. Was there a reason to avoid PSBT_GLOBAL_*? >>=20 >> On Proof of Funds as finalized PSBT >>=20 >> 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? >>=20 >>=20 >>=20 >> 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. >>=20 >> Cheers, >>=20 >> Thomas >>=20 >> [1] https://github.com/tsua0002/btsl-standard=20 >>=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 >>>=20 >>> I've started an implementation of BIP-322 in Go ([1]), and during imple= mentation I noticed >>> that a number of open questions remain. >>>=20 >>> I believe that these open questions and the "Draft" status are contribu= ting reasons for the >>> BIP not being widely implemented. >>> I do see demand for generic message signing in discussions and pull req= uests, though, so I'm >>> taking a shot at helping to move the BIP forward ([2]). >>>=20 >>> 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 includ= e UTXO information. >>> - Introduce a new PSBT field for for PSBT-based message signing. >>>=20 >>> Let me explain the details and reasoning behind the changes: >>>=20 >>>=20 >>> Human-readable prefix >>> ------ >>>=20 >>> As in an earlier discussion ([3]), not having a prefix and needing to a= ttempt decoding both >>> initially proposed formats to detect which one a signature used is cumb= ersome, potentially >>> error prone and requires careful implementation. >>> Introducing a simple fixed-length (for easy detection and parsing) huma= n-readable prefix that >>> is simply prepended to the base64-encoded signature should make detecti= on 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. >>>=20 >>>=20 >>> Encoding format of the "Proof of Funds" variant >>> ------ >>>=20 >>> The "Proof of Funds" variant allows attesting spendability of specific = UTXOs. While the >>> selection and purpose of the UTXOs (e.g., completeness or unspent statu= s) remain out of scope >>> of the BIP, it is my opinion that it should at least be possible to val= idate (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 UTX= O 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 e= xactly 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 "fin= alized" 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. >>>=20 >>>=20 >>> New PSBT field for PSBT-based message signing >>> ------ >>>=20 >>> 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_, th= eir intent is to sign >>> a _message_. Signing software and devices should be able to show that f= act in their user >>> interface, as a BIP-322 transaction would look unusual to a user when p= resented 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 t= o be signed. A signing >>> device or software can then detect and present such a message-signing P= SBT in an appropriate >>> way to the user. >>> The detection and signature producing procedure is also explained in de= tail in my proposed >>> BIP body. >>>=20 >>>=20 >>> 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 p= revious 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. >>>=20 >>> I'm looking forward to your feedback and to further discussion here or = on the BIPs PR ([2]). >>>=20 >>> Oli >>>=20 >>>=20 >>> [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/NsFQcCcaCAA= J >=20 >=20 > --=20 > You received this message because you are subscribed to a topic in the Go= ogle Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/b= itcoindev/qd6BNz9gxCk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com . > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/6dc35b8a-e837-4fc9-9a17-ca29204bf738n%40googlegroups.com . --=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/= E17F4A33-34AF-4E6C-AC15-69854AE8A08E%40gmail.com. --Apple-Mail=_2D488F5B-C204-4C0C-A6F8-7165A64E2052 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

Hi Oli,

Thanks for the detailedd reply and for the detection = section =E2=80=94 the five checks are solid, especially the cryptographic b= inding via to_spend.txid in in check 4.

On the per-in= put vs global question: since you're open to either, I'd argue for a global= field (The message text i= sn't data required to satisfy input 0's script =E2=80=94 it's semantic cont= ext about what the whole transaction represents. That maps cleanly to the g= lobal/per-input split in BIP-174: global fields carry transaction-wide meta= data, per-input fields carry what's needed to sign that specific input.

=

Putting it on input 0 works mechanically but sets a precedent where= transaction-level metadata lives on an arbitrary input by convention. A gl= obal field avoids that and keeps the detection logic just as simple =E2=80= =94 check 1 moves from input-level to global-level, everything else stays t= he same.

Thomas


On 21= Apr 2026, at 11:16, Oliver <gugger@gmail.com> wrote:

Hi Thomas

Thank you for your feedback and questio= ns!

Whether the new PSBT field should be on the inp= ut or a global field is a good question.
I did ask myself the same thing and then slightly leaned towar= d adding it to the input that directly references the TXID that contains th= e message hash.
But I don't = have strong opinions either way, so a global field would definitely also wo= rk.

> how does a parser that ingests PSBTs gener= ically distinguish a BIP-322 proof-of-funds from a regular transaction PSBT= ?

I did add a section that covers detection to the = BIP, see

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 m= essage to be signed but the additional checks I propose also help to make s= ure it's a well-formed and valid BIP-322 PSBT.

>= Worth noting because it suggests "signer context" deserves to be a first-c= lass concern in PSBT design broadly.

Yes, that's something I noticed= in another project as well. A more generic approach to "signer context" wo= uld 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 movin= g forward.


I work o= n PSBT tooling (author of BTSL [1], a declarative validation layer for mult= i-party PSBT workflows) so the PSBT parts caught my attention.

On PSB= T_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 implic= it convention that the first input carries transaction-wide metadata. Was t= here 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 transactio= n 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 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 =C3=A0 09:26:14 UTC+2, Oliver a =C3= =A9crit :
Dear mailing list
<= br>I've started an implementation of BIP-322 in Go ([1]), and during implem= entation I noticed
that a number of open questions remain.

I beli= eve that these open questions and the "Draft" status are contributing reaso= ns for the
BIP not being widely implemented.
I do see demand for gene= ric message signing in discussions and pull requests, though, so I'm
tak= ing a shot at helping to move the BIP forward ([2]).

In short, I'm p= roposing 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.
&nb= sp;- Introduce a new PSBT field for for PSBT-based message signing.

= Let me explain the details and reasoning behind the changes:


Hum= an-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 fi= xed-length (for easy detection and parsing) human-readable prefix that
i= s simply prepended to the base64-encoded signature should make detection qu= ite straightforward
in code and also make it easy to distinguish a BIP-3= 22 signature from a legacy one.
The proposed prefixes are: `smp`, `ful`,= `pof` for the 'simple', 'full' and 'Proof of Funds'
variants respective= ly.
Because there already are implementations of BIP-322 out there, I al= so added a backward
compatibility clause for existing implementations. O= bserving that many of the implementations
I found and looked at only pro= duce signatures of the 'simple' variant, an implementation may
assume th= e '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
sel= ection and purpose of the UTXOs (e.g., completeness or unspent status) rema= in 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` t= ransaction is valid, should be part of the specification.
However, valid= ating the witness of an additional input requires its UTXO information.
= Instead of coming up with a custom encoding for the UTXO information in add= ition to the
full `to_sign` transaction, I realized that a finalized PSB= T contains exactly the information
we require: The full transaction, the= witness and/or signature scripts and the (Non-)Witness
UTXO fields. A f= inalized PSBT also must not contain fields that may be detrimental to priva= cy,
like internal keys, xPubs or script information.
Therefore, I pro= pose that the encoding format for the "Proof of Funds" variant should be th= e
full, base64-encoded PSBT of the `to_sign` transaction, but in the "fi= nalized" state as
described in BIP-174.
Because non-witness inputs re= quire the whole previous transaction to be present, I also added
a size = optimization that allows this field to be reused between inputs if more tha= n one input
references the same previous transaction.


New PSB= T field for PSBT-based message signing
------

When creating a sig= nature for a multisig address script, it makes sense to use a PSBT to geta signature for the `to_sign` transaction from each signer.
However, a= lthough 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 i= nto 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` t= ransaction 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 pr= ocedure 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 inten= t and terminology of the BIP, make it clear what it can't prove (the PR bod= y
   [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/p= ull/2521
[2]: https://github.com= /bitcoin/bips/pull/2141
[3]:&n= bsp;https://groups.google.com/g/= bitcoindev/c/RCi1Exs0ZvQ/m/NsFQcCcaCAAJ

-- 
You received this message because you are subscribed to a topic in the= Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic= , visit https://gr= oups.google.com/d/topic/bitcoindev/qd6BNz9gxCk/unsubscribe.
To un= subscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.
T= o view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6dc35b8a-e837-4fc9= -9a17-ca29204bf738n%40googlegroups.com.

--
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/bitcoindev/E17F4= A33-34AF-4E6C-AC15-69854AE8A08E%40gmail.com.
--Apple-Mail=_2D488F5B-C204-4C0C-A6F8-7165A64E2052--