Refracting Light v3 → Rads → Two Merkle Roots

E46 / Tessera learning and review map · 7 October 2026. Follow branches 01–11 in order; 12 is the workflow master list and 13 the spec sheet (added 8 Oct 2026). This is a map of the current construction, evidence and build boundary, not a new consensus specification. Physics names are metaphors. No quantum hardware is involved. Owner map edits and working WO-08 reference files are included as a dated snapshot.

• 01 · Orientation — what goes where5

  Start here, then follow the numbered branches. CODE means implemented source inspected; MEASURED means a recorded experiment, not a proof; MATH means a derivation with stated premises; MODEL means an idealized estimate; PLAN means approved or proposed work not yet delivered; REVIEW means unresolved assurance or wording.

  • [CODE] The main path0

    Message bytes → length/padding → D0…D3 plus P/Q → bitwise signed-digit input → four coupled state lanes → eight final steps → rotate/XOR fold → 128-bit RL digest. Sources: REFRACTING-LIGHT-SPEC.md §1–5, §8; e46/src/rl.cpp; e46/src/rl_detail.hpp.

  • [PLAN] The Rad path0

    Context and nonce → SHAKE256 stamp → fixed-domain candidates → two RL hashes sharing leading bits → validated Rad → serialized event → event Merkle tree → event_root in the block header. Linked To: branches 06–08.

  • [CODE] The transaction path0

    A 32-byte txid becomes a tagged SHAKE256 Merkle leaf. Transactions stay in block order, coinbase first. Their count-bound root occupies merkle_root beside event_root. Merkle hashing uses SHAKE256, not RL.

  • [REVIEW] “ROT alternating shards” needs precise names0

    The implemented record has contiguous data shards followed by P and Q. The source does not alternate left/right rotation of those shards. ROT refers to left rotations of state words and final 128-bit lanes. Each input bit updates all four lanes from the same old state. Linked To: branches 02–03.

  • [STATUS] Where this session stands0

    Updated 8 Oct 2026 (Claude). PASSED: WO-01 RL lib, WO-02 SHAKE/KMAC, WO-04 Bech32m, WO-03 Merkle, WO-03b count-bound roots, WO-08 Rad engine (S = 2^20 per nonce; measured 9.3 Rads/block at Z 41, 25.4 at Z 40; collision tier 48, model ≈ every 9.9 blocks; stamp Z 18 ≈ 1.7 s), WO-14 Grover re-run (Rad by BHT ≈ 2^13.7, given Rad by Grover ≈ 1.16 M, stamp ≈ 512), WO-05 addresses and IDs (#15: wtxid raw-only), WO-06 header/PoW/ASERT (#16: aserti3-2d, MAX_TARGET 0x1d7fffff = 25 zero bits; surprise exam 25,000 checks, 0 mismatches). WO-07 emission, pools, E46i (#17: no 100-block E46i expiry; 100-year totals 36.8M/4.6M/4.6M; surprise exam 17,000 checks, 0 mismatches). WO-11 SLH-DSA keys + KMAC (#18 seed bytes, #19 OpenSSL pinned + startup self-test; empty-context bug found in review and fixed; surprise exam 1,550 checks, 0 mismatches). WO-12 transactions (#20: coinbase lock_time = height, genesis headline in Data output, a–d; surprise exam 400 txs, 0 mismatches; duplicate-coinbase and malleability checks pass). WO-10 genesis miner (#23: headline in one or two Data outputs, witness commitment last; testnet genesis NASA Crew-12 headline, nonce 14,449,748, block ID 808be9c6…; independently rebuilt 8/8). WO-09 Block QTL (#24: one salt per reveal; wallets draw a fresh OS-random salt; no node salt registry; reveal window 6..2,016 tested at 5/6/2016/2017; surprise exam 400 commitments, 0 mismatches). WO-13 QTL v2 port (Python lock on SHAKE/KMAC, no SHA-2; 13/13 anti-lockout; C++ primitives match; Lock A/B surprise exam 80 checks, 0 mismatches). WO-16 offline CLI wallet (#25 E46QTLW2 file; signed payments accepted by the checker; seed never stored in plain). QUEUED: WO-13b C++ wallet flow (wallet/GUI phase). IN TEST: WO-17 local node, phase 1 (#26: miner 80% paid, pools accrue, Rads and stake locks off until phase 2; 41/41 tests, owner's 200-block run mining). OPEN: #27 phase-2 Rad payouts, #21 P2P bootstrap (owner: tomorrow). Qt wallet designed on canvas (5 screens, 8 themes incl. 3 accessibility). SUNDAY: full WO-01 review, Paradox II wording fixes, Z_base 40 vs 41, blindfold quiz. Rule 7: never rewrite git history (owner files restored from backup/making-it-better-9d73bc6).

• 02 · Binary → polynomials → six-shard record11

  This stage is deterministic encoding and redundancy. It is not encryption, a random-number generator, or extra message entropy.

  • [CODE] Bytes first; bits are read MSB first0

    A text message first needs an explicit byte encoding such as UTF-8. RL accepts bytes. Within every record byte, the core reads bit 7 down to bit 0. The core length prefix is BE64(n); this is distinct from the little-endian integers in chain event serialization.

  • [CODE] Four contiguous data shards0

    For n message bytes, s=ceil(n/4). Append zeros until there are 4s bytes. Dk is the contiguous slice [k*s,(k+1)*s), k=0…3. Appended zeros are distinguishable from real trailing zeros because n is encoded first.

  • [MATH] A byte is also a polynomial0

    Byte b7…b0 represents b7*x^7 + … + b1*x + b0, with coefficients in GF(2). Coefficient addition is XOR: 1+1=0. The same eight stored bits have a field interpretation here; the later lane arithmetic uses ordinary signed integers and carries.

  • [CODE] GF(256), modulus 0x11d0

    Multiply polynomials and reduce modulo x^8+x^4+x^3+x^2+1 (0x11d). This is finite-field multiplication, not ordinary integer multiplication and not a cyclic bit rotation. Example: 0x03×0x03 = 0x05 in this field; ordinary 3×3 is 9.

  • [CODE] xtime example: 0x80 × 2 = 0x1d0

    Shift left; if the old top bit was one, XOR the reduction polynomial and retain eight bits. x^8 reduces to x^4+x^3+x^2+1. Contrast rotl8(0x80,1)=0x01: a polynomial multiply and a rotation are different operations. Source: rl_detail.hpp::xtime; checked in rl-v3-map-examples.json.

  • [CODE] P parity: equal weights0

    For each column j: P[j]=D0[j] XOR D1[j] XOR D2[j] XOR D3[j]. This is a linear parity check. Two identical byte deltas in two data shards cancel in P.

  • [CODE] Q parity: weights 1, 2, 3, 40

    Q[j]=1·D0[j] XOR 2·D1[j] XOR 3·D2[j] XOR 4·D3[j], with every multiplication in GF(256). The coefficients correspond to 1, x, x+1, x². Two different parity equations spread data differences across the record.

  • [MATH] What the RS-style protection actually buys0

    For this (6,4) linear code, a nonzero column difference occupies at least three of the six symbols. It is redundancy in the message record. It does not make a compressed hash collision-free. The four original data shards plus the length prefix already make the full record injective.

  • [MATH] P/Q-silent differences remain possible0

    A column delta (D0,D1,D2,D3)=(1,2,3,0) has P delta 1 XOR 2 XOR 3=0 and Q delta 1 XOR 4 XOR 5=0. Three data symbols changed, so this respects distance three. This is why attackers can target P/Q cancellation without violating the coding property. Linked To: branch 05.

  • [CHECKED] Four-byte worked example0

    M=01 02 03 04; s=1; D0=01,D1=02,D2=03,D3=04; P=04,Q=10 hex. Core record=0000000000000004 01020304 04 10. v3 adds final byte 00. Total=15 bytes=120 steps; digest=b50e39319e845be3741f314aaff6e342. Tiny reference calculation only; no security inference.

  • [CODE] Empty input has a defined path0

    n=0 gives no shard bytes. The eight-byte zero length prefix is still processed, followed by the v3 finalization byte. That is 72 steps. Do not use historical “at least 112 steps” prose as a universal lower bound including the empty message.

• 03 · RedTail outward map and the rotation engine10

  Four lanes; each lane has x and v, each 64 bits. Total state is 4×128=512 bits. The four data shards are not four independently encrypted lanes.

  • [CODE] Initial state and signed digits0

    x=(0,1,2,3), v=(1,3,5,7), step i=0. outward(t)=t−16 when t≤0, otherwise t+15. Input bit 0 becomes d=−16; input bit 1 becomes d=+16. A signed working value is represented on a binary computer; this is not a ternary wire format.

  • [MATH] “Outward” is not saturation to ±infinity0

    This piecewise integer map moves values away from the central gap. It is injective on integers and skips −15…15. It does not clamp infinities or eliminate all eventual hash collisions. The state is subsequently reduced, mixed and folded.

  • [CODE] Stage A: accumulate z0

    For lane l and neighbour ν=(l+1) mod 4: z=257*x_l + 17*v_l + d*(i+l+1) + rotl64(x_ν,11+7*l). Neighbour rotation counts across lanes are 11,18,25,32. Multiplication/addition here are integer operations, with carries, not GF(256) operations.

  • [CODE] Stage B: outward, quotient and remainder0

    (q,r)=floor_divmod(outward(z),2^64). r is in [0,2^64); q carries the high part, including sign information. C++ uses signed 128-bit intermediates. Example z=0: outward(z)=−16, q=−1, r=2^64−16. Truncating division toward zero would be wrong.

  • [CODE] Stage C: update v0

    v′=rotl64((65537*v_l+q+d+i+l+1+v_ν) mod 2^64,13+8*l) XOR r. The four rotation counts are 13,21,29,37. Unsigned word wrap represents modulo 2^64 at the specified point.

  • [CODE] Stage D: update x0

    x′=r XOR rotl64(v′, ((i+11*l) mod 63)+1). This rotation changes with the step and lane, always between 1 and 63 inclusive. There is no alternating left/right rule in this formula.

  • [CODE] Update all lanes simultaneously0

    Compute all x′ and v′ from the old x,v arrays, then replace the whole state and increment i once. An in-place lane update would accidentally feed new state to later lanes and define another hash.

  • [MATH] Rotations themselves are reversible and linear0

    A fixed-width rotation permutes bit positions and has an inverse rotation. XOR is linear over GF(2). The complete step also includes additions, carries, the piecewise outward operation and modular arithmetic; linear pieces alone do not make the entire message-to-state function linear.

  • [CODE / MEASURED] Eight blank finalization steps0

    After the record, absorb 0x00: eight input bits b=0, hence d=−16 each time, with i continuing. “Blank” does not mean no-op. v2 lacked this stage. Tests motivated eight steps after observing better diffusion after two; this measured margin is not a proof of attack resistance.

  • [CODE] Exact step budget by message size0

    steps(n)=8*(8+6*ceil(n/4))+8. n=12 →216; n=44 →600; n=48 →648; n=55 →744; n=64 →840; n=120 →1512. These count steps, not equal-duration wall-clock guarantees. Linked To: Paradox A in branch 07.

• 04 · Four rotated lanes → one folded digest8

  This is the actual compression boundary. Keep final-state relations separate from reachable message relations.

  • [CODE] Unfolded view0

    L_l=(x_l<<64)|v_l. Unfolded=L0 || L1 || L2 || L3: 512 bits, 64 bytes, 128 hexadecimal characters, serialized big-endian per lane. Research output exposes the entire final state; it is not the chain digest.

  • [CODE] Folded view0

    H=L0 XOR rotl128(L1,29) XOR rotl128(L2,61) XOR rotl128(L3,97). H is 128 bits: 16 bytes, 32 hexadecimal characters. Each lane contributes after a fixed left rotation; the fold is not “take the last 128 bits.”

  • [MATH] Rank 128; kernel dimension 3840

    The fold F is a surjective linear map GF(2)^512→GF(2)^128 because L0 can supply any output. Rank-nullity gives a 384-dimensional kernel. Each possible digest has 2^384 raw-state preimages under F; that does not count accessible message preimages.

  • [MATH] Explicit raw-state cancellation0

    Choose any nonzero 128-bit u. Set ΔL0=rotl128(u,29), ΔL1=u, ΔL2=ΔL3=0. Then F(Δ)=rotl128(u,29) XOR rotl128(u,29)=0. This is an exact fold relation, not a discovered message collision. A numerical example is in rl-v3-map-examples.json.

  • [REVIEW] The real fold-attack question0

    Can an attacker efficiently find M≠M′ such that S(M) XOR S(M′) is a nonzero element of ker(F)? Choosing a raw-state delta is easy; steering the complete encoded message through the nonlinear state machine to that delta is the missing attack step. Linked To: branch 05.

  • [MATH] Two kinds of full collision0

    Different messages might reach the same full 512-bit state, or different full states might fold to the same 128-bit digest. The second type is sufficient to break folded collision resistance. A fold-only attack does not automatically produce a 512-bit state collision.

  • [MODEL] Width is not a measured security level0

    For an ideal 128-bit function, generic birthday collision work is on the order of 2^64 and preimage work 2^128. Actual RL may admit a structural shortcut. A 512-bit internal state does not give the 128-bit output 512-bit collision or preimage security.

  • [MATH] Hashing has no decryption key0

    A digest is a many-to-one summary. “Unfolding” here means asking the implementation for its full final state, not decrypting the digest. QTL is a separate keyed-access construction; it is not the inverse of RL hashing.

• 05 · Attack map — what has and has not been tested12

  Use this branch as an audit checklist. A passing test means that experiment passed on its sampled inputs, not that every attack is excluded.

  • [MODEL] Diagnostic truncation0

    Comparing only k bits intentionally increases collisions. For N independent ideal outputs, expected colliding unordered pairs=N*(N−1)/2^(k+1). Matching 8 or 16 bits is not a full 128-bit collision. Compare the entire digest before making the stronger claim.

  • [MEASURED] v2 fold-cancellation classes0

    PHASE3-RESULTS §H tested 20,000 pairs per class: random, single-early, late reinjection, last-data-byte, P-silent, Q-silent, P/Q-silent. Sampled differences had full folded/unfolded rank. These tests found no foothold in those classes; they did not remove the fold kernel or prove all message differences safe.

  • [MEASURED] v3 follow-up0

    PHASE3-RESULTS §J reports full ranks for the same seven fold classes and observed minima 40–44 changed folded bits. §I reports v3 avalanche means near 64 of 128. Use the v3 evidence when describing v3; the original §A–H results are explicitly v2.

  • [MEASURED] Last-step structure and the v3 response0

    v2 experiments injected a difference directly into a random internal state at the last step and saw lower-weight output differences. This is a useful local structural test, not by itself a realizable pair of complete messages. v3 added eight blank steps; follow-up measurements improved this signal.

  • [MEASURED] SAT and reduced variants0

    Solver experiments checked toy word widths and reduced-step states. The tested solver often timed out or cost more than brute force. That reports the solver/model/budget outcome; it does not rule out expert trails, meet-in-the-middle attacks or alternative encodings. Tiny widths also change the effect of constants.

  • [MEASURED] Truncated collisions through 64 bits0

    PHASE3-RESULTS §K records 53 RL searches and 29 SHA-256 controls at 40–64 compared bits, with 82 pairs verified. The displayed 64-bit match has different remaining 64 bits. These sampled partial-collision costs do not establish full-width security equivalence with SHA-256.

  • [REVIEW] Remaining classical attack routes0

    Search for message differences steering into the fold kernel; exploit carry/quotient constraints; try backward/forward meet-in-the-middle matches; examine chosen prefixes, near-boundary clamp states and counter structure; test P/Q cancellation and long-message structure. An arbitrary internal-state attack must be connected to valid message records.

  • [REVIEW] Domain separation and serialization attacks0

    A strong hash does not repair ambiguous bytes. Audit exact tags/NULs, widths, endianness, candidate range, numeric pair order, counts and duplicate handling. Changing a field without recomputing the expected domain is a separate implementation bug from a cryptanalytic collision.

  • [REVIEW] More pairs per nonce are not automatically an attack0

    The owner explicitly accepts all distinct valid pairs within a nonce domain. Multiple pairs from a bucket of three matching hashes are expected behavior. A detector must compare observed rates to the selected S/Z/search strategy and account for hardware and sampling uncertainty. Linked To: branch 07.

  • [MEASURED / MODEL] Grover table simulation0

    PHASE3-RESULTS §L used classical NumPy statevectors for 4/6/8-bit outputs, 4096 candidates, five targets each. For fixed marked count M and domain N, P_k=sin²((2k+1)*asin(sqrt(M/N))). Agreement checks the simulator and oracle, not whether RL has exploitable algebraic structure.

  • [MODEL] Full-width quantum costs need an oracle0

    Idealized RL-only preimage search has scale (π/4)*2^64 Grover iterations. Iterations are not classical hashes or seconds. Fault-tolerant gates, reversible compute/uncompute, qubits and memory must be costed. Generic collision algorithms have different models; WO-14 must analyze the bounded Rad domain rather than blindly reusing unrestricted collision estimates.

  • [REVIEW] What would count as a useful attack result?0

    Publish the exact version, valid distinct inputs, full digests, compared bit width, reproducible verifier, work/memory accounting and applicable assumptions. Distinguish a full hash collision, a truncated Rad, a raw-state fold cancellation, a parser bug and a consensus-rule failure.

• 06 · The bounded Rad construction11

  Owner decision #11: exactly S allowed indices per nonce; S=2^20 and base Z≈41 are provisional runtime parameters until measured. All distinct valid pairs from one nonce are accepted.

  • [SPEC] Bind the search to its context0

    stamp=SHAKE256_256("E46-rad\0" || prev_block_id[32] || u64_LE(window_index) || miner_payload[32] || u64_LE(nonce)). The tag terminates with one actual NUL byte. stamp is 32 bytes. The prefix makes changing context change the puzzle.

  • [SPEC] Candidate index → 16 bytes0

    candidate(i)=u64_LE(i) || eight zero bytes, with 0≤i<S. Verifiers check both the upper zero bytes and the range. A 16-byte buffer alone is insufficient: unrestricted messages would revive the puzzle-domain gap.

  • [SPEC] Numeric i<j, not lexicographic little-endian bytes0

    Rad pairs use indices i<j<S. Example: index 255 starts ff 00…, while 256 starts 00 01…. Lexicographic byte comparison would reverse this numeric ordering. Event IDs, separately, sort lexicographically as raw bytes. Keep these two comparison rules distinct.

  • [SPEC] Two 48-byte RL messages0

    ha=RL_v3(stamp || candidate(i)); hb=RL_v3(stamp || candidate(j)). Each input is exactly 32+16=48 bytes and costs 648 RL steps. A stamp is generated once per nonce context, not once per candidate in a full scan.

  • [SPEC] Z is the leading-prefix match length0

    z=clz128(ha XOR hb), with identical digests giving z=128. The Rad must meet the current minimum. The event stores Z as one byte. The source definition describes the actual shared-prefix length; WO-08 must check the declared value against the computed value.

  • [SPEC] Rad ID0

    id=RL_v3_128(stamp || a || b): 64-byte input, 16-byte output, 840 steps. It is a label and event sort key. It is not the event Merkle hash and not a cryptographic signature. Duplicate (type,ID) entries are rejected by the Merkle event layer.

  • [SPEC] Event serialization: 82 bytes0

    0x02 || miner_payload[32] || u64_LE(window_index) || u64_LE(nonce) || a[16] || b[16] || u8(Z). The previous block ID is supplied from chain context through the stamp; it is not repeated in this event body.

  • [PLAN] Honest, stolen and stale-event verification0

    Check fixed lengths/type, allowed indices, zero padding, numeric order, expected active window, computed stamp, exact Z and runtime threshold. Rebinding a pair to another miner/parent/nonce requires it to satisfy the new puzzle. Context binding is a hash condition, not an unconditional proof that no rebound pair could ever satisfy a threshold.

  • [SPEC] All distinct pairs accepted0

    If i,j,k share enough leading bits, (i,j), (i,k) and (j,k) are all permitted with canonical order. Do not stop enumeration after the first pair or silently enforce one Rad per nonce. Exact repeated events are still duplicates.

  • [SPEC] Byte tiers0

    tier(Z)=8*floor(Z/8). Base 41 has a 40-bit floor; an actual Z=48 Rad reaches the next byte tier. The current collision-block rule uses the base tier floor. Consequently any accepted Rad at Z≥base also reaches that floor; block-trigger frequency must be measured/defined consistently, not assumed rare.

  • [CODE / PLAN] Boundary with Merkle0

    WO-03b accepts type, supplied ID and already-serialized body. WO-08 must validate a Rad and supply the correct ID/body. A Merkle proof authenticates the committed bytes; it does not replace Rad semantic checks. Linked To: branch 08.

• 07 · Paradox A — measure the real work9

  A rate from 12-byte unbounded collision hunts is not a measurement of the current finite Rad puzzle. Formula counts below are model values; full-size runtime and Rad counts have not yet been measured in WO-08.

  • [CODE] Message sizes and step ratios0

    Old search message: 12 bytes / 216 steps. Rad candidate: 48 / 648 =3× steps. Commitment stamp: 55 / 744 ≈3.444× steps. Rad ID: 64 / 840. Block header: 120 /1512. CPU timings also include encoding, memory, lookup/sort and verification overhead.

  • [MODEL] Expected pairs in one complete domain0

    For S distinct candidates behaving as independent uniform 128-bit outputs, E[pairs meeting Z]=S*(S−1)/2^(Z+1). With S=2^20: Z39≈1; Z40≈0.5; Z41≈0.25; Z42≈0.125; Z43≈0.0625. These are expected pair counts, not probabilities or guaranteed outcomes.

  • [MODEL] Probability of at least one Rad0

    In the sparse-collision approximation, P(at least one)≈1−exp(−λ), where λ is the expected pair count. At Z41, λ≈0.25 gives about 22.1%, not 25%. Accepting all pairs requires counting multiplicities, not merely whether a puzzle succeeded.

  • [PLAN] Workload accounting0

    Record S, threshold range, context/nonce schedule, worker count, candidates evaluated, completed puzzles, pair counts by Z, sorting/memory costs and wall time. Keep each nonce domain separate. A full scan evaluates S candidates, but a valid event alone does not prove the miner performed all S evaluations.

  • [MODEL] Converting a measured run to Rads/block0

    Observed-rate projection=150 seconds * total valid pairs / elapsed wall seconds for the stated worker setup. Label it a projection, not a live network measurement. Do not multiply by worker count again when elapsed throughput already aggregates workers. ASERT and competing miners remain later work.

  • [PLAN] Rare events need uncertainty0

    A short run with zero or a few hits cannot settle Z_base. Report completed domains and exposure even when no Rad appears. Compare the measured count with the ideal model; preserve confidence/uncertainty rather than tuning to one lucky sample.

  • [SPEC / PLAN] Commitment stamp experiment0

    h=RL_v3("E46-commit-pow\0" || C[32] || u64_LE(nonce)); the NUL-terminated tag is 15 bytes, total 55. Success means leading_zero_bits(h)≥Z_commit. This is single-target PoW, not a collision search. Z_commit≈18 stays a runtime input.

  • [MODEL] Commitment waiting time0

    For independent uniform attempts at threshold b, expected attempts=2^b; individual attempts/time vary. At b=18 the ideal mean is 262,144 attempts. One accepted nonce cannot establish the mean. Measure repeated contexts with real 55-byte hashing and report the search cap if censored.

  • [PLAN] Resource limits for these experiments0

    At most four CPU workers; no install/push/merge; ask before a run expected to exceed about ten minutes. Avoid overlapping a benchmark with other heavy tests. Record machine/load and never describe projected hash work as fixed seconds on all CPUs.

• 08 · Two Merkle roots — alongside, not nested12

  Each root is a 32-byte SHAKE256 commitment. The two roots occupy separate fields in the same block header. A Rad is an event leaf; it does not contain its own nested Merkle tree in the current design.

  • [CODE] Leaf and node separation0

    leaf(x)=SHAKE256_256("E46-merkle\0" || 0x00 || x). node(L,R)=SHAKE256_256("E46-merkle\0" || 0x01 || L || R). Domain bytes are literal; L and R are 32-byte hashes. The tags distinguish leaf payloads from inner-node pairs.

  • [CODE] Transaction branch0

    x is the 32-byte txid. Preserve block order, coinbase first. The txid is hashed as a leaf rather than used directly as the leaf hash. A txid-to-full-transaction check is an additional step for a light client.

  • [CODE] Event branch0

    x is the complete typed event: type || body. Rad type=0x02; commitment type=0x03. Sort ascending by type, then raw ID bytes. Reject a repeated (type,ID). The separately supplied sort ID is not appended a second time to the leaf.

  • [CODE] Odd carry0

    Pair adjacent nodes left-to-right. If a level has an odd last node, carry it up unchanged; never duplicate it. For three leaf hashes A,B,C: raw_root=node(node(A,B),C). The proof for C contains node(A,B), with no fake self-sibling.

  • [CODE] Count seal — WO-03b0

    If count>0: bound_root=SHAKE256_256("E46-merkle\0" || 0x02 || u64_LE(count) || raw_tree_root). If count=0: zero32. Apply this once after the tree, including singleton trees. merkle_root and event_root both hold this bound root.

  • [MATH] Root tag 0x02 and Rad type 0x02 do not conflict0

    The root hash preimage begins domain || 0x02 || count || raw_root. A Rad leaf hash preimage begins domain || 0x00 || 0x02 || body. The surrounding prefix distinguishes their roles despite reusing the byte value in different fields.

  • [CODE] Proof record0

    Proof={leaf, index, leaf_count, siblings}. Reconstruct the raw tree using index/count and bottom-up siblings; omit carried levels; require exactly the needed siblings; seal with leaf_count; compare with the expected bound root. Count and index use uint64_t in the C++ record.

  • [MEASURED] The count ambiguity and fix0

    Before WO-03b, a first-leaf proof from a 3-leaf tree could verify under count 4 because the final sibling hid subtree size. The seal makes the compared commitment depend explicitly on the count. WO-03b differential tests recorded 30,279 altered-count rejections and 104,570 total comparisons.

  • [CODE / REVIEW] Empty tree is not an inclusion proof0

    An empty root is a defined zero value. There is no valid index or inclusion proof into a zero-leaf tree. A single leaf gets both its leaf hash and the count=1 root seal.

  • [CODE] 120-byte header layout0

    version[4] || prev_block[32] || merkle_root[32] || event_root[32] || time[8] || bits[4] || nonce[8]. The roots are beside each other; header PoW commits to the serialized fields. No height field is present. Header serialization/ASERT integration is WO-06.

  • [CODE / PLAN] RL PoW versus SHAKE block ID0

    RL v3-128 hashes the complete 120-byte header for PoW; the current spec compares it to the top 128 target bits. Block ID uses SHAKE256_256("E46-block\0" || header). These have different jobs. Root construction itself does not mine a block.

  • [REVIEW] Light-client boundary0

    Headers plus a supplied transaction/event and inclusion proof can establish membership under a trusted/validated root. Count binding adds count authentication; it did not invent inclusion proofs. Membership does not prove all block rules, unspent status or payout correctness. Height and QTL age derive from the validated header-chain position.

• 09 · Three different meanings of “collision”5

  Keep these concepts separate when interpreting an attack log or Rad count.

  • [SPEC] Intended Rad collision0

    Two distinct allowed candidate messages share at least the required leading Z digest bits in the same context. This is the work product. It need not match the remaining digest bits.

  • [REVIEW] Unintended complete hash collision0

    Two distinct messages have the same entire 128-bit RL digest. This is a collision-resistance question even if the protocol can count it as a high-Z event. Finding one substantially below the applicable generic model would warrant investigation.

  • [CODE] Duplicate event ID0

    Two events have the same (type,ID) sort key. The event-root layer rejects the block input, whether this is a repeated event or two distinct bodies with a colliding ID. It does not silently merge them.

  • [MATH] Merkle commitments bind bytes, not truth0

    A valid root can commit to invalid event bytes if a block producer supplies them. Full validation must check the events before accepting the block. Semantic validation and commitment verification complement each other.

  • [REVIEW] Mining advantage is a consensus risk0

    A cheaper-than-assumed PoW or Rad strategy may concentrate rewards/power. Difficulty adjustment can change cadence without removing a relative advantage. Avoid the claim that a hash weakness cannot harm users. Linked To: decision #7, deferred Sunday.

• 10 · Build gates and attack checklist10

  This branch connects the map to the current WO-08 work. It does not authorize skipping the manual owner → builder → Claude review relay.

  • [DONE LOCALLY] Foundation evidence0

    WO-01: RL reference matching and C++ implementation. WO-02: SHAKE/KMAC wrapper. WO-04: Bech32m framing. WO-03b: count-bound roots and complete proofs, release/sanitizer suites 12/12, 101,601 fuzz executions. Read reports for exact revisions and reviewer status; local passing results are not external cryptanalysis.

  • [IN PROGRESS] WO-08 Python source0

    rad_reference.py and generate_wo08.py were created after decision #11. A new 1000-case corpus plus toy mined fixtures and commitment hashes has been generated. No new WO-08 golden commit or C++ differential claim yet. Historical WO-03 event fixtures intentionally remain frozen, even though some predate the bounded candidate rule.

  • [NEXT] Freeze, implement, match0

    Review/freeze new WO-08 vectors; implement exact stamp, candidate encoding, numeric index ordering, event parser, ID, leading-prefix count, tier helpers and contextual verification. Compare C++ to Python on at least 1000 random/edge inputs before accepting the implementation.

  • [NEXT] Negative verification cases0

    Reject equal/reversed indices; index=S; nonzero upper candidate bytes; malformed event length/type; claimed Z mismatch; wrong active window; changed miner/parent/nonce; duplicate pair/ID at block integration. Test i=255,j=256 explicitly so little-endian bytes cannot masquerade as numeric order.

  • [NEXT] Mining prototype and calibration0

    Enumerate bounded-domain candidates for each chosen nonce; retain all valid distinct pairs. Measure full S=2^20 domains and actual 55-byte commitment searches using runtime thresholds. Preserve raw results, all zero-hit domains and worker timing. No extrapolated result may be labeled a measured chain rate.

  • [NEXT] Harden and report0

    Warnings as errors; release and ASan/UBSan; parser fuzzing; at most four workers. Report measurements, limits and any new decisions. Preserve all prior golden/evidence files. Claude independently checks before the next work order.

  • [LATER] WO-14 on built libraries0

    After WO-08 PASS, the next scheduled order is the Grover re-run using C++-generated oracle tables and the approved finite Rad puzzle. Follow the exact domain and accepted-solution count. A changed oracle/input domain needs new resource reasoning.

  • [DEFERRED] Items #4–#10, Sunday0

    Light-client wording, ideal security arithmetic, simulation versus security, mining advantage, QTL sequentiality assumptions, checksum guarantees and downstream integration remain review items. They are not silently resolved by this map. Decision #11 candidate domain is resolved by the owner.

  • [REVIEW] Full scan is a harness choice, not proved work0

    The approved rule limits valid candidate indices. It does not demonstrate that a miner evaluated every allowed index before finding a pair. Describe S-hash full-scan calibration precisely; avoid claiming the verifier certifies exactly S hashes or hardware fairness. This is a wording/assurance limit, not a change to the accepted domain.

  • [REVIEW] Collision-block frequency0

    With acceptance Z≥base and trigger tier=floor(base/8)*8, every accepted Rad meets the current trigger floor. If a rarer trigger is intended, it needs a separately approved rule. If not, use measured probabilities of any Rad per block; do not carry forward an assumed once-per-ten-block interval.

• 11 · Glossary and source trail7

  Use the source hierarchy: owner-approved rule for current consensus intent; executable reference/C++ for implemented behavior; recorded raw results for measurements; prose summaries for navigation only.

  • Shard / lane / field0

    Shard: a contiguous message/parity byte block. Lane: a 128-bit internal state pair x,v. GF(256): the finite field used for parity bytes. These are different layers despite sharing binary storage.

  • ROT / XOR / fold / kernel0

    ROT rotates a fixed-width word; XOR adds bits modulo two; the fold XORs rotated lanes into 128 bits; its kernel contains raw-state differences mapped to zero. Kernel membership is an algebraic relation, not a message-producing algorithm.

  • Stamp / nonce / S / Z0

    Stamp: context-derived SHAKE prefix. Nonce: changes the puzzle. S: allowed candidate count. Z: number of shared leading RL digest bits. Z_base: minimum acceptance parameter; Z_commit: leading-zero threshold for commitment PoW.

  • Proof / root / trust anchor0

    A proof reconstructs a commitment from a leaf and siblings. The bound root also commits to count. The expected root must be authenticated through chain validation/trust assumptions; a root supplied only by the proof sender proves nothing about a particular accepted block.

  • Collision / preimage / second preimage0

    Collision: find any distinct pair with equal complete digests. Preimage: match a specified digest. Second preimage: replace a specified message with another hashing identically. Their attack targets and generic costs differ; a truncated Rad is a separate target.

  • Primary local sources0

    REFRACTING-LIGHT-SPEC.md §1–5 and §8; e46/src/rl.cpp and rl_detail.hpp; refracting_light_v3.py; phase3_sat_attacks.py concrete functions; CHAIN-DESIGN.md §2b/§2f/§2g/§4; PHASE3-RESULTS.md §H–L; WO-01/02/04/03b reports; WORK-ORDERS.md; DECISIONS-NEEDED.md. Source fingerprints accompany this map.

  • Reading checkpoint0

    Can you explain why GF multiplication is not ROT; why P/Q can be silent; why a fold kernel is not yet a message attack; why S changes Rad yield; why IDs sort bytewise but pair indices sort numerically; and why Merkle inclusion is not full validation? If yes, the important layer boundaries are in view.

• 12 · Workflow master list — how the build runs10

  Everything about HOW the chain gets built: the relay loop, the 8-step workflow, the rules, where each work order stands, and the decisions log. Source: WORK-ORDERS.md, WORKFLOW-LOW-TOKEN.md, DECISIONS-NEEDED.md. Updated 8 Oct 2026.

  • [PROCESS] The relay loop0

    You paste one order into ChatGPT → it builds on its own branch → replies DONE WO-NN or BLOCKED WO-NN → you tell Claude one line → Claude checks (decisions file first, diff, build, tests, sanitizers, surprise exam) → PASS: next order; FAIL: fix note back to ChatGPT. Source: WORKFLOW-LOW-TOKEN.md.

  • [PROCESS] The 8-step workflow0

    1 SPEC → 2 GOLDEN (Python reference + frozen vectors) → 3 C++ → 4 MATCH byte for byte (+1,000 random) → 5 HARDEN (warnings = errors, ASan/UBSan, fuzz) → 6 MEASURE (≤ 4 workers) → 7 REPORT → 8 REVIEW: Claude re-runs everything plus a surprise exam with an unrecorded seed; then owner approval. Source: WORK-ORDERS.md.

  • [PROCESS] Start-here rules 1–70

    1 git baseline first · 2 fixed order · 3 one WO per branch with its report · 4 new code under e46/ · 5 stop and ask before installs, long runs, unclear spec · 6 write every question into DECISIONS-NEEDED.md, reply BLOCKED · 7 never rewrite history or delete files (added 8 Oct after 89 owner files vanished; restored from backup/making-it-better-9d73bc6).

  • [PROCESS] Golden files and the surprise exam0

    Golden vectors are public and frozen: never edited to make a test pass (any change in e46/golden/ is a red flag). The surprise exam uses fresh random inputs from a seed that is never written down, so nobody can pre-fit them (held-out test).

  • [STATUS] Done (PASS)0

    WO-01 RL v3 C++ library · WO-02 SHAKE256/KMAC256 (built by Claude) · WO-04 Bech32m · WO-03 Merkle + event roots · WO-03b count-bound roots · WO-08 Rad engine + prototype · WO-14 Grover re-run · WO-05 addresses and IDs · WO-06 header, PoW, ASERT · WO-07 emission, pools, E46i · WO-11 SLH-DSA keys + KMAC · WO-12 transactions · WO-10 genesis miner · WO-09 Block QTL. Branches stack: main → wo-01 → wo-02 → wo-04 → wo-03 → wo-03b → wo-08 → wo-14 → wo-05 → wo-06 → wo-07 → wo-11 → wo-12 → wo-10 → wo-09.

  • [STATUS] Building now0

    Node and P2P (to be ordered); WO-13b with the wallet/GUI.

  • [PLAN] Queued, in order0

    WO-06 header + PoW + ASERT → WO-07 emission, pools, E46i → WO-11 SLH-DSA keys (needs owner OK to install liboqs) → WO-12 transactions → WO-09 Block QTL commitments → WO-10 genesis miner + chainparams → WO-13 QTL v2 port (SHAKE/KMAC, dual delay). Then: local testnet on RL v3.

  • [PLAN] Later and notes0

    WO-15 (note): CGMiner/BFGMiner drivers (GPL forks), stratum, example pool, example explorer. Later: P2P (Tor/I2P behind build flags, off), GUI wallet (FIDO2 optional), Quantum Rads (by consensus), RL W and shard variants (after local testnet).

  • [REVIEW] Decisions log0

    Resolved: #1 event IDs/sorting · #2 count seal · #3 Paradox A · #11 S = 2^20 puzzle · #12 full-scan wording · #13 next-tier collision block · #14 Grover toy widths Python-only · #15 wtxid raw-only. Held for Sunday (Paradox II): #4–#10 + "112 steps" wording. Source: DECISIONS-NEEDED.md.

  • [STATUS] Sunday checklist0

    Full WO-01 review · Paradox II wording fixes (before/after for each) · choose Z_base 40 or 41 · blindfold quiz (5 questions, MAPS/SUNDAY-QUIZ.md).

• 13 · Spec sheet — CHAIN-DESIGN at a glance14

  WHAT the chain is, section by section, with the confirmed numbers. One node per section of CHAIN-DESIGN.md; open the file for the exact rules. Values marked provisional are measured or decided later. Updated 8 Oct 2026.

  • [SPEC] §0 Names0

    E46 = the coin · E46 / Tessera = toolkit and art · Rads = collision events (RRAD regular, QRAD quantum later) · Z-level = matching leading bits · E46 Life Tokens · E46i = irradiated Rad rewards · neutrino = 10^-8 E46, the smallest unit.

  • [SPEC] §1 Primitives0

    Proof-of-work: RL v3 (experimental). IDs, Merkle, shared addresses, stamps: SHAKE256 (SHA-3 family). Signatures: SLH-DSA-SHAKE-128s (FIPS 205, hash-based, no lattices). Key derivation: KMAC256. Policy: no SHA-2 anywhere in chain code.

  • [SPEC] §2 Blocks and timing0

    150 s blocks · 4 MB · ASERT difficulty, half-life 7,200 s, integer-only · genesis at one-laptop difficulty · no minimum-difficulty fallback · median-time-past + 15-min future limit · coinbase maturity 100.

  • [SPEC] §2a Addresses and IDs0

    Bech32m. Mainnet/testnet: e46/te46 single (RL v3 128 ‖ SHAKE256 128) · tes/tess shared k-of-n · e46tx · e46blk · e46rad · e461z… Block QTL. Version char q = v0, p = reserved hash switch, z = Block QTL. wtxid raw-only (e46wtx reserved).

  • [SPEC] §2b Header and Merkle roots0

    Header 120 bytes: version · prev_block · merkle_root · event_root · u64 time · bits · u64 nonce. PoW: RL_v3(header) ≤ target; block ID SHAKE256. Merkle tags 0x00 leaf, 0x01 node, 0x02 count seal; odd node carried up; empty = 32 zero bytes.

  • [SPEC] §2c–2d Checkpoints and chainparams0

    Checkpoints per release, ≥ 1,000 blocks deep, signed on a dedicated offline laptop; no rolling checkpoints. Chainparams: prefixes, 150 s, ASERT 7,200 s, 4 MB, maturity 100, decay epoch 17,280, k 20, T 46 M, 80/10/10, N 576, Z 0.1, L 200; network magic/ports/seeds deferred to P2P.

  • [SPEC] §2e Transactions and scriptPubKey0

    UTXO. Witnesses separate (txid excludes signatures). Output types: 0x00 single · 0x01 shared k-of-n (n ≤ 15) · 0x02 stake lock · 0x03 data ≤ 80 B · 0x04 Block QTL single. SLH-DSA: pk 32 B, sig 7,856 B (verify vs FIPS 205). Sighash commits to spent values.

  • [SPEC] §2f Block QTL (opt-in)0

    Commit C (hides key and signature) with an 18-bit RL stamp instead of a fee → wait 6 blocks → reveal; valid only if C is 6–2,016 blocks deep. z-addresses only; ordinary addresses spend immediately. Guy Fawkes protocol / FawkesCoin.

  • [SPEC] §2g Serialization0

    Integers little-endian; Bitcoin CompactSize, minimal only; hex shown in byte order. Block = header ‖ txs ‖ events. Rad event 82 B (a, b = u64 index ‖ 8 zero bytes); commit event 41 B; events sorted by (type, ID), duplicates invalid.

  • [SPEC] §3 Emission0

    Monthly decay events (17,280 blocks): reward = max((T − emitted) >> 20, 1 neutrino). T = 46,000,000; first reward 43.87 E46; half-life 3.46 y. Pools stop filling ~year 100, neutrino floor ~114, T fully emitted ~118, then 1 neutrino per block forever. Clamp remaining at zero.

  • [SPEC] §4 Radium (Rads)0

    Stamp = SHAKE256(prev block ‖ window ‖ miner ‖ nonce). Fixed puzzle: S = 2^20 candidates per nonce. Z_base ≈ 41 provisional (measured 9.3 Rads/block; 40 gives 25.4). Tiers every 8 bits. Collision block = a Rad at the next tier above Z_base (48) ≈ every 9.9 blocks (model). Paradox A: measure on the real format.

  • [SPEC] §5 Pools and Life Tokens0

    Each reward: 80% miner · 10% N-pool (staking; stake ≤ 576 × subsidy; lock timeout 200 blocks) · 10% Z-pool (Rad finders by energy; ≤ 0.1 × subsidy each). Pools never mint. E46i halves every decay epoch until spent (v >> epochs). Fusion: 2 tokens of one tier → 1 of the next.

  • [SPEC] §6–7 Decisions and security0

    §6 lists every confirmed parameter and what is still open (P2P, RL W). §7 security checklist S1–S17: 51% / reorgs, timewarp, selfish mining, Merkle malleability, RL weakness (emergency fork to SHAKE256 PoW), supply overflow, pool accounting, staking abuse, genesis fairness, determinism, signatures, quantum, P2P, QTL, ASIC-friendliness.

  • [PLAN] §9 Refracting Light W0

    Planned successor: 1024-bit state (8 lanes) folded to 512 bits; ≈ 2× slower; untested. Adopted only after the full Phase 3 suite, a step-reversal test and outside review. Local testnet runs RL v3 first.