[BIP Draft] Co-signer Spending Policies

The objective is not to enforce a uniform set of co-signers, but rather to harmonize the various policies that dictate co-signer behavior across different technologies and platforms. This standardization aims to address the current fragmentation in the ecosystem, where solutions such as Halseth's blinded co-signers, Chain Code Delegation, predicate blind signatures, bonded co-signers, and products like Liquidium and Lendasat each operate under their own distinct rules. The lack of interoperability between these methods poses challenges for wallet compatibility and cross-platform integration.

The proposal introduces multiple verification processes—including open verification, blinded verification, and enclave verification—that collectively ensure transaction conditions are met with both transparency and security. All enforceable scripts must be included within the policy, guaranteeing that direct execution does not rely on the presence of a co-signer. Additionally, support for Discreet Log Contract (DLC) oracles is incorporated, allowing oracles to serve as unchanged sources of evidence. The full details of this BIP (Bitcoin Improvement Proposal) can be accessed at this link, where further public feedback is invited.

Central technical questions remain open for discussion. The draft invites input on data serialization options—specifically canonical JSON, TLV (Type-Length-Value), and CBOR—and their implications for test vectors, implementation consistency, and human readability. Each format presents unique trade-offs: TLV offers strict uniqueness per policy and seamless integration with existing protocols like Lightning and DLCs, but lacks human readability. Canonical JSON is widely supported and user-friendly but raises concerns about duplicate keys and inconsistent byte representations. CBOR is compact and standardized for airgapped transfers, though it is less commonly used for these objects. A hybrid approach is also considered, wherein strict TLV is used for hashing and signing, while a JSON mapping facilitates authoring and review. The decision on serialization has significant consequences for interoperability and long-term maintainability.

A key aspect of the policy hash is that it must capture the exact semantics of the verifier, not merely reference a syntactically valid document. This demands explicit handling of unknown fields, duplicate keys, and default values. Any deviation, such as the presence of unrecognized fields or duplicate keys, immediately invalidates the policy, ensuring stringent adherence to the intended policy logic. Policy commitments are domain-separated from both statement and transaction hashes, with the format version embedded as the first field in the hash preimage. The tagging scheme is structured to prevent collisions with existing standards, using CSP/policy/v0 for policies and maintaining separation from tags found in BIP340 and BIP341.

Within the signing process, the signed tuple initially comprised only the event ID, outcome, and timestamp, omitting any indication of whether an outcome was final or provisional. This posed potential risks in contexts like escrow, where outcomes may be revised by attestors. To mitigate this, a finality flag will be introduced, enabling evidence conditions to require confirmation of final status before permitting actions. In scenarios where finality cannot be marked, templates can incorporate dispute windows to provide a safeguard. For DLC attestations, finality is enforced cryptographically; signing conflicting outcomes exposes the attestor’s key, thus preventing ambiguity. Test vectors specifying the exact byte representation of policy IDs will be provided alongside the chosen serialization format, further promoting implementation consistency.

Ongoing development reflects active community engagement and iterative refinement. The latest draft, v2.1, incorporates strict verifier semantics, versioned commitments, signed finality, corrections for k-of-n thresholds, citation fixes, and header updates. However, certain aspects, such as the complete schema definition, exact-byte test vectors, and a reference implementation, remain works in progress. Public commentary and criticism continue to shape the evolution of this proposal, with ongoing discussions accessible via the original October 5 bitcoindev post and the latest draft update.

The choice of serialization remains undecided, with considerations detailed for TLV, canonical JSON, CBOR, and hybrid approaches. TLV ensures strict encoding with no duplicates or reordering, aligning well with existing Lightning and DLC messaging. Canonical JSON brings advantages in readability and tooling, though it requires additional validation to reject duplicate keys and handle normalization issues. CBOR