Anchor the MMR accumulator (bagged peaks) to Bitcoin as an existence witness verifiable with veracity

[MarkovianProtocol]

A MERKLE_LOG seal signs the MMR root, the bagged peaks over the accumulator, under the operator key. It does not prove when that accumulator state existed against a clock no operator runs. An OpenTimestamps proof over the bagged-peak root is an existence witness with a trust root nobody runs, verifiable offline alongside veracity.

Demonstrated on an MMR(39) accumulator built from the MMRIVER reference construction (spec test vector, peaks at 1-based 30, 37, 38):

• accumulator sha256 0a3f00d3ffdbf0d2d8900814e5463931b951231289e2f9be38c0ad1fc9a99d2c
• OpenTimestamps proof confirmed in Bitcoin block 957403, verify offline with the stock ots client

Scope: existence and ordering at a time only. Not consistency, not append-only. It complements the seal, it does not replace it.

The .ots and verifiers are ready, and the same anchor re-runs unchanged over a live forestrie checkpoint. Tell me where this does not compose with the MMR model.

[robinbryce]

https://github.com/forestrie/univocity

And also https://github.com/forestrie/veracity if you want to raise a pr with any changes

[MarkovianProtocol]

Robin,

Taking the veracity door. Univocity is the consistency and non-equivocation layer, that is the seal's job and the on-chain receipt's job. The existence anchor sits beside them, so it belongs in the verifier.

The change is small and read only. A subcommand that resolves the canonical bagged-peaks accumulator root in the exact preimage form you already bag, verifies an OpenTimestamps proof over that root, and reports the Bitcoin block the state provably existed before. It reuses the checkpoint plumbing and mmr.Peaks bagging already there, and asserts the stamped digest equals the checkpoint root, so nobody can anchor a different state and call it the log.

Scope stays honest. Existence and ordering against a clock no operator runs. Not consistency, not append-only. It complements the seal, it does not replace it.

PR lands as: a veracity accumulator-root command, an examples/bitcoin-anchor.sh using the stock ots client, a README section, and a test pinned to the MMR(39) vector from the issue, block 957403.

One decision sets the shape. OTS verification in-process, or shelling to the stock ots client within veracity's dependency budget. Say which way it leans and the PR follows.

Colin