BIP-0322: clarify motivation/purpose, add prefix, clarify Proof of Funds format, describe PSBT based signing #2141

pull guggero wants to merge 12 commits into bitcoin:master from guggero:bip-0322-finalization changing 5 files +773 −218
  1. guggero commented at 2:32 PM on April 14, 2026: contributor

    This PR is an attempt to push this PR forward, hopefully closer to a Complete state.

    If it helps the process and @kallewoof agrees, I'm volunteering to be named as a deputy for this BIP.

    The PR addresses the following discussion items:

    TODO (will follow up with these items soon):

    • https://github.com/bitcoin/bitcoin/pull/16440#issuecomment-568479290
      • Clean up wording: Clarify that there might not always be a cryptographic signature involved (e.g. pure script spend address types)
    • Update btcd pull request to reflect above changes, update test vectors in this PR (prefix and Proof of Funds implementation)
    • Rebase and update after #2135 is merged @murchandamus I went through the different discussions you linked and also both Bitcoin Core PRs and tried to extract all discussion items that I felt were not yet addressed. If anyone feels like a previous discussion item is missing here and not yet addressed by my changes, please comment below!
  2. in bip-0322.mediawiki:186 in 1f65ed5ae0 outdated 
     179 | @@ -180,6 +180,13 @@ Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poels
 180 |  
 181 |  # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html
 182 |  
 183 | +== Changelog ==
 184 | +
 185 | +* '''1.0.0''' (202?-??-??):
 186 | +** Mark Final
    murchandamus commented at 3:23 PM on April 14, 2026:

    In commit "BIP-0322: add tentative changelog"

    Final is a loaded term in context of the BIPs process. It used to refer to the status that we now call Deployed. Perhaps you could clarify whether you intend to move the BIP to Complete ("all planned work is done, and you are recommending it for adoption") or to Deployed ("all of the above, and at least one project is using it in production on mainnet"). This Changelog entry would then best be paired with the corresponding status change.

    guggero commented at 4:38 AM on April 15, 2026:

    Yeah, you're right, changed to Complete.

  3. jonatack added the label Proposed BIP modification on Apr 14, 2026
  4. jonatack added the label Pending acceptance on Apr 14, 2026
  5. jonatack commented at 3:28 PM on April 14, 2026: member

    Thank you @guggero for picking this up.

    If it helps the process and @kallewoof agrees, I'm volunteering to be named as a deputy for this BIP. @kallewoof thoughts? (If helpful, see BIP3 here for details about the Deputy role.)

  6. in bip-0322.mediawiki:22 in 429c24f66e outdated 
      18 | @@ -19,9 +19,13 @@ A standard for interoperable signed messages based on the Bitcoin Script format,
  19 |  
  20 |  The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
  21 |  
  22 | +The Proof-of-Funds variant allows demonstrating control of a set of UTXOs. The list of UTXOs may or may not be related to the address being signed (the address is optional in the Proof-of-Funds variant). But in any case, the UTXO list does not aim to prove completeness (e.g. it does NOT mean: "these are all UTXOs that exist for an address") nor that they are unspent (e.g. a validator must consult the blockchain to verify that).
    murchandamus commented at 3:34 PM on April 14, 2026:

    “The list of UTXOs may or may not be related to the address being signed”

    What “address” is this referring to? I thought BIP 322 message signing works by essentially creating a “fake” transaction where the list of inputs demonstrates control of UTXOs by providing valid inputs for the corresponding output scripts. I’m confused by the singular address vs UTXO list in this line.

    guggero commented at 4:41 AM on April 15, 2026:

    The address is the pkScript you spend in the to_spend transaction, also called the message_challenge in the BIP. In the simple and full case, that's the single UTXO you spend with the fake transaction. In the proof of funds case, you can add more UTXOs, but those don't have to be related to the address. I clarified this in the latest update.

  7. in bip-0322.mediawiki:26 in 429c24f66e outdated 
      18 | @@ -19,9 +19,13 @@ A standard for interoperable signed messages based on the Bitcoin Script format,
  19 |  
  20 |  The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
  21 |  
  22 | +The Proof-of-Funds variant allows demonstrating control of a set of UTXOs. The list of UTXOs may or may not be related to the address being signed (the address is optional in the Proof-of-Funds variant). But in any case, the UTXO list does not aim to prove completeness (e.g. it does NOT mean: "these are all UTXOs that exist for an address") nor that they are unspent (e.g. a validator must consult the blockchain to verify that).
  23 | +
  24 |  Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
  25 |  
  26 | -Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations.
  27 | +Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No message signing protocol can fix these limitations.
    murchandamus commented at 3:51 PM on April 14, 2026:

    Could you please generally limit the length of any lines you add? Whitespace in the Mediawiki sourcecode doesn’t affect the rendering of the document, but GitHub stops highlighting the changed words after certain lengths:

    <img width="982" height="145" alt="Image" src="https://github.com/user-attachments/assets/1759914b-8396-40ea-b5d6-a1782885f6d0" />

    It is easier to parse what changed across commits when the text is composed of shorter lines, and it is also easier to provide suggestions in review comments. I would suggest a maximum text-width of 100 characters for the initial additions, and would request that diffs are minimized afterwards (i.e., when updating any line, allow for slightly shorter or longer lines over rebreaking or otherwise affecting untouched lines; for longer additions prefer inserting another line over changing linebreak of the following lines).

    E.g., in the example below instead of moving "procedures" to the next line to make the first line adhere to the original length limit, which would make the diff appear bigger than it is, it’s kept in the same line to minimize the diff.

    <img width="1031" height="172" alt="Image" src="https://github.com/user-attachments/assets/95b7db11-e202-42f2-aab2-009a1ba0ee59" />

    Basically, please treat the document’s text like code! 🤓

    Please Note that I’m not requesting that you reformat the entire existing document. Should you decide to do that, please make it a separate commit.

    guggero commented at 4:47 AM on April 15, 2026:

    Hmm, yeah, I also don't like long lines. I remembered mediawiki being really weird when it comes to lists, so I didn't change the line length initially (I also try to match the code style of any project I contribute to). But shorter lines makes it much easier to work with text, I agree. So I added a commit at the beginning that does some formatting.

    IMO the deeply nested lists don't become easier to read with this. So I opted for just keeping the long lines there for now. Let me know if you think it's worth changing those.

    The alternative of course would be to move over to markdown completely. Which I'm not sure is a documented process?

  8. in bip-0322.mediawiki:274 in b58cff9e67 
     274 |  # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html
 275 |  
 276 | +== Changelog ==
 277 | +
 278 | +* '''1.0.0''' (202?-??-??):
 279 | +** Mark Final
    jonatack commented at 4:10 PM on April 14, 2026:

    Per BIP3, statuses are now one of Draft | Complete | Deployed | Closed.

    The BIP status doesn't appear to be updated from Draft in this PR.

    guggero commented at 4:38 AM on April 15, 2026:

    Right, added the change from Draft -> Complete now in the last commit and fixed the changelog.

  9. murchandamus commented at 4:22 PM on April 14, 2026: member

    Partial review of the first three commits.

  10. kallewoof commented at 11:25 PM on April 14, 2026: contributor

    Thank you @guggero for picking this up.

    If it helps the process and @kallewoof agrees, I'm volunteering to be named as a deputy for this BIP.

    @kallewoof thoughts? (If helpful, see BIP3 here for details about the Deputy role.)

    Sounds good to me!

  11. guggero force-pushed on Apr 15, 2026
  12. guggero force-pushed on Apr 15, 2026
  13. guggero commented at 5:17 AM on April 15, 2026: contributor

    I updated the prefixes to be fixed-size (smp, ful, pof) and removed the colon to make copy/paste errors by users less likely. @murchandamus I don't really understand the failing CI check... Am I supposed to change the background color of the row in the README?

  14. guggero commented at 12:48 PM on April 15, 2026: contributor

    I've implemented the proposed changes (prefix, Proof of Funds format) in the btcd PR and updated the test vectors here. With that, all (current) TODOs are addressed and I think this PR is ready for a closer look by anyone interested.

  15. guggero force-pushed on Apr 15, 2026
  16. in bip-0322.mediawiki:303 in b01fa36f91 outdated 
     302 |  == Compatibility ==
 303 |  
 304 |  This specification is backwards compatible with the legacy signmessage/verifymessage specification
 305 |  through the special case as described above.
 306 | +To support backward compatibility with implementations of this BIP before it was finalized, a
 307 | +verifier might assume the ''simple' variant in the absence of a prefix.
    murchandamus commented at 3:50 PM on April 15, 2026:

    This sounds like it warrants a Changelog entry. Could you please record the breaking change there?

    You can find guidance about that in BIP3 here: https://github.com/bitcoin/bips/blob/master/bip-0003.md#changelog-section-and-version-header

    guggero commented at 7:46 AM on April 20, 2026:

    Yes, you're right. I updated the changelog to point out the breaking changes.

  17. in bip-0322.mediawiki:8 in 1ee1a210d2 
       5 | @@ -6,7 +6,7 @@
   6 |    Deputies: guggero <gugger@gmail.com>
   7 |    Comments-Summary: No comments yet.
   8 |    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322
    murchandamus commented at 4:52 PM on April 15, 2026:

    I took a look at the comments wiki page. It just contains a couple questions and a link to this Bitcoin Talk discussion: https://bitcointalk.org/index.php?topic=5408898.l0.

    I did not read the discussion, but if you find it interesting, you could add it as an entry to the "Discussion" header. You would then be free to drop the Comments headers as they are not required per BIP3 and the page doesn’t seem useful to me for this BIP.

    guggero commented at 7:46 AM on April 20, 2026:

    Good idea, done!

  18. in README.mediawiki:1081 in 1ee1a210d2 outdated 
    1077 | @@ -1078,7 +1078,7 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
