Skip to content

Releases: machine-native/chronology-protocol

v0.5.3 — Epoch 10: the first consumer

Choose a tag to compare

@parthod0x parthod0x released this 23 Oct 14:30
v0.5.3

The first epoch whose record was produced by a party that will pay for the anchor.
Two signed attestations from another system — real paid transaction-status records
on a public chain, system id NAXYTRA-ATTESTATION/1 — bound into a reality sandwich
and mined into block 1365.

The round trip, and why it needed two new scripts

Every earlier external binding ran in one script because the record was local. This
one is a round trip: the session opens here, the tag goes out, the other party signs
its records with the tag inside the signed bytes, and the digests come back. So
the ritual is now two halves — scripts/open_binding_session.py and
scripts/close_binding_session.py — and the closer refuses to re-mint anything: a
fresh B0 would orphan whatever the other party had already bound to the first tag.

Each digest was recomputed here from the public source's RFC 8785 form before
binding, and the tag confirmed inside each signed object. The bundle carries digests
only; the records' content never enters this repository.

B0            1364
records       2 (seq 0, seq 1), each its own EXTERNAL-RECORD/v1 blob
witnesses     five NTP operators, two exchanges each, every nonce echoed
checkpoint    epoch 10, chained to epoch 9
C             1365, found on round 1
burial        2 at assembly (the chain stands at 1368)
verdict       SANDWICH_PASS
bundle        vectors/valid/naxytra-binding-bundle.cbor
              sha256 dc14bc557abc666288950220ff2117012dd9a90106434a404735f012010947a5
OTS           .ots stamped at four calendars, pending Bitcoin attestation

A decision recorded rather than made quietly

With the laboratory VM idle for two days, publishing at burial depth 0 was
considered and a dry run assembled. The verifier returned SANDWICH_PASS_UNBURIED
— the binding held, but depth is fixed inside the bundle bytes, so the artifact would
have read UNBURIED permanently while every other shipped epoch reads
SANDWICH_PASS. Held for two blocks instead. That is why the verifier has a named
verdict for the case: so the choice is visible, not silent.

Epoch 9

Not in this repository. It was bound through this protocol by a downstream
repository that records its own binding. This repository does not list its
consumers, so the table in the README goes 8 → 10, and says so.

Also in this release

capture_retarget.py --refresh now restamps the one manifest line it changes, so a
refresh-then-verify no longer reports a false FAIL (v0.5.1-era defect, mine). A
second round-trip session is open for a different system id and its first record is
verified and closed as epoch 11, awaiting burial; it publishes separately.

Not claimed

That the other system's records are meaningful — the sandwich bounds a digest in
time, and whether the record it names is true is that system's question. That the
OTS proof is attested — it is pending. Operator diversity on the anchor chain.

v0.5.2 — Galileo satellite signals inside an anchored epoch

Choose a tag to compare

@parthod0x parthod0x released this 01 Oct 16:43
v0.5.2

Epoch 8: a record bounded from both sides, by two parties neither of which is this project

Epoch 8 (block 1270, B0 at 1269) commits a 17-minute capture of Galileo E1-B
navigation pages, 12,574 frames relayed by the public galmon network, recorded
after B0. Five NTP operators witness the session on the same challenge (verdict
CONSENSUS); the checkpoint chains to epoch 7. Bundle:
vectors/valid/galileo-binding-bundle.cbor, buried 2 blocks at assembly; the
capture itself ships as live/galileo-bind-work/galileo-capture.bert.

The capture cannot carry the binding tag -- its bytes are the satellites' -- so
verify_binding() reports UPPER_ONLY, and a new test pins that it must. The
lower bound comes from Galileo's navigation-message authentication: a signing key
kept secret until its 30-second sub-frame, verified offline under the published
trust anchor, puts the capture no earlier than GST week 1414, 400380 s. That check
lives in time-witness, which
takes this bundle and the capture and reports GALILEO_BOUND:

Galileo key release  <  capture  <  block 1270  (< burial)

The ritual is scripts/run_galileo_binding.py (--open, capture, --close), the
same steps as epochs 5-7 with the record supplied rather than built.

capture_retarget.py --refresh leaves the manifest consistent

Refreshing the chain dump rewrote a tracked file and left the root manifest
failing its own check. --refresh now restamps only that one manifest line; the
frozen live/MANIFEST-live.sha256 is deliberately untouched.

Evidence types implemented elsewhere

