proof-aware-crypto-tooling-.../provider
mrwulf 6cf1694453 paper v4: merge of two independent hostile reviews (17->18 pages)
Review A (second Fable instance, delivered via USB, findings re-verified
by me against the tex before adoption; its frontier lemma re-derived from
scratch before applying):
- THE REAL FIX: Lemma 2's hash-fold definition did not cover its own two
  uses (Root recomputes only along the leaf's root path; ConsRec bottoms
  out at the [0,n0) decomposition and consumes the pinned root, which the
  old Steps 1-2 never pinned - incl. the degenerate case where the first
  component IS the pinned root alone). Now: folds shaped by a connected
  sub-tree S containing the root, children outside S consumed as opaque
  inputs, conclusion pins emitted values AND all consumed inputs; Thm 2
  names its S; Thm 3 pins the consumed anchor and handles the degenerate
  case; Lemma 1's role stated honestly.
- dangling R4/R5 taxonomy labels removed; G3/Prop 2 statements now match
  their own veto-proof (deny-only, everywhere); Table 1 caption counts
  boundary+standard-three; r1 defined as raw signature bytes (T1's whole
  point); Contribution 4 'embedded in every signature' -> 'published
  alongside'; Figure 1 redrawn in the exact RFC 9162 shape for n=12;
  Solana error-type nit; App D namespace elision noted.

Review B (GPT-5.6, positions defended 2026-07-10, concessions adopted):
- abstract + G2 narrowed to what Prop 1 proves (same-size evidence +
  monotonicity), unequal-size split views routed through the public leaf
  mirror; residual-trust sentence stated at honest width (checkout, deps,
  binding, parsing in the trusted observation pipeline); freshness
  declared an availability policy (freeze attacks not prevented);
  self-reference verb 'ensures' -> 'enforces and records' + signature
  reveals nothing about the producing program; novelty softened to
  'we are unaware of'; 25-line/150-line accounting in one breath;
  missing-oracle-axiom = refuse-to-classify drift (keeping the oracle
  argument); mechanization tone softened; head-encoding reality
  documented (versioned canonical JSON w/ log id - system was ahead of
  the paper); NEW claim-matrix table (Table 2) decomposing every consumer
  conclusion into mechanism + residual assumption, incl. two deliberate
  not-established rows.

Open questions from Review A resolved: black_box 27 lines are per-lemma
trusted-base bookkeeping (no published cone contains black_box -
verified); T4 x=0 edge case now stated precisely (roots coincide, set
sign bit rejected per RFC 8032, covered by the iff over extracted code;
Lean sqrt_core handles x=0 explicitly); Cheval pages (DBLP-verified)
restored alongside Review A's DOI.

18 pages, 106 tests green, accumulator untouched (12 leaves).
webdocs/llms.txt page counts updated.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-10 10:34:21 +02:00
..
src/pacta_provider paper v4: merge of two independent hostile reviews (17->18 pages) 2026-07-10 10:34:21 +02:00
pyproject.toml add nested proof check provider 2026-07-03 13:03:58 +02:00
README.md add transparency log trust provider 2026-07-03 14:09:34 +02:00

PACTA Proof Check Provider

This nested project is a prototype third-party proof-checking service. It reuses host Lean/Aeneas infrastructure, runs portable PACTA replay/audit checks, and emits signed attestation certificates.

It does not modify anything outside this repository. It may read configured toolchains such as /Users/oho/GitClone/ClaudeCodeProjects/your-lean-project/aeneas-toolchain/env.sh.

It can also maintain a local transparency log. The log is an RFC 9162-style Merkle accumulator over signed attestations. It emits Signed Tree Heads with Ed25519 today and records an ML-DSA/FIPS 204 signature slot as unavailable unless a real backend is present. Agents that require both signatures must reject such receipts.

Commands

PYTHONPATH=src:provider/src python -m pacta_provider discover
PYTHONPATH=src:provider/src python -m pacta_provider init-key --key-dir provider/state/demo-provider
PYTHONPATH=src:provider/src python -m pacta_provider check \
  --config examples/repos.yaml \
  --repo-name dalek-ed25519-verified \
  --repo repos/dalek-ed25519-verified \
  --provider local-pacta-provider \
  --private-key provider/state/demo-provider/provider.ed25519.key \
  --public-key provider/state/demo-provider/provider.ed25519.pub \
  --out provider/out/dalek.attestation.yaml

Transparency log:

PYTHONPATH=src:provider/src python -m pacta_provider log-init \
  --log-dir provider/state/transparency-log \
  --provider local-pacta-provider \
  --public-key provider/state/demo-provider/provider.ed25519.pub

PYTHONPATH=src:provider/src python -m pacta_provider log-append \
  --log-dir provider/state/transparency-log \
  --attestation provider/out/dalek.attestation.yaml \
  --private-key provider/state/demo-provider/provider.ed25519.key \
  --public-key provider/state/demo-provider/provider.ed25519.pub \
  --out provider/out/dalek.receipt.yaml

PYTHONPATH=src:provider/src python -m pacta_provider log-sth \
  --log-dir provider/state/transparency-log \
  --private-key provider/state/demo-provider/provider.ed25519.key \
  --public-key provider/state/demo-provider/provider.ed25519.pub

The resulting certificate can be consumed by pacta with --attestation, --trust-attestation-provider, and --attestation-public-key.

The receipt can be consumed with --transparency-receipt, --transparency-log-public-key, and --require-transparency-receipt.

The private key must remain provider-side. Downstream agents only need the public key, the inclusion receipt, and a policy decision that the provider name/log key is trusted.