spec: redesign on-chain layer to constant-per-batch footprint

[TaprootFreak]

Summary

Replaces the per-spender Variant-1 on-chain design with the constant-per-batch design from the Shielded CSV paper:

• On-chain (new): one 231-byte fixed-size BatchInscription per publisher batch (~58 vBytes amortised), regardless of how many records it covers. Per-record marginal on-chain cost is zero.
• Off-chain (new): the BatchBundle (k=3 replicated by the same DA discipline as CoinProof bundles, content-addressed by Hc("BatchBundle", serialize)) and the AggregateBatchProof (recursive PCD attesting per-member validity, nullifier-set integrity, and new_root = SMT.insert_many(prev_root, nfs)).
• SpendRecord stays as the per-spender object but moves off-chain; a spender hands it to a publisher, which aggregates many into a BatchBundle.
• Mints are off-chain unless the issuer chooses to anchor them.

Why

The Variant-1 design (PR #21) traded constant-per-batch blockspace for blind-node rebuildability — at ~40 vBytes per record on Bitcoin. Discussion revealed the rebuildability property is preserved at lower cost by extending the existing k=3 replication discipline to BatchBundles: a verifier still verifies trustlessly (recursive proof check, not a trust assumption), the on-chain root commitment plus DA-replicated bundles deliver the same property as raw on-chain nullifiers. At 10 sat/vB and $100k BTC: ~$0.58 per batch (constant); per-record amortised well under $0.01 for typical batch sizes.

What changed

End-to-end rewrites: §3.1 on-chain object, §3.2 publisher signing, §3.3 off-chain signature handling, §3.4 publisher role, §3.5 inscription format, §3.6 chain scanning, §3.7 nullifier accumulator, §3.8 fees, §3.10 transaction states.

Cross-section updates: §1.4 SpendRecord off-chain + new BatchInscription/BatchBundle entries; §1.6 trees framing; §2.1 clause 4; §2.2 adds AggregateBatchProof; §2.3.1 mint off-chain; §2.3.2 send hands record to publisher; §2.3.3 receive non-membership via Path A or Path B; §4.5 recovery step 2; §4.6 k=3 extended to BatchBundles; §5.6 public-mode explorer; §5.7 balance attestation re-anchored via batch; §6.1 node responsibilities; §6.3 portability argument; §6.4 interfaces; glossary; test vectors V.5/V.6.

Diff: +315 / -241 in a single file. Build is clean (no broken anchors).

Test plan

• 3-subagent review loop (Quality + Logic) — see if either reviewer finds inconsistencies between the rewritten §3 and the cross-references in §1, §2, §4, §5, §6.
• Verify the Mint case is internally consistent (mints are off-chain unless optionally batched).
• Verify the BalanceAttestation rewrite (§5.7) correctly anchors via BatchBundle position + BatchInscription completion.
• Verify the on-chain byte layout (V.6) matches §3.5 word for word.
• Verify the AggregateBatchProof public inputs in §2.2 match the chain-scanning verification step in §3.6.

[TaprootFreak]

Re-review (doc-consistency pass)

The PR is now MERGEABLE/CLEAN with all CI green, and the body correctly V2-adapts the inherited #38/#39 changes (the F9 three-check at §4.3 now reads "Pk₀ from the k = 3-replicated BatchBundle" rather than on-chain, and the #37 profile-preimage pin survived). Two doc-level issues remain that CI cannot catch:

1. Blocking — glossary Invoice entry contradicts the body (F9 regression from the develop-merge)

The develop-merge reverted the glossary Invoice entry to its pre-#38 shape, dropping pk0 and addr_sig:

this PR (glossary): {amount, recipient, asset_id, memo?, ivpk, op_pubkey, relays, sig}
develop (glossary): {amount, recipient, asset_id, memo?, pk0, ivpk, op_pubkey, relays, addr_sig, sig}   + "Both are required."

The body (§1.5 schema + §4.3 three-check) declares pk0 and addr_sig mandatory and describes the forgery protection they provide, so the glossary now lists an Invoice tuple that is missing two fields the spec requires. onBrokenAnchors/CodeQL do not detect a glossary↔body contradiction. Please re-sync the glossary Invoice entry to the develop (post-#38) form.

2. Minor — anchor-tightening drift vs the #37 convention

27 links whose label cites a specific §X.Y now resolve to a section-top anchor (#1--foundations-normative, #3--on-chain-layer, #5--access--explorer, …), undoing the #37 tightening convention that is now on develop. The anchors are valid (build passes); they are just less precise than the labels claim. A pass re-pointing these 27 to their §X.Y subsection anchors restores the convention.

[TaprootFreak]

Both findings addressed in a0dd748:

1. Glossary Invoice entry — re-synced to develop's post-spec: add addr_sig (sk₀) + pk0 binding to Invoice (F9) #38 form (full tuple with pk0/addr_sig + "Both are required." sentence).
2. Anchor drift — 33 cross-references retightened. The Foundations §1.X family now resolves to docs: replace stale SP1/zkVM references with Plonky2; fix mock-mode and polling claims #11/docs: replace stale SP1/zkVM references with Plonky2; fix mock-mode and polling claims #12/docs: add Trust Model page + reframe trust-model section as run-your-own-node #13/Release: develop -> main #14/docs: point footer source link to the Plonky2 circuit (drop stale SP1 link) #15/Release: develop -> main #16/Discoverability: unblock AI crawlers, add llms.txt, host protocol docs on docs.zkcoins.com #17 subsections, Proofs §2.3.3 to #233-receive, Access & Explorer §5.6/§5.7 to Spec: global serial nullifier accumulator forces publisher contention — throughput / centralization economics unanalyzed (§3.4/§3.6) #56-shareable-confirmation-links, etc. Also caught the [Foundations](#1--) §1.X plain-text-after-link variant.

Build passes locally with no broken anchors. Re-review pass welcome.

The architectural review on the constant-per-batch model + AggregateBatchProof + off-chain accumulator-DA trade-off — separate from these doc-consistency fixes — remains for a human cryptographer / paper-fidelity pass before merge.