verify_sandwich accepts extensions: verifiers for evidence types this repository
does not implement, supplied by the caller (--extension MODULE:NAME on the command
line). A witness profile maintained in another repository can now sit in a sandwich
and be checked by this verifier plus its own extension, while everything this
repository owns about that evidence — binding, signatures, chain, checkpoint,
anchoring — is still checked here. See docs/REALITY-SANDWICH.md §4b.

One behaviour changes, deliberately. Evidence of a type nobody here implements used to
make the verdict FAIL. It is now NOT_CHECKED and the verdict
INDETERMINATE_UNCHECKED_EVIDENCE, because the evidence was not checked, not checked
and found wanting — the same distinction the toolchain verdict already draws. The new
state ranks below FAIL, so it cannot soften a bundle that fails for any other
reason; a test pins exactly that. Every shipped bundle verifies to the verdict it had
before.

Seven tests in tests/test_sandwich_extensions.py cover this, using a stand-in
evidence type so they depend on nothing outside this repository.

Tests: 127.

v0.5.1 — Identifying strings out, claims brought to what the evidence supports

Choose a tag to compare

@parthod0x parthod0x released this 27 Sep 13:10

A housekeeping release in the sense that no new evidence was gathered, and not one in
the sense that it corrects three public claims that were stronger than the record.

The claims, corrected

"Independent miners" were two machines run by one operator. The chain has been
mined from a laboratory VM and from a second machine; both are ours. Sealed acceptance
records said otherwise in three places — "a party outside that VM … a first for this
chain beyond its own operator"
, and twice "that same independent miner".

Those records are named by digest in live/MANIFEST-live.sha256 and are not edited.
The corrections sit beside them in live/anchor-evidence/CORRECTIONS.md, with the
sealed sentence quoted and the corrected reading given. Operator diversity remains
something this record does not have
, and the one thing it most needs.

A third: "classic protocol dead everywhere" becomes not served by any of the four
endpoints tried
— nothing was established about endpoints that were not tried.

The anchor chain is named for what it is at first mention in the README: the
laboratory's experimental Bitcoin (2026), its own genesis, difficulty 1, mined by this
project, not the public network and not money. The only proof-of-work in this record
produced by anyone outside the project is the public-Bitcoin work behind the
OpenTimestamps attestations, and the README now says so in as many words.

Identifying strings removed from the live records

Local filesystem paths, two residential addresses, a host name, a machine name, adapter
models, private and public network addresses, and two country names are replaced by
placeholders across seventeen files.

Every replacement is listed in live/REDACTIONS.md with the digest as captured and
the digest after
. The capture-time digests in live/MANIFEST-live.sha256 and in
ACCEPTANCE.md are left exactly as written — a manifest regenerated after the fact
stops being a record of the capture, which is the whole reason it exists. INTEGRITY.md
states the present seal count (44 of 59) and which classes of file moved.

Nothing else in those files changed: not a hash, not a timestamp, not a measurement, not
a verdict. The binding scripts now take sibling checkouts from an environment variable
rather than absolute paths, so the paths cannot come back.

The instrument behind the rail measurement

live/lora-experiment/01-rail-measurements.json recorded the pre-wiring check — the
step with no undo, where 5 V on the wrong pin destroys an RYLR998 — as taken with a
"handheld multimeter". That is unattributable: a reader cannot judge whether 3.369 V
carries three meaningful decimals without knowing the instrument.

It is a Themisto TH-M100 AC/DC True RMS digital multimeter, 6000 counts, 10 A,
CAT III 600 V
. At 6000 counts a 6 V range resolves 1 mV, so three decimals sit inside
its resolution.

How that is known is recorded with it, because it matters: the meter was identified
from photographs taken on 2026-09-27, three weeks after the measurement, and confirmed
by the operator. Nothing recorded at the bench on 2026-09-06 names it. No reading,
verdict or timestamp changed.

The same photographs corroborate the two header orders the experiment depended on —
DTR·RXD·TXD·+5V·GND·3V3 on the CP2102 and GND·TXD·RXD·RST·VDD on the RYLR998 —
which until now rested only on the note that recorded them.

Hygiene

MANIFEST.sha256 covers every tracked file and is checked two ways: by
verify_all.py, which now reports 13 checks, and by a test that fails if a tracked
file is missing from it. CITATION.cff for citation; THIRD-PARTY.md naming a URL and
licence for each reused item; origin headers on the embedded SHA-256 page, the
Digilent-derived constraints and the Roughtime key.

