Decisions needed¶

One place for every open question. Builders (ChatGPT, Claude) write here instead of only saying it in chat. The owner answers here or in chat; the answer is recorded and the entry moves to Resolved.

Open¶

#	Date	From	Question / limitation	Options + recommendation
4	7 Oct 2026	ChatGPT, WO-03b	The light-client explanation overstates what count binding and header proofs establish.	Recommend qualifying §2b and the light-client explanation: inclusion was possible before this fix; the seal authenticates the claimed count. Inclusion does not establish full block validity or current unspent status. Height comes from chain position, not a header height field. QTL depth and E46i calculations need additional validated context. No light client was built here. See WO-03b report item 4.
5	7 Oct 2026	ChatGPT, WO-03b / map review	The map conflates generic preimage costs with collision costs and labels the combined address security as established.	Recommend correcting the ideal-model arithmetic and naming its assumptions: an ideal 256-bit joint output has generic classical preimage cost about 2^256 and Grover scale 2^128; a 512-bit ideal output has corresponding scales 2^512 and 2^256. Actual RL/joint-address security is unestablished. Clarify whether any smaller quoted cost denotes a separate attack model. Sources: CHAIN-DESIGN §2a, §7, §9; PHASE3-RESULTS §L.5.
6	7 Oct 2026	ChatGPT, WO-03b / white-paper review	Grover table-oracle agreement and sampled collision measurements do not establish full-width RL security or equality with SHA-256 security.	Recommend qualifying the white paper’s §3 claims: distinguish measured simulation/test results from ideal-function estimates and unestablished resistance to structural attacks. Retain the limitations already recorded in PHASE3-RESULTS §L.3–L.7 and the raw evidence.
7	7 Oct 2026	ChatGPT, WO-03b / white-paper review	The statement that a PoW hash weakness only makes mining easier and “nobody loses coins” is not supported.	Recommend correcting white-paper §3: difficulty adjustment may restore cadence while an attacker retains disproportionate mining power, enabling censorship or reorganizations. PHASE3-RESULTS §L.6 already records this distinction. No ASERT or network-security test was run by WO-03b.
8	7 Oct 2026	ChatGPT, WO-03b / QTL handoff	The absolute claim that quantum computers cannot shortcut the planned SHAKE chain lacks an explicit construction-specific assumption and resource model in the announcement text.	Recommend requesting the exact sequentiality argument, assumptions and cited result before retaining that wording in white-paper §1 / CHAIN-DESIGN §8; label the planned dual delay accordingly. Its quantum resistance is not established by the Merkle or Grover table tests. This is a review question, not a demonstrated attack on the chain.
9	7 Oct 2026	ChatGPT, WO-03b / WO-04 handoff	“Always catches a typo” is broader than the demonstrated Bech32m checks and obscures checksum versus semantic validation.	Recommend stating the applicable BIP-350 error-detection conditions precisely, and retaining the WO-04 boundary: checksum/prefix/framing checks do not establish a valid address payload, activation state or network consensus acceptance. See WO-04-REPORT.md and CHAIN-DESIGN §2a / white-paper §7.
10	7 Oct 2026	ChatGPT, WO-03b	WO-03b provides a C++ proof record and test CLI, but no consensus proof wire format, authenticated-header source or block resource limits.	Recommend recording an explicit downstream integration checklist: callers authenticate the expected bound root, WO-08/09 validate supplied event IDs/bodies, and later block/P2P work defines wire encoding and limits. `tree_root()` is diagnostic only. Keep the approved WO-03b scope; do not silently treat the test protocol or opaque events as consensus-valid.
21	8 Oct 2026	Owner (for P2P, later)	Use an IRC channel for peer discovery as a backup, like Bitcoin 0.1–0.3?	Recommend no IRC. Bitcoin removed it in 2011: IRC servers banned the traffic as botnet-like, it was a single point of failure, and it leaked node IPs. Instead, layered bootstrap: (1) hard-coded seed-node list in each release; (2) DNS seeds run by 2–3 different people; (3) peer exchange (addr gossip) once connected; (4) optional Tor/I2P onion seeds (build flag, off by default); (5) research option: signed peer announcements on Nostr relays as the modern ‘IRC’ fallback (open protocol, no permission needed; some Bitcoin-run relays may refuse altcoin traffic, so E46 runs its own relays and never depends on others). Owner likes the layered approach (8 Oct 2026). Decide details when P2P is ordered.

These are review/claim/integration items, not failed WO-03b tests. The local bound-root implementation passed its recorded checks. Owner direction, 7 Oct 2026: proceed with the DONE WO-03b handoff; retain these Open items for reviews and audits. This authorizes the handoff without resolving the technical items. The builder has not rewritten the owner-maintained maps to settle them.

Forward versus retrospective status¶

