# Specification defect report — draft-fassbender-scitt-time-anchor-03

Scope: findings from an independent producer-side implementation,
built exclusively from the published document (see `README.md`).
Per the working rule of this exercise, any question whose answer
could not be justified by a citation of the published text is
recorded here rather than resolved by asking the author.

## D-01 — OTS-UPGRADE: NULL semantics admit two inconsistent readings

**Severity:** minor (Appendix D.1–D.3 are declared informative; no
proof's validity depends on it). **Type:** internal inconsistency /
ambiguity.

**The two readings.**

Section 1.4 defines:

> "OTS-UPGRADE(pending_proof) — contacts a Calendar Server and
> replaces a calendar-level commitment with a Bitcoin Merkle path,
> when available. Returns serialised .ots bytes, or NULL where no
> Bitcoin Merkle path is yet available."

Appendix D.2, step 2b, comments the NULL case as:

> "The calendar returned nothing new. Retry next cycle, unless the
> commitment has gone unanswered for so long that the submission is
> presumed lost."

Reading A (Section 1.4 literally): NULL if and only if the merged
proof carries no Bitcoin Merkle path. Reading B (step 2b's comment):
NULL when the calendar returned nothing new on this call.

**Why they diverge.**

Consider a proof that already carries a Bitcoin attestation but was
left `pending` by the confirmation-depth gate (step 2f: "Leave the
proof pending and retry next cycle") or by ledger unavailability
(step 2d). On the next cycle the calendar has nothing new to return.

- Under Reading B, OTS-UPGRADE returns NULL on every subsequent
  cycle; step 2b's age test eventually sets the proof to "failed".
  That contradicts Section 2.4.1, which defines "failed" as a proof
  "whose calendar commitment was never answered" — here the
  commitment *was* answered, and the proof carries a valid Bitcoin
  attestation awaiting depth.
- Under Reading A, that starvation cannot occur, but step 2c's
  branch — "Still calendar-only. Any additional calendar commitments
  merged by OTS-UPGRADE are persisted" — becomes unreachable: a
  merged proof still carrying no Bitcoin path would have returned
  NULL at 2a, so control never reaches 2c with merged calendar-only
  commitments to persist.

No single reading makes Section 1.4, step 2b, step 2c and
Section 2.4.1 simultaneously coherent as written.

**Resolution adopted in this implementation.**

OTS-UPGRADE returns serialised bytes when the merged proof carries at
least one Bitcoin attestation OR when anything was merged on this
call; NULL only when nothing changed and no Bitcoin path exists. This
is the only reading found under which every branch of D.2 is
reachable and the Section 2.4.1 definition of "failed" is preserved.

**Suggested clarification.**

State the return condition of OTS-UPGRADE once, in Section 1.4, in
terms of the merged proof's contents (e.g. the resolution above), and
align the step 2b comment with it; or alternatively have step 1
select on proof state rather than producer status, so that
already-attested proofs re-enter at step 2c directly.

---

No further entries. The two things the document does not specify —
the .ots serialisation format and the Calendar Server protocol — are
not defects: they are boundaries the document itself declares and
delegates to the pinned [OTS] release (Section 5.2.1; Appendix D,
preamble).