Still not claimed

Operator diversity. Correct absolute mass from the PM sensors —
reference-comparison/pm-mass remains NOT_RUN for want of a reference instrument.
More than one outside verifier. And now stated explicitly: of the two particulate
sensors, only one has an identity read from its own label; the other is identified
by which port it was plugged into, which would not survive the two being swapped.

v0.5.0 — Four more epochs, a block moved by radio, and one command to check it all

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

The largest release since the protocol went public, and the first in which most of the
evidence comes from physical instruments rather than from the protocol exercising
itself.

Four new anchors

epoch 4   height 322   a rolling code proving ELAPSED TIME, not merely an instant
epoch 5   height 479   a record from another system given a checkable time bound
epoch 6   height 530   115 real air measurements bound to proof-of-work
epoch 7   height 628   958 observations, SANDWICH_PASS, buried 104 blocks deep

Epoch 4 is the first upgrade to the camera witness since epoch 2. A handwritten
challenge proves photographs came after B0 and nothing more — one code is one
instant. A code changing every ten seconds, captured across 19 distinct slots, also
proves the frames span real elapsed time. 41 frames, 29 carrying codes.

Epochs 5 and 6 exercise docs/EXTERNAL-BINDING.md: a record produced elsewhere
obtains a time bound only if the binding tag travels into the other system. Building
the second binding exposed that verify_sandwich did not recognise its own new
evidence type, so both bindings initially failed their own verifier. Recorded here
rather than quietly repaired.

Epoch 7 carries two PMS7003 particulate sensors and a BME280. The bridge forwards
raw frames and raw ADC counts and interprets nothing, so every published value stays
recomputable by a reader who distrusts the arithmetic.

Experiment 1 — a block crossed a room by radio, and could not have arrived any other way

The weak form of this experiment is "a file moved between two machines with radios
attached", to which the honest objection is: how do you know it did not go over the
network, or was already there? The design makes that objection physically
impossible
rather than answering it.

15:54:06Z   receiver air-gapped; isolation RECORDED, not asserted
16:12:05Z   block 732 mined -- EIGHTEEN MINUTES LATER
16:14:59Z   transmitted: 306 bytes, 3 CHRB fragments, 3 passes, 9 sends, 0 lost
            13.7 m, a cement wall, a wooden door, a cupboard
            RSSI -52..-61 dBm, SNR 8-9 dB, complete on the first pass
16:21:06Z   receiver validates proof-of-work LOCALLY, still offline
16:23:17Z   reconnected; receiver queries the chain ITSELF: tip 732, hash identical

The block did not exist anywhere when the receiver lost its connection, so it cannot
have been pre-staged, cached or synced. The received file's SHA-256 matches on both
machines. RADIO-RELAY.md no longer says the driver is untested on hardware.

Records: live/lora-experiment/ (nine JSON evidence files).

One command, three outcomes

scripts/verify_all.py runs every check in VERIFY.md and prints a single verdict:
toolchain, test suite, two plain bundles, seven sandwich bundles, and attestation
confirmation. 12 checks, all PASS.

Three outcomes, never two — PASS, FAIL, INDETERMINATE, exit 0/1/2 — and the third
is exercised rather than assumed: --skip-network reports 11 passed, 0 failed, 1 could
not be checked, and says plainly that nothing failing is not the same as success.

That distinction is not decoration. Outside review found this project's verifier
reporting FAIL where it should have said INDETERMINATE_TOOLCHAIN — implying the
evidence was bad when only the toolchain was too old. It was the most serious defect
outside review has found, and it is not being reintroduced in the tool built to
summarise everything.

Attestations, and an omission that was invisible by construction

scripts/confirm_attestations.py checks every .ots against a public block explorer.
21 attestations across 13 distinct blocks, all confirmed. The script ships, so the
count can be repeated rather than trusted.

Writing it found that the upgraded proofs had never been committed: the public
repository advertised fifteen attestations while holding twenty-one. Upgrades
only ever add evidence, which is exactly why the omission produced no symptom. A count
that can only be too low is still a count nobody can check.

Independent verification — closed, on the second attempt, under a stricter bar

A verification report was received, recorded, and withdrawn within hours when a
party in a position to be the verifier denied producing it. The failure was not that
the report was false; it was that its provenance was never established. Hashing a file
supplied by one party against a number supplied by the same party is circular.