Forward implementation: WO-03b is complete locally and ready for Claude’s independent review. No unresolved formula choice or observed test failure is blocking this implementation. Release and sanitizer suites: 12/12 each; differential run: 104,570 comparisons, including 30,279 wrong-count rejections.
Retrospective claim review: items 4–9 concern existing documentation and claims. They do not request additional WO-03b implementation.
Downstream integration: item 10 records obligations for later consumers of the library. It does not expand the approved WO-03b scope.
Workflow handoff: DONE WO-03b, authorized by the owner despite the retained Open review items. This is permission to hand off, not a reviewer PASS or permission to merge. No next work order starts before Claude’s PASS and the owner’s next order.

Paradox II: held for Sunday (Claude’s task)¶

The paradox: the claims grew faster than the evidence. Several sentences Claude wrote in the white paper and spec say more than the tests showed. Items 4–10 above are that gap. The owner chose to hold them for the Sunday review (7 Oct 2026).

Item	Claude’s planned fix on Sunday (with before/after shown to the owner)
4	Reword the light-client explanation: inclusion was provable before count binding; the seal adds the count; height comes from counting headers, not a header field; E46i/QTL checks need more validated context
5	Label address security as an ideal-model figure (≈ 2^256 classical, ≈ 2^128 Grover for the 256-bit payload, assuming both hashes behave ideally); real RL/joint-address security unproven
6	Change “indistinguishable from SHA-256” to “matched SHA-256 on the tests we ran”; full-width security unproven
7	Most important: remove “nobody loses coins”. A proof-of-work shortcut could give an attacker most of the mining power, then reorganizations and double-spends. People can lose coins
8	Cite the post-quantum sequential-work result (to verify: Chung, Fehr, Huang & Liao, EUROCRYPT 2021) and state the random-oracle assumption for the planned hash-chain lock
9	Precise Bech32m wording (BIP-173/350: guaranteed to catch errors in up to 4 characters); a valid checksum isn’t a valid address
10	Add a downstream integration checklist to WORK-ORDERS.md (callers check the bound root against a trusted header; WO-08/09 validate event IDs and bodies; block/P2P work defines wire limits)
extra	Found by the owner’s map (7 Oct 2026): Claude wrote “every real message goes through at least 112 steps”. That’s true only for 1–4-byte messages; the empty message takes 72 steps (8-byte length prefix + v3’s final byte). Fix every “at least 112” sentence (PHASE3-RESULTS, RL-V3-PAPER, white paper) to state the message size

When done, items 4–10 move to Resolved.

Resolved¶