1078 |  | Generic Signed Message Format
1079 |  | Karl-Johan Alm
1080 |  | Specification
1081 | -| Draft
1082 | +| Complete
    murchandamus commented at 4:54 PM on April 15, 2026:

    You also need to update the background color in line 1075 (above) to

    |- style="background-color: #cfffcf"

    murchandamus commented at 5:15 PM on April 15, 2026:

    To clarify, that’s the cause of the CI failure.

  19. in bip-0174/type-registry.mediawiki:193 in 81b5a1ce3c outdated 
     186 | @@ -187,6 +187,10 @@ This document collects the fields and types used in PSBTs of any version from al
 187 |  | <tt>PSBT_IN_SP_TWEAK = 0x20</tt>
 188 |  | [[bip-0376.mediawiki|376]]
 189 |  |-
 190 | +| Generic Signed Message
 191 | +| <tt>PSBT_IN_GENERIC_SIGNED_MESSAGE = 0x21</tt>
 192 | +| [[bip-0322.mediawiki|322]]
 193 | +|-
    murchandamus commented at 4:57 PM on April 15, 2026:

    cc: @achow101, no action required, just wanted to make you aware of this overlap with PSBTs, in case you had thoughts on PSBTs being used for Generic Message Signing.

    achow101 commented at 10:15 PM on April 21, 2026:

    Seems fine

    murchandamus commented at 10:17 PM on April 21, 2026:

    Thanks for taking a look, @achow101.

  20. in bip-0322.mediawiki:487 in 81b5a1ce3c outdated 
     497 | +== Changelog ==
 498 | +
 499 | +* '''1.0.0''' (2026-04-15):
 500 | +** Mark Complete
 501 | +* '''0.0.1''' (2018-09-10):
 502 | +** Proposed as draft
    murchandamus commented at 5:00 PM on April 15, 2026:

    BIP322 has been out there for nigh a decade and I think there are some implementations of it in production. From what I understand this update includes a breaking change to the format. While it was in Draft status and changes should still be expected, this may come as a surprise due to the age of the proposal. Therefore, I would request that you clearly document the breaking change in the Changelog and write to the mailing list about this update to BIP322.

    murchandamus commented at 8:56 PM on April 15, 2026:

    When you start versioning the document per a Changelog section, please also add the Version header to the preamble!

    guggero commented at 7:47 AM on April 20, 2026:

    I updated the changelog to point out the breaking changes. And I also summarized the changes in a message to the mailing list: https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk The link is now also included in the discussion list.

    murchandamus commented at 6:53 PM on April 20, 2026:

    Awesome, thanks for doing that.

  21. murchandamus commented at 5:02 PM on April 15, 2026: member

    Finished my first pass. I think it’s great that you want to pick up this proposal and bring it up to speed. Strong concept ACK. You also seem to have buy-in from @kallewoof, which is great. Given the age of the proposal and the breaking change, I would heartily recommend that you write to the mailing list about the changes you are proposing in this PR.

  22. in bip-0322.mediawiki:224 in 421803f06c outdated 
     223 | +  control of.
 224 | +</li>
 225 | +<li>
 226 | +  They satisfy <code>to_sign</code> as they would any other transaction.
 227 | +</li>
 228 | +</ol>
    murchandamus commented at 5:07 PM on April 15, 2026:

    Thanks for changing the formatting to shorter lines!

    I am not sure what you mean about Mediawiki having issues with lists, I wasn’t aware, but if it helps, I wouldn’t have minded longer lines in lists. The HTML list syntax (…<ol><li>…) strikes me as more visual clutter in the source code compared to the Mediawiki syntax. It looks fine in the rendered document, though, so no need to change it again.

    guggero commented at 7:51 AM on April 20, 2026:

    I have not found a way to break a list item into several lines when using the mediawiki syntax. There is the #: continuation syntax but that introduces a line break and additional indentation in the rendered version. It felt weird to leave the lists as long lines, so I updated the easier ones, where there wasn't a lot of nesting. But I agree that the <ol><li> syntax doesn't make things very clear for editors... I'm happy to revert and just keep the long lines for now. Or perhaps someone knows a trick to format mediawiki list items properly? I assume converting to markdown is not the way to go at this point?

    murchandamus commented at 6:58 PM on April 20, 2026:

    Yeah, my alternative would have been to just leave the lines in the list items longer than the others, but if the HTML tags are just more robust then that might be the best solution for the lists. I don’t think it would be worth it to convert it to different syntax or Markdown now.

  23. murchandamus commented at 5:14 PM on April 15, 2026: member

    Oh one more observation:

  24. murchandamus removed the label Proposed BIP modification on Apr 15, 2026
  25. murchandamus removed the label Pending acceptance on Apr 15, 2026
  26. murchandamus added the label PR Author action required on Apr 15, 2026
  27. murchandamus added the label BIP update by author on Apr 15, 2026
  28. BIP-0322: wrap long lines at 100 characters
    This re-formats the document for easier editing and diff viewing.
