BIP-322 nit fixes#2162
Conversation
scgbckbone
left a comment
There was a problem hiding this comment.
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
| === 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 |
There was a problem hiding this comment.
Right, the link here no longer makes sense since this sentence was moved to the start of the section.
|
ACK, good fixups. Thank you, @scgbckbone, I've noted to cc you on further BIP 322 changes.
@guggero thoughts on this? |
| @@ -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 | |||
|
|
|||
There was a problem hiding this comment.
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.
Yes, that seems right. The rest of the validation should remain the same in your case.
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 |
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
pofprefix on the wire format looks structurally redundant. The spec already requiresPSBT_GLOBAL_GENERIC_SIGNED_MESSAGEto 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...