[BIP Draft] Co-signer Spending Policies

Posted by PREDGE

Oct 22, 2026/21:01 UTC

The signed tuple in statement v0 consists of the event ID, outcome, and timestamp. This structure currently does not indicate whether the outcome is final or subject to change. In scenarios such as escrow delivery or other events resolved by human decision-makers, it is common for attestors to issue an initial response and subsequently revise it as new information emerges. When a co-signer encounters a valid statement within a specified maximum age, there is a risk that the signature may be applied to a preliminary answer rather than the definitive resolution.

To address this ambiguity, two solutions are proposed. One approach involves introducing a finality flag within the signed tuple, enabling evidence conditions to explicitly require confirmation of finality before acceptance. Alternatively, for use cases such as escrow, it can be mandated that templates incorporate a waiting period corresponding to a dispute window, thereby ensuring that outcomes have remained uncontested before signatures are finalized.

Regarding data serialization formats, both JSON and TLV are considered viable options. Regardless of which format is ultimately selected, it is essential that test vectors for the policy ID are established using the precise byte representations. Canonical JSON poses particular challenges, as differences in implementation can lead to byte-level inconsistencies. Ensuring standardized test vectors will help maintain interoperability across different implementations.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiDecoding BitcoinWarnet
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project.

Give Feedback