Skip to content

BIP-322 nit fixes#2162

Merged
jonatack merged 1 commit into
bitcoin:masterfrom
scgbckbone:bip322_break_changes
May 19, 2026
Merged

BIP-322 nit fixes#2162
jonatack merged 1 commit into
bitcoin:masterfrom
scgbckbone:bip322_break_changes

Conversation

@scgbckbone
Copy link
Copy Markdown
Contributor

Hi,

Writing from the Coldcard team — we shipped BIP-322 Proof-of-Reserves on 2026-03-06, before #2141 was merged. Reading the BIP-322 related PRs from last weeks it seems you have no idea we have live BIP-322 support in prod.

Refs:

As I understand updated BIP, none of the prefix business is part of Signer (HWW) flow. So we will be adding PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE + relaxing the requirement for 0th input to have non-witness utxo. Nothing else.

Thank you for moving the BIP forward!

One more observation: the pof prefix on the wire format looks structurally redundant. The spec already requires PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE to be present,
plus the prevout-of-to_spend and single-OP_RETURN-output rules — and PSBTs are self-marked at position 0 of the base64 (always start with cHNidP8). Dropping the prefix would let
verifier-side libraries feed the base64 straight into their existing PSBT parsers (without any change).

For future BIP-322 work we'd appreciate being tagged/contacted.

Thanks.

PR patch-list contains few small issues I found while reading...

Copy link
Copy Markdown
Contributor Author

@scgbckbone scgbckbone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://gist.github.com/orangesurf/0c1d0a31d3ebe7e48335a34d56788d4c

this is now also obsolete as PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE is required by BIP to be in PSBT globals

@jonatack jonatack added the Proposed BIP modification PR by non-owner to update BIP content label May 19, 2026
Comment thread bip-0322.mediawiki
=== Full (Proof of Funds) ===

The [[#full-proof-of-funds|Proof of Funds]] variant extends the basic scheme: in addition to signing
The Proof of Funds variant extends the basic scheme: in addition to signing
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the link here no longer makes sense since this sentence was moved to the start of the section.

@jonatack
Copy link
Copy Markdown
Member

ACK, good fixups.

Thank you, @scgbckbone, I've noted to cc you on further BIP 322 changes.

One more observation: the pof prefix on the wire format looks structurally redundant. The spec already requires PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE to be present, plus the prevout-of-to_spend and single-OP_RETURN-output rules — and PSBTs are self-marked at position 0 of the base64 (always start with cHNidP8). Dropping the prefix would let verifier-side libraries feed the base64 straight into their existing PSBT parsers (without any change).

@guggero thoughts on this?

@jonatack jonatack merged commit 53cc4e3 into bitcoin:master May 19, 2026
4 checks passed
@jonatack jonatack added Fixups Minor or clearly correct fixups that don't require BIP author review and removed Proposed BIP modification PR by non-owner to update BIP content labels May 19, 2026
Comment thread bip-0322.mediawiki
Comment on lines 167 to 499
@@ -260,7 +260,7 @@ Validation consists of the following steps:
# Check the '''upgradeable rules'''
## The version of <code>to_sign</code> must be 0 or 2.
## The use of NOPs reserved for upgrades is forbidden.
## The use of Segwit versions greater than 1 are forbidden.
## The use of Segwit versions greater than 1 is forbidden.
## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state.
# Let ''T'' be the nLockTime of <code>to_sign</code> and ''S'' be the nSequence of the first input of <code>to_sign</code>. Output the state ''valid at time T and age S''.

@@ -459,7 +459,7 @@ A '''transaction finalizer''' of a BIP322 PSBT must follow these steps:
This specification is backwards-compatible with the legacy signmessage/verifymessage specification
through the special case [[#legacy|as described above]].
To support backward compatibility with implementations of this BIP before it was finalized, a
verifier might assume the ''simple' variant in the absence of a prefix.
verifier might assume the ''simple'' variant in the absence of a prefix.

== Reference implementation ==

@@ -493,7 +493,7 @@ and many others for their feedback on the specification.
** Mark Complete
** Breaking change: Add human-readable prefix to encoded signature
** Breaking change: format of "Proof of Funds" signatures to be base64-encoded finalized PSBT
** Add new PSBT input field for PSBT-based signing
** Add new PSBT global field for PSBT-based signing
* '''0.0.1''' (2018-09-10):
** Proposed as draft

Copy link
Copy Markdown
Member

@jonatack jonatack May 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@guggero
Copy link
Copy Markdown
Contributor

guggero commented May 20, 2026

Reading the BIP-322 related PRs from last weeks it seems you have no idea we have live BIP-322 support in prod.

Yes, you are correct. I did not look into the specifics of existing implementations. My goal was to get the BIP to a complete state with a minimal diff. Sorry if this is causing friction on your end, especially given the timing of your PoF feature release.

As I understand updated BIP, none of the prefix business is part of Signer (HWW) flow. So we will be adding PSBT_GLOBAL_GENERIC_SIGNED_MESSAGE + relaxing the requirement for 0th input to have non-witness utxo. Nothing else.

Yes, that seems right. The rest of the validation should remain the same in your case.

and PSBTs are self-marked at position 0 of the base64 (always start with cHNidP8). Dropping the prefix would let verifier-side libraries feed the base64 straight into their existing PSBT parsers (without any change).

True. But having a BIP-related HRP for two of the variants and the PSBT-related for one would have felt weird and inconsistent. And the pof prefix also makes it very clear that it's not just any PSBT but one related to BIP-322 (e.g., must be finalized, input 0 is not a real UTXO). So hopefully snipping off three characters at the beginning is an okay tradeoff for validation side implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Fixups Minor or clearly correct fixups that don't require BIP author review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants