diff --git a/docs/README.md b/docs/README.md index c0e9613..a493e73 100644 --- a/docs/README.md +++ b/docs/README.md @@ -16,6 +16,10 @@ and the novel-layer register. Cited by CLAUDE.md ground rule 3. - [opcode-comparison.md](opcode-comparison.md): informative side-by-side of the CLVM, bllsh, and BitLisp operator sets. +- [objection-register.md](objection-register.md): every objection on + the public record to a Lisp VM for Bitcoin or to the conditions + architecture, with BitLisp's answer, its status, and where it + lives. The skeleton of the Phase 5 essay. - [condition-comparison.md](condition-comparison.md): informative side-by-side of Chia's deployed condition vocabulary and BitLisp's v0 vocabulary, plus the validation-layer architecture comparison. diff --git a/docs/objection-register.md b/docs/objection-register.md new file mode 100644 index 0000000..2d1a024 --- /dev/null +++ b/docs/objection-register.md @@ -0,0 +1,155 @@ +# Objection register + +Every objection on the public record to a Lisp VM for Bitcoin, or to +the conditions architecture in particular, with BitLisp's answer and +where that answer lives, or an admission that it does not exist yet. +The register is the skeleton of the Phase 5 essay and of the direct +exchange with the introspection architecture's author (evaluation doc +section 6 items 1 and 5). An objection the essay cannot point at a +row for is a gap in this file, not in the essay. + +Sources are the nine public threads read in full on 2026-08-16 +(evaluation doc sections 8.4 and 8.5 list them: the March 2022 +bitcoin-dev thread, the OP_FOLD and jets threads, the covenants +terminology post, the October 2023 scriptPubKey thread, delving 636, +682, 1224, 1275, and post 14 of delving 1509), plus the two exchanges +already recorded in the evaluation doc (section 6 items 5 and 6), +cited only as that document records them. Attributions are to public +posts. Per project policy, private correspondence stays out and is +not quoted here. + +## Status vocabulary + +| status | meaning | +| --- | --- | +| ANSWERED | a spec statement or a ratified decision answers it, and vectors or invariants pin the answer | +| RECORDED | a decision or an argument answers it on the record, with no artifact that a reviewer can run | +| PARTIAL | part of the objection is answered and the rest is owed, the row says which part | +| OPEN | acknowledged and unanswered, with the phase that owes the answer | +| CONCEDED | BitLisp accepts the objection as a real cost and says so in the evaluation doc | + +A CONCEDED row is not a failure of the register. The essay's rule +(execution plan, Phase 4) is to publish the miss, and a conceded +objection stated first by this project is worth more than one stated +first by a reviewer. + +## 1. Objections to any expressive VM + +These apply to Simplicity, to the introspection Lisp, and to BitLisp +alike. The essay owes each of them an answer before the conditions +architecture's own objections come up. + +| id | objection | source | BitLisp's answer | status | where | +| --- | --- | --- | --- | --- | --- | +| O1 | Reviewability is priced empirically and superlinearly. A single opcode family (TXHASH) was judged an order of magnitude worse than CTV by the person who implemented both, and a whole VM sits orders beyond that. | Roose, O'Beirne, delving 1509 (2025). ZmnSCPxj, bitcoin-dev (2022): "I can read C++ better than frikkin Bitcoin SCRIPT." | No argument refutes a price. The response is artifacts that let a reviewer check the price for themselves: a spec complete enough to predict every vector without reading the implementation (ground rule 1), a vector corpus that is the source of truth between sessions, a dual-oracle diff harness over the CLVM intersection, a closed operator set with no BLS and one signature scheme (D1, D2, D3), and a reference implementation kept small enough to review whole. The hardened implementation's line count against the Python reference is a Phase 6 number the essay publishes either way. | RECORDED, the measurable part owed to Phase 6 | evaluation doc 7.1 item 7 and 8.5 item 3, `docs/vm-record.md` D1 to D3, `tools/diff_clvm.py`, `vectors/` | +| O2 | The audit burden of generality. If APO or CTV must be reimplemented in a covenant language, a reviewer audits the general machinery plus every reimplementation, where BIP 118 was a five-line patch. | ZmnSCPxj, bitcoin-dev (2022) | The conditions architecture's specific reply is that the checks a contract would otherwise reimplement (output matching, signature binding, fee reserve, identity) live in one validator specified once, and a program emits claims rather than re-deriving the check. The introspection side's reply (wallet bugs beat consensus bugs) is a values argument and is not claimed here. The residue is real: program logic still exists per contract and still needs review. | PARTIAL, the per-contract residue conceded | evaluation doc 7.2 item 2, `spec/VALIDATION.md` rules 1 to 8 | +| O3 | Witness-supplied code plus OP_SUCCESS-style upgrade semantics is theft: a spender injects a success opcode. Delegation "wreaks havoc" on soft-forking new opcodes. | Towns, bitcoin-dev (2022). O'Connor, delving 682 (2024). ZmnSCPxj on the pre-segwit `1 RETURN` hazard (2022) | The operator set is closed and an unknown operator is a hard failure before its arguments are evaluated, so no byte in a witness can evaluate to success by being unrecognized. Upgrades travel by new tapleaf version for coins created after a fork and by reserved conditions for coins already deployed. A reserved condition is inert data with a declared cost that old and new validators both charge, so assigning it meaning later only tightens validity, the OP_NOP direction. | ANSWERED | `spec/VM.md` section 3.2, `spec/VALIDATION.md` rule 6, D3, C4, `vectors/vm/dispatch.json`, `vectors/conditions/encoding.json` | +| O4 | Dynamic typing forgoes what static types buy at consensus: bounds-check-free evaluation after quasi-linear typechecking, and maximum memory computed upfront from the program. | O'Connor, delving 682 (2024) | Conceded for the consensus VM: BitLisp is untyped like CLVM, and adopts the introspection side's reply that an attacker can always craft programs that typecheck but fail. The upfront-memory half is the same question as O12 and is open there. A typed authoring language is a separate tooling gate after Phase 5 and never changes consensus semantics. | CONCEDED for consensus, the memory half OPEN under O12 | execution plan Phase 3 hard scope boundary, `docs/vm-record.md` entry 8 | +| O5 | No ZK story. Neither Simplicity nor a Lisp suits proof systems, and a ZK-verifier opcode has the strongest exit asymptotics of any candidate. | Rubin, bitcoin-dev (2022). Evaluation doc 4.7 records the candidate | The pure (program, witness arguments) to condition-list function is the statement a proof would prove, per input and before transaction assembly, with the validator untouched by such an upgrade. ZK_VERIFY is reserved as a condition in the reserved tier. The data-availability dependence of rollup exits, and the blast radius of a verifier soundness bug, are recorded against the opcode candidate. | RECORDED, no artifact exists or is planned | evaluation doc 4.7, section 5 obligation 4 and principle 4, `spec/VALIDATION.md` rule 6 | +| O6 | Non-termination, not recursion, is the dangerous property, and "covenant" is the wrong word for the useful capabilities (transaction introspection, output introspection). | Towns, bitcoin-dev (2022) | Every evaluation runs under a cost budget charged in evaluation order and failing closed at `cost_exceeded`, a zero budget rejects every program, so no BitLisp program fails to terminate. Recursion exists only through `a` and is bounded by the same budget. The vocabulary half is owed: the docs use "covenant" in the broad sense in several places, and neither puzzle doc states its construction's termination path, the question the objection says skeptics actually ask. | PARTIAL, the termination bound ANSWERED, the vocabulary and per-construct statements owed to the essay | `spec/VM.md` section 3.3, D7, `vectors/vm/dispatch.json`, `docs/glossary.md` | +| O7 | Homoiconicity breeds private macro dialects, and embedded DSLs mean learning two languages. Standardize the macro layer or drop it. Macros are "something of a false idol" for debuggability. | ZmnSCPxj, bitcoin-dev (2022). Towns, delving 1224 (2024) | The v0 authoring language has no macro system. It has fixed special forms (`if`, `list`, `assert`, `and`, `or`), `defun`, `defun-inline`, computed `defconstant`, and `include` resolved through one explicit search path everywhere. A macro unit landed on 2026-08-16 and was reversed the same day on this record. Re-evaluation stays open at the typed v1 gate, decided on the benchmark-puzzle authoring experience. | ANSWERED for v0 tooling | `docs/lang/language.md`, execution plan Phase 3 units 6, 6b, 6c | +| O8 | "NACK ON THE ONE-CHARACTER NAMES." Give operators proper names, add quasiquotation, consider infix sugar. | ZmnSCPxj, bitcoin-dev (2022) | The VM keeps CLVM's names and opcodes on everything shared, because the diffable intersection and the vendored upstream test corpus are worth more than readable mnemonics at the consensus layer, where the reader is an implementer with the table open. The authoring language is where names live, and its forms are named. No quasiquote in v0 (it left with the macro system). | PARTIAL by design, the VM half declined under ground rule 3 | `spec/VM.md` section 4, `docs/lang/language.md`, `docs/opcode-comparison.md` | +| O9 | Nail down the high-level to low-level mapping for debuggers early. Source maps are insufficient for CLVM-class targets, something DWARF-strength is needed, and this is Chia's biggest developer complaint. | prozacchiwawa, delving 682 (2024). Towns' CPS debugger in delving 1224 is the response on his side | Compilation produces a symbol table beside the bytecode, and the REPL runs a stepping debugger over the reference VM (`debug`, `step`, `next`, `trace`) with the stacks shown at every task. Whether this reaches the DWARF-strength bar (recovering variable bindings in every context after `apply`) is untested, the benchmark puzzles are the first real workload, and their authoring observations feed the typed v1 ledger. | PARTIAL, the mechanism exists, its adequacy is measured by unit 7 | `docs/lang/language.md` symbol table, `docs/lang/repl.md`, execution plan Phase 3 | +| O10 | Safe, probably, and politically unactivatable. "CAT, Simplicity, or Lisp" would not harm the incentive structure, and none will activate. | Black, delving 1509 (2025) | Conceded. BitLisp is a research project and not a soft-fork proposal. Its deployment posture is two-track: CTV and CSFS (or BIP 448) are compatible groundwork on their own timeline, and the architecture is built as a specification plus Inquisition and signet deployment, evidence in every activation scenario including slow ones. The laboratory framing (prove behaviors in Lisp, distill opcodes if warranted) is the one generality argument that survived the 2025 thread. | CONCEDED | `docs/motivation.md`, evaluation doc section 5 deployment posture and 8.5 item 3 | + +## 2. Objections to the CLVM-derived VM + +Defects and design questions raised against CLVM itself or against +the introspection Lisp's CLVM inheritance. BitLisp inherits the same +VM under ground rule 3 and owes each of them a divergence row, a +vector, or an open entry. + +| id | objection | source | BitLisp's answer | status | where | +| --- | --- | --- | --- | --- | --- | +| O11 | CLVM serialization is non-canonical (several encodings of one value) and verbose (100 kB of block CLVM gzips to 60 kB). | Towns, bitcoin-dev (2022), delving 682 (2024) | Canonicality is answered: non-minimal length prefixes, trailing bytes, and back-references are `bad_encoding`, one accepted spelling per program. Density is not: BitLisp keeps CLVM's wire format so the serializer stays inside the diffable intersection, and the witness-size question is obligation 3, measured against the 526 vb gate in Phase 4. A bespoke format is the introspection side's answer and adds a format to review, with its own `rd` and `wr` still marked broken in the 2024 artifact. | PARTIAL, canonicality ANSWERED, density OPEN to Phase 4 | D5, `spec/VM.md` section 2, `vectors/vm/serialize.json`, evaluation doc section 5 obligation 3 | +| O12 | CLVM costs total allocation, never live memory. A recursive doubling program builds a 200 MB live string inside the mempool cost limit, where Script holds live memory near 500 kB. Fixing it means costing memory, which fixes a consensus-preferred evaluation order. | Towns, bitcoin-dev (2022), delving 682 and 1224 (2024) | Open. BitLisp inherits the total-allocation model and states no point-in-time memory bound. Both sides are recorded: keep the model and prove the reachable peak acceptable under the Phase 4 budget mapping, or adopt a peak bound and pin evaluation order as observable behavior. The measurement that sizes the reachable peak is a Phase 4 bullet, and the 200 MB construction is a mandatory adversarial vector class for whichever side wins. | OPEN, Phase 4 | `docs/vm-record.md` entry 8, execution plan Phase 4 | +| O13 | Evaluation order is consensus surface. Eager and lazy differ in memory profile, the cost result "must not be changed as a result of any optimisations", and the introspection prototype flipped order twice. Mandate lazy evaluation as spec. | Towns, delving 1224 (2024). ZmnSCPxj, bitcoin-dev (2022) | The order is stated and pinned: arguments evaluate right to left in the CLVM stack-machine order, `i` evaluates all three arguments with no lazy branch, the rightmost failing argument's error wins, and cost accrues in evaluation order against the budget. Laziness is an authoring-layer idiom (`if` compiles to the apply-over-quoted-branches shape), the same split the introspection side settled on. What the order implies for memory is O12. | ANSWERED for order, the memory consequence OPEN under O12 | `spec/VM.md` section 3.2, `vectors/vm/dispatch.json`, `docs/lang/language.md` `if` | +| O14 | Chialisp tolerates surplus solution arguments. In Bitcoin that is third-party wtxid malleability: a relay peer mutates unconsumed witness bytes and produces a conflicting wtxid at a lower effective feerate. | Towns, delving 636 (2024) | Open, with the serialization half closed. D5 gives each program one accepted spelling. The semantic half (solution bytes that deserialize canonically and are never consumed) is recorded with both sides steelmanned, and it interacts with O12 because "consumed" depends on evaluation order. Until decided, no standard-layer template may depend on surplus tolerance. The decision is owed before the Phase 4 witness format freezes. | OPEN, Phase 4 | `docs/vm-record.md` entry 9, D5 | +| O15 | A soft-fork operator must be NOP-shaped with an explicit version bound and a statically knowable cost, never SUCCESS-shaped. Chia's own `softfork` was unimplemented in 2022. | Towns, bitcoin-dev (2022) and delving 636 (2024). ZmnSCPxj (2022) on static cost and version | The NOP-shaped mechanism exists at the condition layer: reserved conditions carry a declared cost that every validator charges before and after assignment, with a floor against free spam, so a future assignment can only tighten. An in-VM guard was declined as redundant with tapleaf versions plus reserved conditions, then reopened on the argument that a guard is cheaper than spending leaf versions, with a pre-registered deciding test (a concrete upgrade the guard delivers that the reserved tier cannot) and no deadline. Until decided, nothing in the tree assumes a guard. | ANSWERED for the mechanism, the guard sub-decision OPEN with no deadline | `spec/VALIDATION.md` rule 6, C4, `docs/vm-record.md` decision 1 and its addenda | +| O16 | CLVM's defect history: the negative-division inconsistency, CATbleed (insufficient hash-input domain separation), unmetered internal recursion depth, and operators checked only after their arguments evaluate. Each deserves a regression vector. | Towns, delving 636 (2024), the primer's defect section | Negative division: floor semantics matching the consensus binary, the Python library's deprecation treated as policy (D6, pinned and diffed). CATbleed: BitLisp has no `coinid` and no in-VM identity derivation, program identity is the tree hash whose leaf and pair tags are distinct and whose child hashes are fixed width, and the CREATE_OUTPUT_TAPROOT and self assert derivations use BIP 341's tagged hashes. Argument-first evaluation: an unknown operator fails before its arguments evaluate and a reserved atom fails after, both stated. Recursion depth: the spec sets no depth limit and the cost budget is the only bound, so the safe depth for a recursive implementation is a Phase 4 bound to record beside D8, and the C++ implementation must be non-recursive or prove the reachable depth safe. | PARTIAL, three of four ANSWERED, depth owed to Phase 4 and 6 | D6, D8, D9, `spec/VM.md` sections 3.2 and 4, `vectors/vm/arith.json`, `vectors/vm/sha256tree.json` | +| O17 | A state tree living beside taproot commitments must hash distinctly from the BIP 341 TapLeaf and TapBranch tags, "to ensure they can't be misinterpreted as taproot scripts, possibly enabling theft of funds." | Towns, delving 1275 (2024) | Argued and unstated. The tree hash is Chia's untagged construction with one-byte `0x01` and `0x02` node prefixes, structurally disjoint from BIP 341 preimages that begin with two 32-byte tag digests, so no confusion is apparent. The spec statement and the vector pinning the disjointness argument are owed with the Phase 4 commitment scheme, the point at which the tree hash and the taproot tags meet in one tree. | OPEN, Phase 4 | `docs/vm-record.md` D9 addendum | +| O18 | Numbers. Truncating u64 arithmetic cannot hold satoshi amounts, arbitrary-size sign-bit numbers match CScriptNum, and the muladd scalar endianness divergence should go by using big-endian throughout. | Towns (self-adjustment, delving 682). ZmnSCPxj, bitcoin-dev (2022) | Integers are arbitrary-size signed big-endian two's complement atoms, the CLVM rule, so amounts never truncate and there is no little-endian anywhere in the VM. Redundant encodings are accepted as operands and cost at actual length, results are always minimal. Condition-layer amounts carry the field's own domain, 0 to MAX_MONEY, rejected at parse outside it. | ANSWERED | `spec/VM.md` section 1, `vectors/vm/arith.json`, C9, C15 | +| O19 | BLS is a Chia artifact. Bitcoin has secp256k1 only, no deployed aggregation, and a second signature scheme is attack surface. | Towns, bitcoin-dev (2022), the first of his two listed changes | The BLS operators are absent (D1). The one signature operator is BIP340 Schnorr over secp256k1 with tapscript's tri-state rule, ECDSA and the r1 curve declined (D2). At the condition layer each signature assert carries its own 64-byte signature and verifies as a self-contained triple (C16), digests are BIP340 tagged hashes with fixed-width binding fields (C17), which also closes a non-injective message concatenation found in the deployed BLS design during the port. The aggregate-verification saving Chia gets is conceded as unavailable until Bitcoin has a deployed aggregation scheme. | ANSWERED, aggregation CONCEDED | D1, D2, C16 to C19, `vectors/vm/secp.json`, `vectors/validation/signature-asserts.json` | +| O20 | Costing is unfinished in every public artifact. No published cost schedule exists for the introspection Lisp, and the stated methodology (implement in C++, benchmark, derive) has not been run. | The threads' own record, evaluation doc 8.5 item 4 | BitLisp states a complete v0 schedule (core, every operator family, every condition) inherited from CLVM's deployed table and anchored to CHIP-0049's condition pricing, with every constant marked PROVISIONAL, a pre-registered Phase 4 measurement pass that re-prices each one and isolates per-spend overhead, and a weight mapping still TODO with one constraint already normative (the per-byte witness cost floor the flat condition costs rely on). Upstream's February 2026 modpow repricing sets the re-validation bar and is recorded as such. | OPEN, Phase 4, the schedule stated and the measurement owed | `spec/COSTS.md` sections 1 to 10, decision 25, C21, C22, evaluation doc section 5 obligation 2 | +| O21 | Cost must be knowable before evaluation. A committed maximum operation count that adds to transaction weight makes every evaluation total, and Bitcoin deliberately conflates bytes with CPU. | ZmnSCPxj, OP_FOLD and jets threads (2022), bitcoin-dev (2022) | Every evaluation is total under the budget regardless (O6). Whether the budget is derived from weight or declared and committed is the Phase 4 weight-mapping decision, and the annex-declared shape has one precedent in the record: the taproot annex was declined as a signature carrier (C16) as a contested namespace under today's relay policy, which weighs against an annex-declared budget too. The jets question does not arise: the operator set is closed and no relay-level compression is planned. | OPEN, Phase 4 | `spec/COSTS.md` section 9, C16, execution plan Phase 4 | +| O22 | The introspection Lisp's own VM divergences from CLVM (reverse cons, balanced-tree environments, `partial`, dropped division, u64 bitwise operators, ascending string compare, eager `i` with lazy `if` only in the surface language) each carry a rationale that a CLVM-faithful design must answer. | Towns, delving 682 and 1224 (2024) | Each stays at the CLVM default under ground rule 3, recorded side by side with its bllsh counterpart in the opcode inventory. The eager `i` with surface-level `if` is shared. The rest are declined without a first-principles case having been made against the CLVM form, and the inventory names the capability each would add so a later case can be made against a row rather than a memory. | RECORDED | `docs/opcode-comparison.md`, ground rule 3 | + +## 3. Objections to the conditions architecture + +These are the ones that separate BitLisp from the introspection +Lisp. The evaluation doc's two steelmen (sections 7.1 and 7.2) +already carry the strongest form of most of them, and the rows below +point back rather than restate. + +| id | objection | source | BitLisp's answer | status | where | +| --- | --- | --- | --- | --- | --- | +| O23 | The novel validator is the whole risk budget. A cross-input matching engine with multiset semantics is exactly the kind of accounting where Bitcoin's worst consensus failures have lived (CVE-2018-17144 was a duplicate-input accounting bug), and correctness margins dominate capability margins. | Evaluation doc 7.1 item 1, from the August 2026 exchange | Answered by work rather than argument. The validator is specified as eight rules in five stages of strictly increasing context, each rule with a hypothesis invariant suite and adversarial vectors opening with the theft case that motivated it (duplicate CREATE_OUTPUT, grafted-output interception, fee theft), the novel-layer register naming the oracle substitute for each rule, and every Chia-portable semantic translated from the deployed validator's tests. Hostile review of this layer is the Phase 5 binding test and has not happened. | RECORDED, the review OPEN to Phase 5 | `spec/VALIDATION.md`, `docs/condition-record.md` section 4, `vectors/validation/`, `python/tests/test_*_invariants.py`, evaluation doc 7.3 | +| O24 | Chia's bundle model does not port. Spend bundles merging in the mempool complicate block assembly, may increase centralization pressure and censorship, and let third parties link their spends to yours. | Towns, bitcoin-dev (2022), the stated reason for choosing introspection | Not imported. The transaction is the atomic unit: the transaction view is a pure function of the containing transaction, messages and announcements balance within it (C8), a transaction with no BitLisp input is subject to no rule, and the composition guarantee makes two independently valid transactions valid when concatenated, so nothing a validator does depends on what else is in the mempool. Hard gate 1 (deterministic transaction-scoped validity) is the same property stated as a gate. The deployed design's own author states monotonicity was designed in, so the property is not an accident of porting. | ANSWERED | C8, decisions 14 and 16, `spec/VALIDATION.md` rule 2 and rule 3, `vectors/validation/mixed-transaction.json`, `vectors/validation/messages.json`, evaluation doc 8.4 items 1 and 4 | +| O25 | Bitcoin's positional identity blunts the flagship win. Non-interactive aggregation on Chia rests on content-derived coin identity, and an aggregator recombining spends changes every downstream outpoint, breaking presigned chains. | Evaluation doc 4.4 qualification, from the August 2026 exchange | Conceded and mitigated. The claim is qualified to constructions whose downstream authorization travels in script or in rebindable signature messages, a discipline binding on the benchmark programs. The seal family (SEAL, SEAL_OUTPUTS) is the consensus answer to interception: an assert pinning the spending transaction's txid or outputs hash, with the grafted-output regression pair. Every binding surface carries a recombination-stability class, and seals are a third class of spend-time facts. The recombined-txid cost to txid-tracking wallets is recorded as an integration cost. | CONCEDED, mitigated by ANSWERED rows | evaluation doc 4.4 and section 5, C20, decisions 12 and 24, `vectors/validation/seals.json` | +| O26 | The Chia evidence is contaminated. Five years of operation validates conditions plus Chia's coin model as a package, and porting the conditions half alone may keep the novel-validator cost while shedding the identity model that made it work. | Evaluation doc 7.1 item 5 | Accepted as fair in 7.3, and located: the identity and recombination seam (decision 12) is where Chia's converged vocabulary stops being a reference because its fixed point assumes content-derived identity. That seam gets no translated tests and is exercised by merge invariants and recombination vectors instead, which the novel-layer register says plainly. | CONCEDED, the seam RECORDED | evaluation doc 7.3 and 8.3, `docs/condition-record.md` section 4 closing paragraph, decision 12 | +| O27 | Both architectures' designers publicly leaned introspection for a Bitcoin retrofit. | Towns and Cohen, bitcoin-dev (2022), Cohen again in delving 682 (2024) | Handed to the steelman first (7.1 item 6) and answered on substance in 8.4: the recorded objection targets Chia's bundle and mempool model, none of which this architecture imports (O24). The same designer separately noted that conditions and the coin format are what enable capabilities as well as covenants, and that matching this in Bitcoin might take aggressive OP_CAT use. Authority is not argument, and the essay says both. | RECORDED | evaluation doc 7.1 item 6 and 8.4 item 2 | +| O28 | The margins are narrower than they look. External-state claims can move to the annex, accumulating checks can be a few special-cased opcodes or annex records in BIP 345's shape, and purity's caching benefit exists under introspection too. | Evaluation doc 7.1 item 2 | Two replies on the record and one measurement owed. The introspection side's own flagship state-carrying design re-derives per contract what the condition layer provides once (value accounting into a successor, scriptPubKey recomputation, domain-separated state hashing), with a five-hook template layer proposed to make it bearable, a condition vocabulary in embryo (7.2 item 8). The consolidation benchmark is the concrete case where the architectures differ in complexity class, one condition against an O(N^2) scan or a special-cased opcode, and its adversarial variant is an obligation 1 vector. The exchange conceded that accumulating checks belong in condition lists. The witness-byte cost of computed-over-context claims, the measured half, is Phase 4. | PARTIAL, the measurement OPEN to Phase 4 | evaluation doc 3.2, 7.2 items 1 and 8, 8.5 items 1 and 2, `vectors/validation/vault-consolidation.json` | +| O29 | Coin set versus UTXO. Retrofitting onto Bitcoin should leave the UTXO model intact and compensate with transaction-parsing operators, and dual coin identities "gunk up" the system. | Cohen, bitcoin-dev (2022) | The UTXO model is intact and no coin-set identity exists anywhere. Output claims name literal scriptPubKey bytes (C1), identical claims consume distinct positional slots (C3), addressing fields are what the validator holds from prevout data (C9), and every condition that would need a chain read (birth, ephemeral, before-style timelocks) is declined, with the reserved tier as the reintroduction path (C5 to C7, C13, C14). Chia's coin-parent reading is a recorded decline because it is unverifiable from prevout data. | ANSWERED | C1, C3, C5 to C7, C9, C13, C14, `spec/VALIDATION.md` transaction view | +| O30 | Direct assertions about the transaction may be the best way to go for a Bitcoin Lisp, and conditions are a layer comparable to the transaction format, outside the language. | Cohen, bitcoin-dev (2022) and delving 682 (2024) | The central architecture question, kept open by design and argued from both sides in the steelmen. The layering advice is followed exactly: the VM is a pure predicate machine and the condition layer is a separate spec with its own record. The assert families read the transaction view directly and are direct assertions in all but delivery mechanism. The claims (output slots, message halves, the fee reserve) are what only a validator-level object provides, and the question the essay points review at is whether that object's correctness risk outweighs its capability margins. | RECORDED, the essay's framing question | evaluation doc sections 5, 7.1, 7.2, 7.3, decision 14 | +| O31 | Ephemeral coins and intra-transaction chaining do not port. A Bitcoin transaction cannot spend its own outputs. | Evaluation doc section 5 known honest costs | Conceded and made structural: ASSERT_EPHEMERAL is declined as always false, its companion interlock is moot because BIP 68 anchors relative locks at prevout confirmation, and package-level validation is the recorded reintroduction trigger. | CONCEDED | C14, decision 20, `vectors/conditions/self-asserts.json` | +| O32 | Expressiveness invites tokens and spam, and inscriptions on bare Script show expressiveness may not be the binding constraint on spam either way. | Evaluation doc section 5 obligation 4, recording both sides | Curation with the counterargument beside it. Consensus-carried bytes with no consensus meaning are declined (C2 memos), the vocabulary is complete over the spend schema and every omission is a recorded decline (principle 1), and the fungible asset token is built as a capability-and-risk study, not a goal, to know what the vocabulary exposes rather than to guess. | PARTIAL, the study OPEN at unit 7 | C2, evaluation doc section 5 obligation 4 and principle 1, execution plan Phase 3 unit 7 | +| O33 | Cultural headwind: this is "porting Chia to Bitcoin." | Evaluation doc section 5 known honest costs | Conceded as a cost and answered where it can be: Bitcoin-native vocabulary in every artifact with the glossary bridging both ecosystems, the transaction model and every field domain taken from Bitcoin, and the Chia inheritance limited to the VM intersection where fidelity to a deployed binary is a checkable claim. The match-Chialisp-by-default rule is itself a reviewability argument, not a loyalty. | CONCEDED | `docs/glossary.md`, ground rule 3 | +| O34 | "The only thing missing is the assertion about one's own id." | Cohen, bitcoin-dev (2022) | Landed as the self assert family over outpoint, txid, scriptPubKey, and amount, then extended to the execution identity taproot splits into two (tapleaf hash and merkle root as rule 3 specifier fields, C23) and to the cheap identity assert over the control block's internal key and merkle root (C24), with internal-key addressing of a counterpart declined as attacker-satisfiable. | ANSWERED | decisions 20, 26, 28, C23, C24, `vectors/validation/self-asserts.json` | +| O35 | The aggregation record is thin. Identical-spend dedup shipped only in release 2.5.5, program-aware aggregation caused a 2025 block-production incident, and fast-forward eligibility versus replay defense is a live tension. | Evaluation doc 4.4 reality check, from the August 2026 conversation and corpus study | Cited as thin. The offer economy's daily non-interactive composition is the evidence that stands, the node-level story is stated as younger than the architecture allows, and the rebasability-versus-replay tension is the recombination-stability classification's job on this side, resolved per binding surface with the seal family as the replay-side answer. | RECORDED | evaluation doc 4.4 and 8.2 item 4, decisions 12 and 24 | +| O36 | What has actually been built with it? Where is the Lightning Network on Chia? | Rubin, bitcoin-dev (2022), unanswered on the introspection side until the 2024 earmarks demo | The vault (BIP 345 core semantics plus keyless consolidation) and the singleton wrapper are written, compiled, and pinned as vectors. The payment pool, the asynchronous offer, and the token study are queued in that order. The four-puzzle acceptance artifact is what Phase 4 measures and what the essay cites at file level. Until the pool exists, the scaling argument's flagship construction is unmeasured. | PARTIAL, two of five built | `docs/puzzles/vault.md`, `docs/puzzles/singleton.md`, `vectors/vm/vault-programs.json`, `vectors/vm/singleton-programs.json`, execution plan Phase 3 unit 7 | + +## 4. What the register owes + +The OPEN and PARTIAL rows, grouped by the phase that owes them. This +list is the objection-side view of the execution plan and must agree +with it. + +Phase 3 (unit 7): +- O9, the debugger's adequacy under real puzzles. +- O32, the token capability-and-risk study. +- O36, the pool, the offer, and the token. + +Phase 4: +- O11, witness density against the 526 vb gate (obligation 3). +- O12, the reachable live-memory peak and the evaluation-order + decision (VM record entry 8). +- O14, surplus solution data (VM record entry 9). +- O16, the safe recursion depth beside the D8 bounds. +- O17, the tree-hash and taproot-tag disjointness statement. +- O20, the measured cost schedule and the weight mapping. +- O21, derived versus committed budget. +- O28, the witness-byte cost of computed-over-context claims. + +Phase 5: +- O6, the covenant vocabulary and the per-construct termination + statements. +- O23, hostile review of the validation layer, the binding test. + +Phase 6: +- O1, the hardened implementation's size against the reference. +- O16, a non-recursive evaluator or a proven depth bound. + +No deadline: +- O15, the in-VM guard sub-decision. + +## 5. Anticipated, not yet raised + +Objections the essay should expect that no public thread has made, +because the threads predate the scaling argument. Recorded so the +essay states them first. + +- The 300 vb per-user-lifetime floor and the 10% exit-space + allowance are assumptions. The gate's sensitivity table covers + exit rates, not the floor or the allowance, and a reviewer can + pick different ones. The essay owes the arithmetic under each. +- Pooled custody with unilateral exit trades per-user block space + for coordination and watchtower requirements the arithmetic does + not price. The candidates are compared on exit bytes alone. +- The offer-based exit aggregation is exactly the non-interactive + composition whose upstream record O35 calls thin, and Bitcoin's + positional identity (O25) qualifies it further. The essay must not + lean on it harder than 4.4 allows. +- The four design obligations were set by the same author who + designs against them (the correlated-blind-spot item on the plan's + risk watch-list). External implementers arrive only after Phase 5, + and the register cannot substitute for them.