Skip to content

Anti-equivocation for the C2SP checkpoint hook: an OpenTimestamps/Bitcoin adapter (Corollary 4.1) #1

Description

@MarkovianProtocol

Really enjoyed the Right to History design, the single-user sovereignty framing plus RFC 6962 logs is a clean way to make an agent's own history tamper-evident.

One thing I wanted to raise, framed entirely around your own Corollary 4.1 and section 4.6. You note that in the single-user, single-machine deployment, external root anchoring is needed to realize anti-equivocation in practice, and that the kernel already exports signed tree heads in the C2SP checkpoint format as the architectural hook for it, but the anchoring itself is not yet implemented. So anti-equivocation, the property, is specified but not yet realized in the shipped kernel.

The two options section 4.6 names are "a public service or a trusted third party." OpenTimestamps gives you the public-service half without the trusted-third-party half, which is the best match for a sovereignty kernel: you timestamp the checkpoint into Bitcoin, and verification later needs only Bitcoin block headers. There is no operator to trust, no service that can equivocate, and it still verifies even if the anchoring service or the OTS calendars disappear, because the proof is self-contained against the chain. That maps cleanly onto a single-user, self-hosted threat model where you explicitly do not want to reintroduce a trusted party.

Concretely it is additive and needs no change to your log semantics. You already emit a C2SP checkpoint (origin, tree size, base64 root hash). You stamp those exact bytes, then upgrade the proof once it is in a block:

# checkpoint = your existing C2SP signed tree head bytes
$ ots stamp checkpoint.txt          # -> checkpoint.txt.ots  (commitment submitted to Bitcoin)
# ... after ~1 block confirmation ...
$ ots upgrade checkpoint.txt.ots    # embeds the Bitcoin block proof
$ ots verify checkpoint.txt.ots     # verifies against Bitcoin headers, no operator in the path

Programmatically the commitment is just: sha256 the checkpoint bytes, submit to the OTS calendars, store the returned proof beside the checkpoint; verification recomputes the sha256 and checks the inclusion proof down to a Bitcoin block header. Anyone holding a checkpoint can then confirm both that it existed before block N and that no second, forked checkpoint was ever anchored, which is exactly the anti-equivocation Corollary 4.1 asks for.

Happy to send a short reference adapter that takes your C2SP signed tree head and produces the .ots proof if it is useful, we maintain a small keyless tool that does this and it would be a clean fit under the hook you already built. Scope note so it stays honest: this gives existence-in-time and non-equivocation of the tree head, it does not change what the log records or assert anything about the actions themselves.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions