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.
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