The bar is now: the artifact identified by digest, commit and toolchain, and the
verifier publishing from somewhere they control. Closed 2026-08-22 by
issue #1 — a
non-collaborator who cloned at fc5933d, ran the offline suite, confirmed an
attestation against a public explorer, and stated their limits precisely.

They found three real defects in two days. Two are now enforced by tests.

One report is a start, not a consensus. More verifiers are still wanted, and mining
remains open: every block on this chain was mined by this project, so the next accepted
block belongs to whoever finds it.

Availability

A second seed now serves the chain from a different provider in a different
jurisdiction (docs/D2-SECOND-SEED-RUNBOOK.md). This buys availability, not
independence
— both seeds are still ours, and a reader who distrusts this project
gains nothing from a second machine it also runs.

Not claimed

This release does not claim the sensors report correct absolute mass —
reference-comparison/pm-mass is honestly NOT_RUN and needs a reference instrument.
It does not claim LoRa is a practical distribution channel: three fragments for 306
bytes, a duty-cycled band and no back-channel are what they are. It does not claim more
than one outside party has verified anything.

The release gate could not run, and said something false while not running

scripts/release_audit.py is this project's own pre-release check. Preparing this
release found three things wrong with it.

It crashed on any machine without a C compiler. run() did not catch
FileNotFoundError, so a missing cc aborted the whole audit and discarded every
other step's result — no report was written at all. A gate that cannot run is not a
gate.

Once it could run, it would have called that missing compiler a failure. That is
the conflation this project treats as its most serious defect class: "could not check"
reported as "checked and failed" says the release is bad when nothing about it was
examined. The audit now has three outcomes and exits 0/1/2 like every other verifier
here, and prints what was not asked and why.

And its report asserted live_anchor_claimed: false with a status of
RELEASE_CANDIDATE_PASS_PRE_POW — both hardcoded, and both untrue since v0.1.1. Seven
epochs are anchored. The field is now read from the evidence on disk, and the version
comes from the tags rather than a constant that nobody remembered to bump.

A guard for the front page

The README's attestation tally was written from an internal status note that had gone
stale — it said 21 attestations across 13 blocks while the proofs on disk carried 25
across 17. VERIFY.md was already protected by a test that parses the .ots files
themselves; the README, which is what a stranger reads first, was not. It is now.

An understatement is still a number nobody can check, and this is the second time a
stale attestation count has been found in a published document.

v0.4.1 — The first chain reorganization, survived (2026-08-21)

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

The height-264 anchor published in v0.4.0 was orphaned. It carried valid
difficulty-1 work and the public seed advertised it as its tip, but the laboratory's
miner produced a competing block at the same height and extended it — two blocks beat
one, and our block left the active chain. This is the anchor chain's first
reorganization, and the direct consequence of it having had two independent miners
since 2026-08-19.

orphaned   0000000032580c2f…  height 264   valid PoW, briefly the tip, now an orphan
re-anchor  000000001a5380c4c618b2fd2dc4a8768e5cd807cf3122a24ce2fc4c548dc112
           height 269, nNonce 796895470
window     B0 263  ≺  acquisition  ≺  C 269      (six blocks, not adjacent)
verdict    SANDWICH_PASS — all checks true, buried 3 deep
bundle     vectors/valid/roughtime-sandwich-bundle.cbor
           sha256 bf22c1586a2dff27…

Nothing in the evidence depended on which block won. The acquisition, every
Ed25519 and post-quantum signature, and the epoch-3 checkpoint are byte-identical to
what v0.4.0 published; only the anchor's identity changed. Re-anchoring meant mining
the same checkpoint payload onto the new tip, which widened the causal window and
left both bounds intact — and the verifier proves it rather than asserting it:
S_LINKAGE_B0_TO_C now walks the five intervening blocks (the winning 264 and its
265–268) to establish the unbroken path from B0 to the new anchor.

This is the construction's first encounter with a chain reorganization, and it
behaved as designed
: a wider window, no lost evidence, every claim re-verified. The
orphaned block's bytes are preserved in live/anchor-evidence/orphans/ and the v0.4.0
release note above is left standing with a pointer to the correction — a claim that
quietly disappears teaches a reader nothing.

The laboratory's own record of the event, written from the chain bytes rather than from
this project's perspective, is in the original-bitcoin-laboratory genesis repository
under bitcoin-findings/2026-08-21-first-reorganization/.

v0.4.0 — Authenticated time witnesses (2026-08-21)

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

