[ogasurfproject-jpg]

What and why

LIMITATIONS.md and ROADMAP.md list these as open:

• Checkpoint 2 has no witness receipt.
• Submission to witnesses is not automated.
• No receipt yet carries a signed witness time or a bound grade.
• A second witness and split-view monitoring are future work.

This PR adds an evidence packet, docs/evidence/witness-2026-10-20-nenrin/, with receipts from a second, independently operated witness for both checkpoints. It also adds tests/test_witness_receipt_nenrin.py, which checks them offline with tools/verify_witness_receipt.py.

	checkpoint 1	checkpoint 2
verified	true	true
grade_cryptographically_bound	true (mmr-verified)	true (mmr-verified)
witness_time_established	false: more than 30 days old when witnessed	true, iat 1792467378

Checkpoint 1 now has two witnesses, Action State and this one. As far as I know, checkpoint 2's receipt is the first under this registry where both limits read true.

The witness is HORIZON SHIELD (The HORIZONs Co., Ltd.), already a registered mirror. Its code is public: registry-witness-v0.

mmr-verified is signed only after the witness has done three things itself:

• run this registry's two chain checks (consistency proofs, and the MMR rebuilt from the raw entries) with trace-verify's own functions;
• pinned key bc133259…;
• confirmed that every checkpoint it signed before is still on the same line, byte for byte.

Receipts are final: one per checkpoint, never reissued. The witness log is RFC 9162, and its tree heads carry consistency proofs. The first tree head is anchored to Bitcoin through the JIDEC ledger.

The packet README states what this does not establish. In particular, two witnesses on one checkpoint are a start on split-view detection, not proof of it.

Two offers, for the maintainers to accept or not

1. Recurring witnessing. I can run this on every new checkpoint and open an evidence PR like this one. Later, if you prefer, it can be an endpoint compatible with tools/capture_witness_receipt.py (POST /checkpoints, GET /checkpoints/<log_id>, GET /v1/inclusion/<digest>).
2. Mirroring in both directions. We already mirror this registry. In return, would AgenTrust hold a mirror of the NENRIN/JIDEC ledger? It is one GitHub Action in a repository of yours (BECOME_A_MIRROR.md), with no server and no secrets. Each log would then be independently held by the other's operator.

Registry impact

• This PR does not modify any existing line under registry/

Checks

• python -m unittest discover -s tests: 414 tests pass locally (8 new)
• ruff check . passes
• tools/validate_registry.py passes; nothing under registry/ or producers/ changes
• Anchor format or verification semantics: unchanged
• Commits are signed off (DCO)

Disclosure: I also reported #591 on trace-spec, and HORIZON SHIELD works on adjacent verification tooling. The witness key is in witness-key.json. Its private half never leaves the operator's machine.

[imran-siddique]

Both receipts verify here: 7 of 7 checks each, output identical to verification-1.json and verification-2.json, and both checkpoints are byte-identical to line 1 of registry/2026/09/01.ndjson and 09/25.ndjson. 414 tests pass.

Three changes before merge. The witness key first appears in horizon-shield 65b0db6, 12 minutes before this PR, and the log holds only our two leaves, so the README should say that rather than "independent". The Bitcoin anchor has no proof in the packet: add it or drop the sentence. LIMITATIONS.md line 41 still says one checkpoint is witnessed.

[ogasurfproject-jpg]

@imran-siddique Thank you. All three are in 04f60f8:

