@forestrie/receipt-verify 0.8.0 → 0.8.2

package/dist/freshen-receipt.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"freshen-receipt.d.ts","sourceRoot":"","sources":["../src/freshen-receipt.ts"],"names":[],"mappings":"AA+CA,OAAO,EAEL,KAAK,0BAA0B,EAChC,MAAM,uBAAuB,CAAC;AAI/B,MAAM,MAAM,mBAAmB,GAAG;IAChC,iEAAiE;IACjE,eAAe,EAAE,UAAU,CAAC;IAC5B;uEACmE;IACnE,SAAS,EAAE,UAAU,CAAC;IACtB;;mFAE+E;IAC/E,iBAAiB,EAAE,SAAS,0BAA0B,EAAE,CAAC;IACzD;iEAC6D;IAC7D,eAAe,CAAC,EAAE,UAAU,EAAE,CAAC;IAC/B;wDACoD;IACpD,qBAAqB,EAAE,UAAU,CAAC;CACnC,CAAC;AAEF,MAAM,MAAM,oBAAoB,GAAG;IACjC,wEAAwE;IACxE,OAAO,EAAE,UAAU,CAAC;IACpB,wDAAwD;IACxD,UAAU,EAAE,MAAM,CAAC;CACpB,CAAC;AASF;;;;;GAKG;AACH,wBAAsB,cAAc,CAClC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,oBAAoB,CAAC,CAmJ/B"}
+{"version":3,"file":"freshen-receipt.d.ts","sourceRoot":"","sources":["../src/freshen-receipt.ts"],"names":[],"mappings":"AAyDA,OAAO,EAEL,KAAK,0BAA0B,EAChC,MAAM,uBAAuB,CAAC;AAI/B,MAAM,MAAM,mBAAmB,GAAG;IAChC,iEAAiE;IACjE,eAAe,EAAE,UAAU,CAAC;IAC5B;uEACmE;IACnE,SAAS,EAAE,UAAU,CAAC;IACtB;;mFAE+E;IAC/E,iBAAiB,EAAE,SAAS,0BAA0B,EAAE,CAAC;IACzD;iEAC6D;IAC7D,eAAe,CAAC,EAAE,UAAU,EAAE,CAAC;IAC/B;wDACoD;IACpD,qBAAqB,EAAE,UAAU,CAAC;CACnC,CAAC;AAEF,MAAM,MAAM,oBAAoB,GAAG;IACjC,wEAAwE;IACxE,OAAO,EAAE,UAAU,CAAC;IACpB,wDAAwD;IACxD,UAAU,EAAE,MAAM,CAAC;CACpB,CAAC;AASF;;;;;GAKG;AACH,wBAAsB,cAAc,CAClC,KAAK,EAAE,mBAAmB,GACzB,OAAO,CAAC,oBAAoB,CAAC,CAyJ/B"}

package/dist/freshen-receipt.js

@@ -3,23 +3,33 @@
  *
  * A receipt goes stale when log growth buries the peak it commits to. Freshening
  * re-anchors it to the CURRENT sealed state without tiles: extend the leaf's
- * inclusion path from its old peak up to the latest accumulator using the
+ * inclusion path from its old peak up to the current accumulator using the
  * checkpoint chain's consistency proofs (the tile-free source of the climb
  * nodes), then attach that fresh path at header 396 to the LATEST checkpoint's
- * pre-signed peak receipt. The result is a native receipt that verifies with
- * plain `verify --genesis` against the current state — the latest checkpoint
- * carries the genesis-verifiable delegation cert (see plan-2607-32's Phase 3
- * finding: the calldata provider supplies the climb material tile-free, but the
- * signature/cert comes from the latest `.sth`).
+ * pre-signed peak receipt. The result is a native receipt about the current
+ * state (the calldata provider supplies the climb material tile-free, but the
+ * signature/cert always comes from a latest `.sth`; plan-2607-32 Phase 3).
  *
