Bitcoin Forum
July 15, 2026, 07:22:30 AM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [Tech] Timestamping AI forecasts with OpenTimestamps — pipeline + open verify sc  (Read 15 times)
neuportal (OP)
Newbie
*
Offline

Activity: 1
Merit: 0


View Profile
July 13, 2026, 11:58:46 AM
 #1

Sharing the technical setup we use to make forecast *timing* independently
verifiable, and inviting scrutiny of the pipeline. Not an announcement, no token —
just a proof-of-existence workflow on OpenTimestamps + Bitcoin.

Problem: a forecast only means something if you can prove it existed, unchanged,
before the event it predicts. Internal timestamps (DB rows, file mtimes, log
lines) are trivially editable by the party that benefits. We wanted timing that
nobody — including us — can backdate.

Pipeline:
1. Serialize each forecast to a canonical JSON record (inputs, probability, target
   event, cutoff time). Canonicalization matters: stable key order + fixed
   encoding so the hash is reproducible.
2. SHA-256 the record locally. Only the 32-byte digest leaves the machine.
3. Submit the digest to OpenTimestamps public calendar servers. They aggregate
   many digests into a Merkle tree and anchor the root in one Bitcoin tx (one tx
   timestamps the whole batch — that's why it's free).
4. Store the returned .ots proof next to the record; it holds the Merkle path from
   our leaf digest up to the anchored root.
5. After the anchoring tx confirms, upgrade the .ots so the proof is complete and
   self-contained (no dependence on the calendar server staying online).

Verification (anyone, no account):
    ots verify forecast.json.ots -f forecast.json
The client recomputes the digest, walks the Merkle path to the Bitcoin tx, and
reads the block timestamp. Change one byte and the digest won't match —
verification fails. If it passes: "existed as of block N."

Open artifacts:
- Proofs repo (records + .ots files): github.com/neuportalai-ui/experiment-proofs
- Archived dataset, citable DOI: 10.5281/zenodo.21294229

The forecasts themselves are locked before the event, then scored publicly with a
Brier score against prediction-market prices frozen at the same instant — losses
kept on the board, because a record that only shows wins proves nothing.

Feedback I'd genuinely want:
- Canonical JSON: we control the encoder, but is there a more portable canonical
  form you'd trust for reproducible hashing across languages?
- Worth self-anchoring a daily Merkle root of all records as a fallback to the
  public calendars?
- Batching cadence vs. proof-freshness tradeoffs.

Educational content, not financial advice and not a betting tip. Happy to answer
technical questions on the OTS flow.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!