The lower causal bound becomes cryptographic. Under the NTP profile a server
echoes the challenge-derived nonce; under the new ROUGHTIME/v1 profile the server
Ed25519-signs a Merkle root containing it. Epoch 3 puts both classes in one
checkpoint: two signed Roughtime witnesses (Cloudflare, txryan) beside the five NTP
witnesses, consensus q=3 of 7, anchored at height 264 with parent = B0 — the fourth
consecutive adjacent-block causal window, won on the first attempt.

B0 263  ≺  signed acquisition 06:17 UTC  ≺  C 264 (epoch 3)
bundle   vectors/valid/roughtime-sandwich-bundle.cbor
verdict  SANDWICH_PASS_UNBURIED — all checks incl. S_ROUGHTIME_SIGNATURES;
         burial depth 0 at publication (the laboratory miner had not yet
         extended the chain; its gaps run 6-184 min). Re-running
         scripts/assemble_g5_bundle.py records burial when it lands.

⚠️ Superseded by v0.4.1: the height-264 anchor above was orphaned. The block
was real and briefly the tip, but lost a chain race. The claim is left standing
here with this pointer rather than edited away; the corrected anchor and the full
account are in v0.4.1 below and in
live/anchor-evidence/ROUGHTIME-SANDWICH-ACCEPTANCE.md.

New in this release:

  • ctp/roughtime.py — IETF-draft Roughtime client and complete offline verifier:
    challenge-derived nonce, Merkle inclusion, response signature, delegation
    signature against pinned long-term keys, delegation-window containment. Ed25519
    through the OpenSSL CLI, so no new Python dependencies. Every wire constant was
    pinned empirically against live servers before being hard-coded.
  • scripts/run_g5.py, scripts/assemble_g5_bundle.py, tests/test_roughtime.py
    (synthetic round-trip with four tamper cases). Suite: 29 tests.
  • scripts/ots_upgrade.py (from v0.3.1) and the normative profile in
    docs/REALITY-SANDWICH.md §3b, including the honest precision trade: signed
    evidence is currently ±2–4 s against NTP's ±30–200 ms.

Record: live/anchor-evidence/ROUGHTIME-SANDWICH-ACCEPTANCE.md.
The epoch chain now reads 0 → 1 → 2 → 3, every link committed into proof-of-work.


v0.3.0 — The first astronomical ChronologyProof (2026-08-21)

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

Sandwich v2: a real optical observation of the sky, inside the causal bounds. On
the evening of 2026-08-20 the operator photographed the gibbous Moon over New Delhi
with a fresh challenge code — the first 16 hex digits of q, derived from block 252's
hash five minutes earlier — handwritten on paper inside the frames. Ten original
frames (EXIF intact, sha256-manifested) became a CAMERA-PHOTO/v1 witness beside
five fresh NTP witnesses in the epoch-2 checkpoint, chained to epochs 1 and 0, mined
into height 253 (parent = B0: an adjacent-block causal window again) and buried by
ten overnight laboratory blocks.

B0 252  ≺  photos 15:24 UTC (code in frame)  ≺  C 253  ≺  254…263
bundle   vectors/valid/astro-sandwich-bundle.cbor
         sha256 32ec9b4eeb00906bc5d27ec5ddd7573ee7a25aef5ded69e8469bf9977636bcfc
verdict  SANDWICH_PASS — all checks, incl. S_CAMERA_BINDING and S_PHOTO_FILES

The bundle carries the open-astrolabe engine's expectation for the capture instant —
Moon at SW 216.6°, altitude 24.0°, 55.2% illuminated, reference grade — as
prediction_json, labeled EXPECTATION_NOT_EVIDENCE. The frames show exactly that.
The prediction-vs-photo comparison is human-verifiable by design in this profile;
a plate-solved astrometric residual is named future work, not claimed. Full record:
live/anchor-evidence/ASTRO-SANDWICH-ACCEPTANCE.md;
normative profile: docs/REALITY-SANDWICH.md §6. Suite: 27 tests.


v0.2.1 — Cross-checked expectation, corrected constant, real-Bitcoin sidecar anchors (2026-08-19)

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

