From f6fb88c15a19fed43611e6e472830c7fc18be993 Mon Sep 17 00:00:00 2001 From: Evan Date: Wed, 29 Jul 2026 16:06:57 -0700 Subject: [PATCH] Plan: Phase 2 reference notes, CLVM costing learnings and muladd Two notes requested by Evan (2026-07-29) so they are not lost when Phase 2 design starts. First, per-condition costing reads Chia's deployed condition costs and the CHIP-0049 revisions (base cost past a free tier, announcements always priced, cap removed for pricing) before we design ours, with the free-tier carve-out and the announcement-to-message mapping called out as decisions to make rather than inherit. Second, the taproot-output-construction question: bllsh solves it in-language with secp256k1_muladd, our architecture points to a condition form the validator computes natively, decided when CONDITIONS.md v0 is drafted. --- docs/execution-plan.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/execution-plan.md b/docs/execution-plan.md index 3c999ef..94af5de 100644 --- a/docs/execution-plan.md +++ b/docs/execution-plan.md @@ -102,6 +102,11 @@ - [ ] **Adversarial regression corpus** in `vectors/matching/`: the duplicate-CREATE_COIN theft case as vector #1; batching-wallet scenarios; message forgery/replay shapes; mixed-tx edge cases. - [ ] Cross-check subset: for semantics that overlap Chia (timelock comparisons, dedup behavior), translate Chia consensus tests into bitlisp vectors. +**Reference material for this phase (recorded 2026-07-29, per Evan):** + +- **Condition costing has five years of deployed CLVM learnings: read them before designing ours.** Chia's deployed per-condition costs are the baseline, and CHIP-0049 (the Chia 3.0 hard fork, in review) revises them: a base cost of 500 per condition beyond the first 100, announcement conditions always priced, and the hard 1,024-announcement cap removed in favor of pricing. That is the pricing-over-caps philosophy obligation 2 commits us to, applied by the team with production data. Two decisions to make deliberately rather than inherit: whether a free tier (their first-100 carve-out) is acceptable or a cliff we reject, and how their announcement pricing maps onto our tx-scoped SEND/RECV_MESSAGE conditions, their closest descendant. +- **Taproot output construction belongs to the condition layer, not the VM (design question, decide in CONDITIONS.md).** bllsh ships `secp256k1_muladd`, a general EC linear-combination operator, largely so programs can verify taproot tweaks in-language. BitLisp will meet the same need when covenant recursion constructs a successor coin whose scriptPubKey is taproot(internal key, tree). The conditions-architecture answer is a condition form that commits to the taproot components and lets the one hardened validator compute the tweak natively, keeping EC arithmetic out of the consensus VM. Decide the form when CONDITIONS.md v0 is drafted, and record the muladd decline rationale next to it (VM.md section 8, D2 entry, already records the v0 decline). + **Done when:** invariant suite green over large generated corpora; adversarial corpus ≥ 50 hand-designed vectors each citing a MATCHING.md rule; a reviewer can read MATCHING.md alone and predict every vector's outcome. **Claude Code fit:** strong for implementation + invariant/corpus generation; **design decisions stay in Fable 5 sessions** (this chat) and land in spec prose before Claude Code touches them. Session pattern: Fable 5 designs a matching rule → spec commit → Claude Code implements + generates vectors → Fable 5 reviews divergence reports.