#	Date	From	Question	Decision
1	7 Oct 2026	ChatGPT, WO-03	Event IDs, byte order, duplicates and Rad field sizes undefined	WO-03 sorts by (type, ID), rejects duplicates; formats defined in CHAIN-DESIGN.md §2g
2	7 Oct 2026	ChatGPT, WO-03	A Merkle path can’t authenticate the leaf count	Bind the count into both roots (CHAIN-DESIGN.md §2b)
3	7 Oct 2026	Claude	Rad and stamp thresholds measured on the wrong message size (“Paradox A”)	Z_base 43, Z_commit 18, provisional until WO-08/09 measure
11	7 Oct 2026	ChatGPT, WO-08	Rad puzzle had no candidate limit per nonce	Option B: fixed domain S = 2^20, a = u64 LE index ‖ 8 zero bytes, index < S; all distinct pairs accepted; Z_base ≈ 41 provisional (CHAIN-DESIGN §2g, §4)
12	7 Oct 2026	Owner / WO-08	Full-scan cost wording	Wording only: “expected cost under the optimal full-scan strategy”; rule unchanged. Measure that strategy. Optimality is the stipulated model, not a new proof from this benchmark.
13	7 Oct 2026	Owner / WO-08	Collision-block trigger	NEXT byte tier strictly above Z_base: 8*(floor(Z_base/8)+1), so base 41 triggers at 48. Report measured Rad rate and resulting collision-block frequency. Owner instruction governs pending Claude §4 update.
14	8 Oct 2026	Owner / WO-14	Toy widths versus built-library oracle	Option C: keep w=2,3,4 toy-width oracles Python-only; cross-check the actual C++ `librl` against the Python reference at w=64 only. Preserve quantum cost analysis in section M at Z_base=41, including BHT collision search, Grover for a given Rad, and the 18-bit stamp. Claude will correct the WO-14 row in WORK-ORDERS.md.
15	8 Oct 2026	Owner / WO-05	Human-readable encoding for wtxid	wtxid is a raw 32-byte SHAKE digest, displayed as plain hex only; it is not user-facing and must never use the `e46tx` envelope, which would make its string indistinguishable from txid. Reserve `e46wtx`/`te46wtx` for possible future display, unused now. Claude will add this to CHAIN-DESIGN §2a.
16	8 Oct 2026	Owner / WO-06	ASERT integer rules and target bounds	Option A: BCH `aserti3-2d` exactly (16-bit fixed point, cubic 2^x constants, truncating division, arithmetic shift), E46 numbers: spacing 150 s, half-life 7,200 s, anchor = genesis (anchor parent time = genesis time − 150). Max target `0x1d7fffff` (≈2^231, 25 leading zero bits, 2^25 expected hashes) for mainnet and testnet; genesis bits = max target (re-measure before launch). Clamp: result 0 → 1; result > max target → max target, checked before any fixed-width shift can overflow. Compact bits: canonical only; reject negative, overflow, zero mantissa, target > max. Implemented in WO-06; exact rule is recorded in CHAIN-DESIGN §2.
17	8 Oct 2026	Owner / WO-07	100-block E46i burn in the WO-07 handoff	Keep spec. The 100-block burn was an error in Claude’s handoff (an early 7 Oct idea, superseded the same day). E46i follows CHAIN-DESIGN §5.3a only: value = v >> epochs elapsed (lazy, half-life = 1 decay epoch of 17,280 blocks), spendable any time after normal coinbase maturity (100 blocks); no 100-block expiry. Ordinary E46 never decays.
18	8 Oct 2026	Owner / WO-11	Wallet seed derivation encoding and output length	Approved: 32-byte master seed; account and index are u32 little-endian; KMAC256 key is the master seed; message is ASCII `E46-key` ‖ account ‖ index; empty customization; 48-byte output split as bytes 0–15 `SK.seed`, 16–31 `SK.prf`, 32–47 `PK.seed` (FIPS 205 order). Recorded in CHAIN-DESIGN §2e.
19	8 Oct 2026	Owner / WO-11	OpenSSL seeded SLH-DSA keygen is documented “for testing purposes”	Option A (testnet): keep OpenSSL 3.6.5’s SLH-DSA-SHAKE-128s provider, with guards: pin the OpenSSL version in the build; run the NIST ACVP seeded-keygen KAT in CI on every build; run the same KAT as a wallet startup self-test and refuse key generation if it fails. Revisit before any mainnet launch. Logged as CHAIN-DESIGN §7 S18.
20	8 Oct 2026	Owner / WO-12 read-up (found by Claude)	Coinbase height and genesis pszTimestamp sat in the witness, outside the txid (duplicate coinbase txids; headline not sealed by merkle_root); plus gaps a–d	Approved: coinbase `lock_time` = block height; coinbase witness = `extranonce[8] ‖ ≤100 free bytes`; genesis pszTimestamp is carried in one or two leading 0-E46 Data outputs, each payload ≤80 bytes, concatenated in order with no added bytes. (a) witness commitment = bound root of wtxids with the coinbase wtxid as 32 zero bytes; (b) extranonce fixed at 8 bytes; (c) sighash commits value ‖ type ‖ varbytes payload of every spent coin; (d) every output ≤ T, checked sums, outputs > inputs or any sum > T invalid. CHAIN-DESIGN §2e, §2g updated.
22	8 Oct 2026	Owner / WO-12 exam	lock_time boundary and sequence switch	Follow Bitcoin exactly: a transaction with lock_time L is valid only in a block whose height (if L < 500,000,000) or median-time-past (otherwise) is strictly greater than L; lock_time is ignored when every input’s sequence is 0xFFFFFFFF, so a wallet that wants the lock sets at least one sequence to 0xFFFFFFFE. Coinbase lock_time = height (#20) is exempt. CHAIN-DESIGN §2e Locks updated.
23	8 Oct 2026	Owner / WO-10	Genesis timestamp and witness commitment occupy separate coinbase Data outputs, and the full headline exceeds 80 bytes	Option A: every coinbase’s last output is the witness commitment (type 0x03, value 0, payload exactly the 32-byte bound root using a zero coinbase wtxid). Genesis pszTimestamp is the concatenation of one or two preceding Data-output payloads (each ≤80 bytes), in order and with no added bytes; the commitment remains last. The stale §2b wording that put pszTimestamp in the coinbase input is corrected. Testnet fixture headline is exactly `E46 08/Oct/2026 NASA’s SpaceX Crew‑12 Splashes Down, Sets Briefing to Discuss Mission` (89 UTF-8 bytes), split as `E46 08/Oct/2026 NASA’s SpaceX Crew‑12 Splashes Down,` (56 bytes) and `Sets Briefing to Discuss Mission` (33 bytes).

How to add an entry¶

| # | date | who, WO | the question in one sentence | options + recommendation |

Then reply BLOCKED WO-NN, see DECISIONS-NEEDED.md instead of DONE WO-NN.