1. The README no longer says independent. It says the witness key first appears in horizon-shield 65b0db6, 12 minutes before this PR, that the witness log holds only these two leaves, and that the same operator runs a registered mirror.
2. 2. The anchor is in the packet: jidec-127.txt (JIDEC ledger entry 127, which names the first tree head's line SHA-256 and the witness key) and jidec-127.txt.ots, attested at Bitcoin block 972264 (merkle root 81b695d0..., 2026-10-20 05:09:57 UTC). A new offline test checks the line hash, that the record names it, and that the proof commits to the record's SHA-256. Checking the header itself needs a node or an explorer, and the README says so.
3. 3. LIMITATIONS.md now describes both packets and says only one of the two witnesses has a track record.
      tests/test_witness_receipt_nenrin.py: 9 passed; ruff check . clean.

[dinakarjs]

Rechecked 04f60f8. The packet now discloses the witness/key's short history and common mirror operator, contains the JIDEC entry and OTS file, and updates LIMITATIONS.md. Both receipts verify offline with the documented distinction between signed grade, signed witness time and registry continuity. Nine packet tests pass; the full unittest discovery and Ruff also exit successfully in a fresh Python 3.12.14 environment installed from the three CI locks. The full run emits socket ResourceWarnings; these are not counted as failures.

Evidence boundary: test_bitcoin_anchor_chain_offline checks the record/head hashes, OTS file-digest prefix and presence of an attestation tag/height. It does not deserialize/evaluate the complete OTS operation path or authenticate the Bitcoin header. I have not independently checked that header, so I am not certifying the stated mainnet upper-bound time. A useful follow-up is a parsed operation-chain check plus a corrupted-operation negative, with header authenticity still a separate external check. The original maintainer's evidence acceptance/re-review remains open; receipt verification is not a split-view-monitoring claim.

[ogasurfproject-jpg]

@imran-siddique when you have time, could you take another look? Your three points from 20 October are all in 04f60f8:

1. README: "independent" is gone from the packet. A new section says the witness key first appears in horizon-shield 65b0db6, 12 minutes before this PR, that the witness log holds only these two leaves, and that the same operator runs a registered mirror.
2. Bitcoin anchor: the packet now carries jidec-127.txt and jidec-127.txt.ots. The proof attests at block 972264; its commitment equals that block's merkle root (81b695d0...) at blockstream.info. A new offline test checks the line hash, that the ledger entry names it, and that the proof commits to the entry's SHA-256.
3. LIMITATIONS.md: the paragraph now reads "Two checkpoints have witness receipts; one witness has a track record", and describes the second witness as above.

@dinakarjs rechecked 04f60f8 on 21 October: #143 (review)

[dinakarjs]

Completed the bounded operation-chain follow-up proposed in my review: dinakarjs#1. It is a one-commit author-adoption companion based on your exact 04f60f8 head, so it does not duplicate your upstream submission. Cherry-pick candidate: a973b0a.

Five new tests evaluate the captured SHA256/append/prepend operations and compare the resulting Bitcoin leaf with your reported root. A changed operand preserves the old digest/tag/height checks but changes the computed result. Full unittest discovery: 420 tests, OK; Ruff passes. Fixed-result, append-as-prepend and skip-hash mutations each cause two assertion failures, no errors. Small sibling-branch controls check the evaluator independently of this packet.

The helper is deliberately fixture-only, with bounded sizes/depth and unsupported operations refused. The README explicitly preserves the separate requirement to authenticate the Bitcoin header/chain; this is not independent confirmation of mainnet time. Please adopt if useful, or retain it as a follow-up after this packet is accepted. Your ownership and the original maintainer re-review remain unchanged.

[ogasurfproject-jpg]

@dinakarjs thank you for a973b0a: the five tests pass here against the 04f60f8 packet, changing the expected root makes the root test fail, and the root it computes is the one the opentimestamps library and blockstream.info give us for block 972264. While Imran's re-review is in progress on 04f60f8 we will keep this PR's head unchanged, and we will take your commit in, with your authorship, as a follow-up once the packet is accepted.

[rajnisht7]

All the earlier findings are addressed on 04f60f8, the README disclosure, the JIDEC/OTS files, and the LIMITATIONS update all look good.

however there is still one consistency issue:

docs/evidence/witness-2026-10-20-nenrin/jidec-127.txt still says HORIZON SHIELD “operates an independent witness” whereas updated README correctly states that nothing in the packet shows a track record or independence beyond a different operator and key, and LIMITATIONS.md was also updated accordingly. So the packet currently asserts both things at once.

This matters because jidec-127.txt is the exact document whose SHA-256 is committed by the OTS proof and listed in SHA256SUMS. The file itself also says it cannot be altered after anchoring and that corrections should be later entries. A simple wording edit would break the cryptographic linkage, so the characterisation needs to be reconciled in a way that preserves the anchor (e.g. a superseding JIDEC/OTS entry that cites this one, or another approach that keeps the packet internally consistent).

A couple of smaller notes (non blockers):

• ROADMAP.md still treats a second operator / continuous witnessing as future work. Worth bringing it in line with the new packet once the above is fixed.

• The offline Bitcoin test correctly checks the captured structure, commitment, tag and height, but does not evaluate the full OTS operation chain or authenticate the Bitcoin header. The README already documents that boundary, so this is fine as-is; the deeper operation-chain work can stay a follow-up.

[ogasurfproject-jpg]

@rajnisht7 thank you, that is a real inconsistency, and you are right that editing jidec-127.txt would break the anchor.

jidec-127.txt and its proof stay exactly as anchored. I have appended JIDEC entry 143 as a correction that cites entry 127 by title and claim SHA-256 (6d8ff0fb…). It replaces "operates an independent witness" with the README's wording: a second witness, a party other than the registry operator with its own key, with no track record or independence shown beyond that. Its proof is in the packet as jidec-143.txt and jidec-143.txt.ots (Bitcoin block 972850), and SHA256SUMS and the README now list both entries.

ROADMAP.md now says that a second operator has receipts for checkpoints 1 and 2, taken by hand, and that continuous submission and split-view monitoring remain open.

The offline Bitcoin test is unchanged, as you suggested; the full OTS operation chain stays a follow-up.

Commit: 7aec547

[rajnisht7]

Thank you for addressing the issue, a couple of things still needs addressed:

• jidec-143.txt says “stamped to Bitcoin block 972264”, but jidec-143.txt.ots actually attests block 972850 (confirmed with ots info). README also says 972850. Since the document is already anchored, this needs another append-only correction rather than editing the file.
• test_bitcoin_anchor_chain_offline still only checks jidec-127.txt / .ots, it will be good to add the same offline structural checks for jidec-143 (SHA-256 matches manifest, OTS commits to that digest, expected attestation / height 972850). Full OTS chain validation can stay a follow-up.
• ROADMAP still says receipt-bound witness time/grade is future work and that “the captured receipt authenticates a root, not the response’s grade or an observation time.” Checkpoint 2 in this packet has both grade_cryptographically_bound and witness_time_established true. LIMITATIONS already explains the distinction, kindly soften the ROADMAP wording so it doesn’t imply the capability doesn’t exist.
• non-blocking: test_reported_grade_must_match_the_signed_one currently tests the opposite