Wiki syntax is weird for lists and line wraps break them. Simple lists
were changed to <ul> or <ol> tags but complex lists remain as they are
to not bloat the diff too much.
    6f3fce21e6
  29. BIP-0322: small semantic and formatting fixes
    This fixes small inconsistencies or incomplete definitions based on
previous, already merged changes.
    bbaf40ce1d
  30. BIP-0322: reference btcd implementation 665d96065f
  31. BIP-0322: update motivation, clarify Proof of Funds purpose
    This addresses two discussion items:
 - The list of UTXOs should not be interpreted as a "proof that no other
   UTXOs for an address exist".
 - The BIP only addresses "signer receives funds with the address" and
   not "signer sent a previous transaction" use case.
    0a20483c65
  32. BIP-0322: clarify terminology used
    Since the term "signature" can be pretty overloaded dependin on the
context, we clarify what it actually means in this BIP.
    8a46a5bfa5
  33. BIP-0322: encode finalized PSBT for Proof of Funds
    This commit proposes a fix for the problem that an offline verifier
previously was not able to even verify the witness stack of additional
inputs. By providing the full finalized PSBT, a verifier has all the
input data necessary to run the script through the validation engine.

We require the PSBT to be finalized to make sure it contains the final
script witness or final script sig but no extra potentially
privacy-sensitive fields. The Non-Witness and Witness UTXO fields are
explicitly allowed for finalized PSBTs, which makes the format perfect
for the use case.
    833a1a8a89
  34. BIP-0322: add prefix to message signature c2850a0010
  35. guggero force-pushed on Apr 20, 2026
  36. guggero force-pushed on Apr 20, 2026
  37. guggero commented at 7:52 AM on April 20, 2026: contributor

    Thank you all for your inputs and reviews so far! As you might already have received in your respective inboxes, my message to the mailing list has been published: https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk

  38. in bip-0322.mediawiki:16 in 3300b28e61 
      14 | +  Discussion: 2019-07-23: https://github.com/bitcoin/bitcoin/pull/16440
  15 | +              2022-01-13: https://github.com/bitcoin/bitcoin/pull/24058
  16 | +              2022-08-06: https://bitcointalk.org/index.php?topic=5408898.0
  17 | +              2024-05-04: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/vp6Xo36aBwAJ
  18 | +              2025-05-10: https://bitcoin.stackexchange.com/questions/126277/where-can-i-use-bip322-to-sign-a-message-to-verify-a-multisig-address
  19 | +              2026-04-20: https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk
    jonatack commented at 3:03 PM on April 20, 2026:

    nit, perhaps better to link to the top post

                  2026-04-20: https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk/m/k1fHq4RKAQAJ
  39. jonatack commented at 3:10 PM on April 20, 2026: member

    Given the work here, would it make sense for @guggero to be an author? @kallewoof

  40. jonatack removed the label PR Author action required on Apr 20, 2026
  41. in bip-0322.mediawiki:482 in ff4c6574b6
    murchandamus commented at 7:19 PM on April 20, 2026:

    I would recommend that the original mailing list thread also be listed in the Discussion header.

    guggero commented at 8:30 AM on April 21, 2026:

    Ah, yes, definitely. Pushed in a fixup commit.

  42. murchandamus commented at 7:20 PM on April 20, 2026: member

    I gave the document another full read, it looks good to me. I left one more suggestion.

  43. murchandamus commented at 3:26 PM on April 21, 2026: member

    I went over the commits one more time, LGTM. It might be good to have a PSBT expert take a look. Are you otherwise still waiting for review or is this ready to go from your perspective?

    Edit: Ava Chow took a look and stated "seems fine" above in #2141 (review).

  44. AlthaafM commented at 3:42 PM on April 21, 2026: none

    Good day Murch trust you are well, "Thank you for the review, Murch. From my perspective, the core logic for the PSBT-based signing and the Proof of Funds format is ready for a deeper dive. I would welcome a review from a PSBT expert to ensure the implementation aligns perfectly with current standards (BIP 174/370). I have also started a thread on the mailing list to ensure the conceptual side is fully socialized."

    Althaaf Mohamed +27670672423

    On Tue, 21 Apr 2026, 17:28 Murch, @.***> wrote:

    @.**** commented on this pull request.

    I went over the commits one more time, LGTM. It might be good to have a PSBT expert take a look. Are you otherwise still waiting for review or is this ready to go from your perspective?

    — Reply to this email directly, view it on GitHub https://github.com/bitcoin/bips/pull/2141?email_source=notifications&email_token=CCJH5M23XNE5KJ73AZJKPUL4W6HSJA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMJUHA4TCNBZHAY2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOS6XA4S7OJSXM2LFO5PW433UNFTGSY3BORUW63TTL5RWY2LDNM#pullrequestreview-4148914981, or unsubscribe https://github.com/notifications/unsubscribe-auth/CCJH5M6KQFYVNIUZIBLWREL4W6HSJAVCNFSM6AAAAACXY62O2KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DCNBYHEYTIOJYGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

  45. AlthaafM commented at 4:13 PM on April 21, 2026: none

    "I've updated the reference implementation to use double-SHA256 (SHA256d) and added input validation to ensure the logic follows Bitcoin's standard Merkle tree conventions. This should address the previous technical concerns regarding implementation completeness."

  46. guggero commented at 6:36 AM on April 22, 2026: contributor

    Are you otherwise still waiting for review or is this ready to go from your perspective?

    I didn't consult with @kallewoof about my suggested changes before opening the PR, as I wanted to show a complete picture before starting any discussions. So a quick word from the original author would be appreciated to ensure my updates still align with the initial vision for the BIP.

    And I also want to give the mailing list thread a bit of time for discussions to unfold. There already is a proposal for a change to move the PSBT field from an input field to a global field.

    Detailed review is definitely welcome but a merge would be a bit premature at this point IMO.

  47. AlthaafM commented at 7:10 AM on April 22, 2026: none

    Hi @guggero, thanks for checking in.

    From my perspective, the core vision for the Proof of Funds project remains the same. I have the Reference Implementation (Merkle root logic for leaf duplication and the 0x21 field mapping) verified locally and ready to be integrated.

    I was holding off on pushing those final code updates to avoid interfering with the high-level review of the BIP registry entry. If you feel the vision aligns, I can provide the implementation and test vectors whenever you're ready for them.

    Regarding the move from an 'input' to a 'global' field, I'm happy to follow the consensus of the reviewers.

  48. murchandamus commented at 10:51 PM on April 22, 2026: member

    Okay great, let’s revisit in a week or so, on April 28th or later.

  49. guggero force-pushed on Apr 29, 2026
  50. guggero commented at 11:12 AM on April 29, 2026: contributor

    I've updated the PR to define a new PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE = 0x09 field (as suggested by Tomas on the mailing list thread) instead of a per-input one. I also added an UTF-8 message to the test vectors and applied previous fixup commits.

    IMO this is good to go now, though more review would still be nice.

  51. murchandamus commented at 5:05 PM on April 29, 2026: member

    Thanks for the update. I’m putting this on my queue to read again. Especially because it is being advanced to Complete, more review would certainly not hurt. I’ll check in with you after reviewing it before merging the PR.

  52. murchandamus commented at 9:36 AM on May 6, 2026: member

    ACK. Looks good to me. If you are not currently expecting more review and are finished with your planned work, I would suggest that we publish this update whenever you greenlight that.

  53. in bip-0322.mediawiki:370 in a1f4350035 
     376 | +  They set the appropriate PSBT input and global fields as required by the signers(s) to produce a
 377 | +  partial signature.
 378 | +</li>
 379 | +<li>
 380 | +  They set the <code>PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE</code> field, using the full UTF-8 encoded
 381 | +  message as the <code>keydata</code>.
    achow101 commented at 10:03 AM on May 6, 2026:

    Should be valuedata

    guggero commented at 10:20 AM on May 6, 2026:

    Thanks, fixed!

  54. BIP-0174+BIP-0322: describe PSBT based signing
    This commit proposes a new PSBT input field type for transporting the