- * Trust note: the freshened receipt is defined SOLELY by the latest checkpoint —
- * its label-1000 delegation cert and its pre-signed peak receipt. Owner-rooting
- * is established by the verify step's trust anchor: `verify --genesis` rejects a
- * cert whose delegator is not the genesis owner (a hard failure, not a warning).
- * A rotation of the delegated-TO sealer key is routine and within the owner's
- * authority, so freshen does NOT flag it — there is no signer-change gate (this
- * supersedes the earlier `--allow-new-signer` sketch; see the plan-2607-32 F2
- * note). The old receipt's cert is irrelevant to the emitted artifact.
+ * Trust note — three orthogonal concerns (see forestrie-cli's TRUST-MODEL.md):
+ *  - FRESHNESS is what freshen produces: the extended path recomputes the
+ *    current accumulator peak (self-checked below); a caller may additionally
+ *    bind that accumulator to a trusted chain read. This is the receipt's
+ *    substance.
+ *  - SEALING attestation: the emitted receipt necessarily carries the LATEST
+ *    checkpoint's signature — its label-1000 owner→sealer delegation cert and
+ *    pre-signed peak receipt. A freshened receipt is a NEW attestation of the
+ *    current state, so the only signature it can carry is one over a checkpoint
+ *    at the current size; attaching any other would be forgery. A rotation of
+ *    the delegated-TO sealer key is routine and within the owner's authority, so
+ *    freshen does NOT flag it — there is no signer-change gate (this supersedes
+ *    the earlier `--allow-new-signer` sketch; plan-2607-32 F2). The old receipt's
+ *    cert is irrelevant to the emitted artifact.
+ *  - AUTHORITY (does the log chain to genesis) is NOT carried by this signature
+ *    and NOT freshen's concern: it is the grant hierarchy, proven by grants + their
+ *    inclusion proofs (and enforced on-chain at publish). Downstream `verify`
+ *    picks the posture — `--genesis`/`--known-log-key` check the sealer chains to
+ *    the owner; the accumulator rungs check freshness directly and treat the
+ *    signature as vestigial.
  *
  * Two independent fail-closed guards keep a bad assembly from ever minting:
  *  - Cross-checks against the checkpoint being borrowed from: the supplied
@@ -138,6 +148,13 @@ export async function freshenReceipt(input) {
         store.set(fullIndices[k], oldPath[k]);
     }
     for (const link of links) {
+        // A base-0 link (treeSize1 === 0) has no from-peaks to climb — a 0→N
+        // consistency proof carries `paths: []` (the whole accumulator is its
+        // right-peaks). Skip it: it contributes no store nodes, and calling
+        // `peakMMRIndexes(-1n)` would throw (`posHeight(0)`, FOR-414). A genesis-
+        // rooted `.sth` chain always starts with such a link.
+        if (link.treeSize1 === 0n)
+            continue;
         const fromPeaks = peakMMRIndexes(link.treeSize1 - 1n);
         fromPeaks.forEach((peakIndex, j) => {
             const climb = link.paths[j];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@forestrie/receipt-verify",
-  "version": "0.8.0",
+  "version": "0.8.2",
   "license": "MIT",
   "type": "module",
   "description": "Offline SCITT grant receipt verification (ADR-0045)",
@@ -28,8 +28,8 @@
   ],
   "dependencies": {
     "@noble/hashes": "^1.7.1",
-    "@forestrie/encoding": "0.5.0",
-    "@forestrie/merklelog": "0.3.0"
+    "@forestrie/merklelog": "0.3.0",
+    "@forestrie/encoding": "0.5.0"
   },
   "devDependencies": {
     "esbuild": "^0.24.0",

package/src/freshen-receipt.ts

@@ -3,23 +3,33 @@
  *
  * A receipt goes stale when log growth buries the peak it commits to. Freshening
  * re-anchors it to the CURRENT sealed state without tiles: extend the leaf's
- * inclusion path from its old peak up to the latest accumulator using the
+ * inclusion path from its old peak up to the current accumulator using the
  * checkpoint chain's consistency proofs (the tile-free source of the climb
  * nodes), then attach that fresh path at header 396 to the LATEST checkpoint's
- * pre-signed peak receipt. The result is a native receipt that verifies with
- * plain `verify --genesis` against the current state — the latest checkpoint
- * carries the genesis-verifiable delegation cert (see plan-2607-32's Phase 3
- * finding: the calldata provider supplies the climb material tile-free, but the
- * signature/cert comes from the latest `.sth`).
+ * pre-signed peak receipt. The result is a native receipt about the current
+ * state (the calldata provider supplies the climb material tile-free, but the
+ * signature/cert always comes from a latest `.sth`; plan-2607-32 Phase 3).
  *
- * Trust note: the freshened receipt is defined SOLELY by the latest checkpoint —
- * its label-1000 delegation cert and its pre-signed peak receipt. Owner-rooting
- * is established by the verify step's trust anchor: `verify --genesis` rejects a
- * cert whose delegator is not the genesis owner (a hard failure, not a warning).
- * A rotation of the delegated-TO sealer key is routine and within the owner's
- * authority, so freshen does NOT flag it — there is no signer-change gate (this
- * supersedes the earlier `--allow-new-signer` sketch; see the plan-2607-32 F2
- * note). The old receipt's cert is irrelevant to the emitted artifact.
+ * Trust note — three orthogonal concerns (see forestrie-cli's TRUST-MODEL.md):
+ *  - FRESHNESS is what freshen produces: the extended path recomputes the
+ *    current accumulator peak (self-checked below); a caller may additionally
+ *    bind that accumulator to a trusted chain read. This is the receipt's
+ *    substance.
+ *  - SEALING attestation: the emitted receipt necessarily carries the LATEST
+ *    checkpoint's signature — its label-1000 owner→sealer delegation cert and
+ *    pre-signed peak receipt. A freshened receipt is a NEW attestation of the
+ *    current state, so the only signature it can carry is one over a checkpoint
+ *    at the current size; attaching any other would be forgery. A rotation of
+ *    the delegated-TO sealer key is routine and within the owner's authority, so
+ *    freshen does NOT flag it — there is no signer-change gate (this supersedes
+ *    the earlier `--allow-new-signer` sketch; plan-2607-32 F2). The old receipt's
+ *    cert is irrelevant to the emitted artifact.
+ *  - AUTHORITY (does the log chain to genesis) is NOT carried by this signature
+ *    and NOT freshen's concern: it is the grant hierarchy, proven by grants + their
+ *    inclusion proofs (and enforced on-chain at publish). Downstream `verify`
+ *    picks the posture — `--genesis`/`--known-log-key` check the sealer chains to
+ *    the owner; the accumulator rungs check freshness directly and treat the
+ *    signature as vestigial.
  *
  * Two independent fail-closed guards keep a bad assembly from ever minting:
  *  - Cross-checks against the checkpoint being borrowed from: the supplied
@@ -200,6 +210,12 @@ export async function freshenReceipt(
     store.set(fullIndices[k]!, oldPath[k]!);
   }
   for (const link of links) {
+    // A base-0 link (treeSize1 === 0) has no from-peaks to climb — a 0→N
+    // consistency proof carries `paths: []` (the whole accumulator is its
+    // right-peaks). Skip it: it contributes no store nodes, and calling
+    // `peakMMRIndexes(-1n)` would throw (`posHeight(0)`, FOR-414). A genesis-
+    // rooted `.sth` chain always starts with such a link.
+    if (link.treeSize1 === 0n) continue;
     const fromPeaks = peakMMRIndexes(link.treeSize1 - 1n);
     fromPeaks.forEach((peakIndex, j) => {
       const climb = link.paths[j];