A cross-check did its job, and the error is stated rather than buried. The
astrolabe-engine (an independent celestial-model implementation whose Sun/Moon
positions carry its own reference grade, 10″, validated against JPL Horizons and
IMCCE; cited by name, version and commit in the bundle) was run against
the sandwich's consensus instant. Its GAST disagreed with the bundle's stored ERA by
~100°: the v0.2.0 integer implementation had ERA_A_NANO a factor of 1000 too large
(pico-turns written as nano-turns). Corrected, the two now agree to the physics:
engine GAST 140.0929°, bundle ERA 139.7493°, difference +0.3436° = the equation of
origins. A float-reference regression test pins this forever (suite: 26).

  • vectors/valid/reality-sandwich-bundle.cbor re-assembled with the corrected
    expectation (only the labeled EXPECTATION_NOT_EVIDENCE field changed; every
    signed observation, checkpoint, and block byte is identical):
    sha256 61d409059c8ccb89…, verdict SANDWICH_PASS, burial 2 at assembly.
  • live/anchor-evidence/astrolabe-expectation.json — the engine's own prediction
    for the consensus instant (GAST, Sun, Moon, with the engine's declared grades),
    produced by consuming its public surface only. Still an expectation, never evidence.
  • External anchor sidecars: standard OpenTimestamps proofs for all three evidence
    bundles (vectors/valid/*.cbor.ots, via scripts/ots_stamp.py), submitted to two
    independent public calendars. These add an economically real upper causal bound on
    the same bytes from the public Bitcoin chain; pending attestations become Bitcoin
    block attestations after calendar aggregation (ots upgrade with any standard
    client). Two of four calendars were unreachable (expired TLS certificates on their
    side) — stated, and two independent attestations were obtained.

v0.2.0 — The reality sandwich (2026-08-19)

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

First real (non-simulated) evidence acquisition, causally sandwiched between live
proof-of-work blocks. Normative construction: docs/REALITY-SANDWICH.md.

B0  = 00000000fc80fe4f…  height 221   (the v0.1.1 live-anchor block itself)
        ≺  acquisition: 10 real NTPv4 exchanges, 5 independent operators
           (NIST, PTB, Google, Microsoft, Apple), challenge nonce embedded in
           every request and echoed by every server
        ≺
C   = 0000000055cddf6e…  height 222   (epoch-1 checkpoint payload, real difficulty-1 work)

New in this release:

  • ctp/sandwich.py — challenge/nonce derivation, NTP witness profile with
    deterministic measurement re-derivation from raw packets, declared-origin
    picosecond frames (SPEC §3), integer-only IAU-2000 ERA expectation
    (EXPECTATION_NOT_EVIDENCE), sandwich bundle format, and the offline verifier
  • scripts/run_sandwich.py / build_sandwich_template.py /
    assemble_sandwich_bundle.py / verify_sandwich.py
  • tests/test_sandwich.py — derivation vectors, measurement math, and a full
    synthetic sandwich round-trip with tamper cases (suite: 25 tests)
  • vectors/valid/reality-sandwich-bundle.cbor — the real sandwich, offline-verifiable

The epoch-1 checkpoint chains to the sealed epoch-0 checkpoint through its record
commitment. The consensus interval from the five witnesses is ±42 ms wide; the causal
window is one block on each side — the tightest this chain can express. The sandwich
proves when the evidence was acquired, never that its content is true; every
non-claim in the normative document applies.


v0.1.1 — Live anchor executed (2026-08-19)

Choose a tag to compare

@parthod0x parthod0x released this 06 Sep 22:56

The external gate declared above was completed on 2026-08-19. The sealed 96-byte CHRN
checkpoint payload was carried, byte-identical, in the coinbase of a really-mined
difficulty-1 block accepted as the active tip of the live laboratory chain:

block   00000000fc80fe4f27b59cafbf782f029f586151bd144115b3d5f1ee360d088b   height 221
chain   Bitcoin (2026), genesis 00000000ad12f3ec…   nNonce 2757362010

Evidence, in four independent forms — the operated seed's active chain, an independent
full-chain linkage re-verification, an unmodified released Jan09-derived client's own
acceptance log, and the bundle verifier's PASS verdict (all 13 checks true) — is in
live/anchor-evidence/ACCEPTANCE.md. The
live-anchored bundle is vectors/valid/evidence-bundle-live-anchored.cbor; the sealed
v0.1.0 bundle and MANIFEST.sha256 remain untouched, exactly as sealed.

Two earlier candidates with valid PoW lost their height races to the laboratory's own
miner and are disclosed in the acceptance record. PASS_LIVE_ANCHORED was reached by
adding mined-and-accepted reality to the sealed evidence, never by editing a verdict.