message to be signed to different signers in a multisig signing use
case.
    0dd436e7d4
  55. BIP-0322: update test vectors
    This commit updates the test vectors to reflect all the changes in the
previous commits and also introduces new test vectors for the Proof of
Funds variant.
    d77863fb9e
  56. BIP-0322: add guggero as deputy e69e2f9717
  57. BIP-0322: remove comments, add discussion links
    As described in BIP-0003, the comments section is no longer required.
Instead we add all relevant discussions.
    414e16f5a2
  58. README+BIP-0322: add changelog, mark Complete 40dc3e1a19
  59. guggero force-pushed on May 6, 2026
  60. guggero commented at 10:25 AM on May 6, 2026: contributor

    ACK. Looks good to me. If you are not currently expecting more review and are finished with your planned work, I would suggest that we publish this update whenever you greenlight that.

    Thank you for the re-review! Sounds good to me. I don't have any more work planned and all current review comments are addressed. I'm not aware of any in-progress review. Still feels weird to merge without @kallewoof's direct approval though. But I leave the decision to you, the BIP maintainers/editors.

  61. kallewoof commented at 12:54 PM on May 6, 2026: contributor

    Still feels weird to merge without @kallewoof's direct approval though. But I leave the decision to you, the BIP maintainers/editors.

    I've been following the discussion even if I haven't commented. And I personally don't think I have any rights to any of this at this point, seeing as I failed to get this pushed through to adoption myself. I will comment if something looks off to me, of course, but silence is implicit approval.

  62. jonatack assigned jonatack on May 6, 2026
  63. in bip-0322.mediawiki:18 in 40dc3e1a19 
      16 | +              2022-01-13: https://github.com/bitcoin/bitcoin/pull/24058
  17 | +              2022-08-06: https://bitcointalk.org/index.php?topic=5408898.0
  18 | +              2024-05-04: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ/m/vp6Xo36aBwAJ
  19 | +              2025-05-10: https://bitcoin.stackexchange.com/questions/126277/where-can-i-use-bip322-to-sign-a-message-to-verify-a-multisig-address
  20 | +              2026-04-20: https://groups.google.com/g/bitcoindev/c/qd6BNz9gxCk/m/k1fHq4RKAQAJ
  21 | +  Version: 1.0.0
    jonatack commented at 3:19 PM on May 7, 2026:

    nit, after the Version header could add a Requires: 174, 340 header (along with any other BIPs this one depends on)

  64. in bip-0322.mediawiki:36 in 40dc3e1a19 
      40 | +coins, no matter what script they are controlled by, can in-principle be signed for. For easy
  41 | +interoperability with existing signing hardware, we also define a signature message format which
  42 | +resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on
  43 | +any real network).
  44 | +
  45 | +The Proof of Funds variant allows demonstrating control of a set of UTXOs.
    jonatack commented at 3:24 PM on May 7, 2026:

    As this is the first mention of the Proof of Funds variant, perhaps introduce it in some way, and/or link to where it is defined below for more details.

    guggero commented at 7:33 AM on May 8, 2026:

    Slightly adjusted the wording and linked to the section that explains the variant (in the follow-up PR).

  65. in bip-0322.mediawiki:99 in 40dc3e1a19 
     107 | +| <code>pof</code>
 108 | +| full finalized PSBT of the <code>to_sign</code> transaction, consensus and base64-encoded
 109 |  |}
 110 |  
 111 | -<sup>1</sup>: Possible on a technical level but should NOT be used anymore in the context of this BIP.<br/>
 112 | +<sup>1</sup>: Possible on a technical level but should NOT be used anymore in the context of this
    jonatack commented at 3:27 PM on May 7, 2026:

    nit, might be helpful to briefly describe why

    guggero commented at 7:34 AM on May 8, 2026:

    Hmm, to be honest, I'm not 100% sure why this was defined the way it is in the Legacy section, which was already present before my changes. So I just linked to that section to make the footnote more clear in that it refers to that rule.

  66. jonatack commented at 3:40 PM on May 7, 2026: member

    It's good that you addressed backward compatibility, as IIUC software already implementing the draft version of BIP322 could break when encountering the new 1-byte prefix. I don't know the current state of existing implementations.

    A couple nits follow; they along with a minor grammar round-up could be done in a follow-up.

    (If @kallewoof agrees, I think it would make sense @guggero for you to be co-author of BIP322 for your work.)

    What is the easiest way for implementers to run the test vectors? By running btcutil/bip322/test_vectors_test.go in https://github.com/btcsuite/btcd/pull/2521?

  67. jonatack merged this on May 8, 2026
  68. jonatack closed this on May 8, 2026
  69. kallewoof commented at 6:46 AM on May 8, 2026: contributor

    (If @kallewoof agrees, I think it would make sense @guggero for you to be co-author of BIP322 for your work.)

    Sounds good to me.

  70. guggero deleted the branch on May 8, 2026
  71. guggero commented at 7:31 AM on May 8, 2026: contributor

    @jonatack thanks for the review! I've created the follow-up PR here: #2155

    along with a minor grammar round-up

    Anything specific you noticed or should I just do a general grammar pass?

    What is the easiest way for implementers to run the test vectors?

    Yes, checking out and running cd btcutil/bip322; go test -test.run 'Test.*Vectors' ./... is one option. Another option is to run the tests in btcutil-js that executes the same test vectors using the same Golang code but through a WASM binary.

  72. jonatack commented at 6:42 PM on May 8, 2026: member

    Yes, checking out and running cd btcutil/bip322; go test -test.run 'Test.*Vectors' ./... is one option. Another option is to run the tests in btcutil-js that executes the same test vectors using the same Golang code but through a WASM binary.

    Thanks, will test!

    Anything specific you noticed or should I just do a general grammar pass?

    I'll comment on the new PR with a link to a diff.

Contributors
guggeromurchandamusjonatackkallewoofachow101AlthaafM
Labels
BIP Update by Owner
Linked (view graph)
#2135 BIP174: Deduplicate type definitions by introducing registry file#2155 BIP-0322: polishing follow-up
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-09 20:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me