Posted by lukecarriere
Oct 28, 2026/14:37 UTC
The policy ID is constructed as the BIP340 tagged hash, using the tag CSP/policy, derived from the canonical serialization of the policy. The format version is mandated as the first field in the preimage, and the tag is updated to CSP/policy/v0 to align with CSP/statement/v0. This ensures a clear distinction between policy and statement commitments, which already utilize separate tags. Additionally, every CSP tag remains distinct from those used in BIP340 or BIP341.
Strict validation rules govern the handling of policies. Any policy containing unknown fields is rendered invalid, and co-signers are required to refuse to sign under such circumstances. Extensions to the policy format must be introduced through new profile versions rather than by allowing unrecognized fields to be ignored. The presence of duplicate keys also invalidates a policy document. There are no implicit defaults, so every field must be serialized explicitly. This explicit serialization guarantees that the hashed bytes precisely represent the enforced conditions.
To further clarify correct implementation, test vectors will be included. These will encompass not only positive cases but also examples of documents that should be rejected, such as those containing unknown fields, duplicate keys, or missing required fields. Exact-bytes test vectors requested by @PREDGE will also be provided.
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback