{ "id": "n112", "title": "Refracting Light v3 → Rads → Two Merkle Roots", "ideas": { "1": { "id": "n006", "title": "01 · Orientation — what goes where", "ideas": { "1": { "id": "n001", "title": "[CODE] The main path", "attr": { "note": "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." } }, "2": { "id": "n002", "title": "[PLAN] The Rad path", "attr": { "note": "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." } }, "3": { "id": "n003", "title": "[CODE] The transaction path", "attr": { "note": "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." } }, "4": { "id": "n004", "title": "[REVIEW] “ROT alternating shards” needs precise names", "attr": { "note": "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." } }, "5": { "id": "n005", "title": "[STATUS] Where this session stands", "attr": { "note": "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)." } } }, "attr": { "note": "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." } }, "2": { "id": "n018", "title": "02 · Binary → polynomials → six-shard record", "ideas": { "1": { "id": "n007", "title": "[CODE] Bytes first; bits are read MSB first", "attr": { "note": "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." } }, "2": { "id": "n008", "title": "[CODE] Four contiguous data shards", "attr": { "note": "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." } }, "3": { "id": "n009", "title": "[MATH] A byte is also a polynomial", "attr": { "note": "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." } }, "4": { "id": "n010", "title": "[CODE] GF(256), modulus 0x11d", "attr": { "note": "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." } }, "5": { "id": "n011", "title": "[CODE] xtime example: 0x80 × 2 = 0x1d", "attr": { "note": "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." } }, "6": { "id": "n012", "title": "[CODE] P parity: equal weights", "attr": { "note": "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." } }, "7": { "id": "n013", "title": "[CODE] Q parity: weights 1, 2, 3, 4", "attr": { "note": "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." } }, "8": { "id": "n014", "title": "[MATH] What the RS-style protection actually buys", "attr": { "note": "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." } }, "9": { "id": "n015", "title": "[MATH] P/Q-silent differences remain possible", "attr": { "note": "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." } }, "10": { "id": "n016", "title": "[CHECKED] Four-byte worked example", "attr": { "note": "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." } }, "11": { "id": "n017", "title": "[CODE] Empty input has a defined path", "attr": { "note": "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." } } }, "attr": { "note": "This stage is deterministic encoding and redundancy. It is not encryption, a random-number generator, or extra message entropy." } }, "3": { "id": "n029", "title": "03 · RedTail outward map and the rotation engine", "ideas": { "1": { "id": "n019", "title": "[CODE] Initial state and signed digits", "attr": { "note": "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." } }, "2": { "id": "n020", "title": "[MATH] “Outward” is not saturation to ±infinity", "attr": { "note": "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." } }, "3": { "id": "n021", "title": "[CODE] Stage A: accumulate z", "attr": { "note": "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." } }, "4": { "id": "n022", "title": "[CODE] Stage B: outward, quotient and remainder", "attr": { "note": "(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." } }, "5": { "id": "n023", "title": "[CODE] Stage C: update v", "attr": { "note": "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." } }, "6": { "id": "n024", "title": "[CODE] Stage D: update x", "attr": { "note": "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." } }, "7": { "id": "n025", "title": "[CODE] Update all lanes simultaneously", "attr": { "note": "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." } }, "8": { "id": "n026", "title": "[MATH] Rotations themselves are reversible and linear", "attr": { "note": "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." } }, "9": { "id": "n027", "title": "[CODE / MEASURED] Eight blank finalization steps", "attr": { "note": "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." } }, "10": { "id": "n028", "title": "[CODE] Exact step budget by message size", "attr": { "note": "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." } } }, "attr": { "note": "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." } }, "4": { "id": "n038", "title": "04 · Four rotated lanes → one folded digest", "ideas": { "1": { "id": "n030", "title": "[CODE] Unfolded view", "attr": { "note": "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." } }, "2": { "id": "n031", "title": "[CODE] Folded view", "attr": { "note": "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.”" } }, "3": { "id": "n032", "title": "[MATH] Rank 128; kernel dimension 384", "attr": { "note": "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." } }, "4": { "id": "n033", "title": "[MATH] Explicit raw-state cancellation", "attr": { "note": "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." } }, "5": { "id": "n034", "title": "[REVIEW] The real fold-attack question", "attr": { "note": "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." } }, "6": { "id": "n035", "title": "[MATH] Two kinds of full collision", "attr": { "note": "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." } }, "7": { "id": "n036", "title": "[MODEL] Width is not a measured security level", "attr": { "note": "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." } }, "8": { "id": "n037", "title": "[MATH] Hashing has no decryption key", "attr": { "note": "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." } } }, "attr": { "note": "This is the actual compression boundary. Keep final-state relations separate from reachable message relations." } }, "5": { "id": "n051", "title": "05 · Attack map — what has and has not been tested", "ideas": { "1": { "id": "n039", "title": "[MODEL] Diagnostic truncation", "attr": { "note": "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." } }, "2": { "id": "n040", "title": "[MEASURED] v2 fold-cancellation classes", "attr": { "note": "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." } }, "3": { "id": "n041", "title": "[MEASURED] v3 follow-up", "attr": { "note": "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." } }, "4": { "id": "n042", "title": "[MEASURED] Last-step structure and the v3 response", "attr": { "note": "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." } }, "5": { "id": "n043", "title": "[MEASURED] SAT and reduced variants", "attr": { "note": "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." } }, "6": { "id": "n044", "title": "[MEASURED] Truncated collisions through 64 bits", "attr": { "note": "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." } }, "7": { "id": "n045", "title": "[REVIEW] Remaining classical attack routes", "attr": { "note": "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." } }, "8": { "id": "n046", "title": "[REVIEW] Domain separation and serialization attacks", "attr": { "note": "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." } }, "9": { "id": "n047", "title": "[REVIEW] More pairs per nonce are not automatically an attack", "attr": { "note": "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." } }, "10": { "id": "n048", "title": "[MEASURED / MODEL] Grover table simulation", "attr": { "note": "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." } }, "11": { "id": "n049", "title": "[MODEL] Full-width quantum costs need an oracle", "attr": { "note": "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." } }, "12": { "id": "n050", "title": "[REVIEW] What would count as a useful attack result?", "attr": { "note": "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." } } }, "attr": { "note": "Use this branch as an audit checklist. A passing test means that experiment passed on its sampled inputs, not that every attack is excluded." } }, "6": { "id": "n063", "title": "06 · The bounded Rad construction", "ideas": { "1": { "id": "n052", "title": "[SPEC] Bind the search to its context", "attr": { "note": "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." } }, "2": { "id": "n053", "title": "[SPEC] Candidate index → 16 bytes", "attr": { "note": "candidate(i)=u64_LE(i) || eight zero bytes, with 0≤i0: 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." } }, "6": { "id": "n079", "title": "[MATH] Root tag 0x02 and Rad type 0x02 do not conflict", "attr": { "note": "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." } }, "7": { "id": "n080", "title": "[CODE] Proof record", "attr": { "note": "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." } }, "8": { "id": "n081", "title": "[MEASURED] The count ambiguity and fix", "attr": { "note": "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." } }, "9": { "id": "n082", "title": "[CODE / REVIEW] Empty tree is not an inclusion proof", "attr": { "note": "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." } }, "10": { "id": "n083", "title": "[CODE] 120-byte header layout", "attr": { "note": "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." } }, "11": { "id": "n084", "title": "[CODE / PLAN] RL PoW versus SHAKE block ID", "attr": { "note": "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." } }, "12": { "id": "n085", "title": "[REVIEW] Light-client boundary", "attr": { "note": "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." } } }, "attr": { "note": "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." } }, "9": { "id": "n092", "title": "09 · Three different meanings of “collision”", "ideas": { "1": { "id": "n087", "title": "[SPEC] Intended Rad collision", "attr": { "note": "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." } }, "2": { "id": "n088", "title": "[REVIEW] Unintended complete hash collision", "attr": { "note": "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." } }, "3": { "id": "n089", "title": "[CODE] Duplicate event ID", "attr": { "note": "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." } }, "4": { "id": "n090", "title": "[MATH] Merkle commitments bind bytes, not truth", "attr": { "note": "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." } }, "5": { "id": "n091", "title": "[REVIEW] Mining advantage is a consensus risk", "attr": { "note": "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." } } }, "attr": { "note": "Keep these concepts separate when interpreting an attack log or Rad count." } }, "10": { "id": "n103", "title": "10 · Build gates and attack checklist", "ideas": { "1": { "id": "n093", "title": "[DONE LOCALLY] Foundation evidence", "attr": { "note": "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." } }, "2": { "id": "n094", "title": "[IN PROGRESS] WO-08 Python source", "attr": { "note": "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." } }, "3": { "id": "n095", "title": "[NEXT] Freeze, implement, match", "attr": { "note": "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." } }, "4": { "id": "n096", "title": "[NEXT] Negative verification cases", "attr": { "note": "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." } }, "5": { "id": "n097", "title": "[NEXT] Mining prototype and calibration", "attr": { "note": "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." } }, "6": { "id": "n098", "title": "[NEXT] Harden and report", "attr": { "note": "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." } }, "7": { "id": "n099", "title": "[LATER] WO-14 on built libraries", "attr": { "note": "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." } }, "8": { "id": "n100", "title": "[DEFERRED] Items #4–#10, Sunday", "attr": { "note": "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." } }, "9": { "id": "n101", "title": "[REVIEW] Full scan is a harness choice, not proved work", "attr": { "note": "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." } }, "10": { "id": "n102", "title": "[REVIEW] Collision-block frequency", "attr": { "note": "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." } } }, "attr": { "note": "This branch connects the map to the current WO-08 work. It does not authorize skipping the manual owner → builder → Claude review relay." } }, "11": { "id": "n111", "title": "11 · Glossary and source trail", "ideas": { "1": { "id": "n104", "title": "Shard / lane / field", "attr": { "note": "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." } }, "2": { "id": "n105", "title": "ROT / XOR / fold / kernel", "attr": { "note": "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." } }, "3": { "id": "n106", "title": "Stamp / nonce / S / Z", "attr": { "note": "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." } }, "4": { "id": "n107", "title": "Proof / root / trust anchor", "attr": { "note": "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." } }, "5": { "id": "n108", "title": "Collision / preimage / second preimage", "attr": { "note": "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." } }, "6": { "id": "n109", "title": "Primary local sources", "attr": { "note": "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." } }, "7": { "id": "n110", "title": "Reading checkpoint", "attr": { "note": "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." } } }, "attr": { "note": "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." } }, "12": { "id": "n225", "title": "12 · Workflow master list — how the build runs", "ideas": { "1": { "id": "n201", "title": "[PROCESS] The relay loop", "attr": { "note": "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." } }, "2": { "id": "n202", "title": "[PROCESS] The 8-step workflow", "attr": { "note": "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." } }, "3": { "id": "n203", "title": "[PROCESS] Start-here rules 1–7", "attr": { "note": "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)." } }, "4": { "id": "n204", "title": "[PROCESS] Golden files and the surprise exam", "attr": { "note": "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)." } }, "5": { "id": "n205", "title": "[STATUS] Done (PASS)", "attr": { "note": "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." } }, "6": { "id": "n206", "title": "[STATUS] Building now", "attr": { "note": "Node and P2P (to be ordered); WO-13b with the wallet/GUI." } }, "7": { "id": "n207", "title": "[PLAN] Queued, in order", "attr": { "note": "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." } }, "8": { "id": "n208", "title": "[PLAN] Later and notes", "attr": { "note": "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)." } }, "9": { "id": "n209", "title": "[REVIEW] Decisions log", "attr": { "note": "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." } }, "10": { "id": "n210", "title": "[STATUS] Sunday checklist", "attr": { "note": "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)." } } }, "attr": { "note": "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." } }, "13": { "id": "n226", "title": "13 · Spec sheet — CHAIN-DESIGN at a glance", "ideas": { "1": { "id": "n211", "title": "[SPEC] §0 Names", "attr": { "note": "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." } }, "2": { "id": "n212", "title": "[SPEC] §1 Primitives", "attr": { "note": "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." } }, "3": { "id": "n213", "title": "[SPEC] §2 Blocks and timing", "attr": { "note": "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." } }, "4": { "id": "n214", "title": "[SPEC] §2a Addresses and IDs", "attr": { "note": "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)." } }, "5": { "id": "n215", "title": "[SPEC] §2b Header and Merkle roots", "attr": { "note": "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." } }, "6": { "id": "n216", "title": "[SPEC] §2c–2d Checkpoints and chainparams", "attr": { "note": "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." } }, "7": { "id": "n217", "title": "[SPEC] §2e Transactions and scriptPubKey", "attr": { "note": "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." } }, "8": { "id": "n218", "title": "[SPEC] §2f Block QTL (opt-in)", "attr": { "note": "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." } }, "9": { "id": "n219", "title": "[SPEC] §2g Serialization", "attr": { "note": "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." } }, "10": { "id": "n220", "title": "[SPEC] §3 Emission", "attr": { "note": "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." } }, "11": { "id": "n221", "title": "[SPEC] §4 Radium (Rads)", "attr": { "note": "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." } }, "12": { "id": "n222", "title": "[SPEC] §5 Pools and Life Tokens", "attr": { "note": "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." } }, "13": { "id": "n223", "title": "[SPEC] §6–7 Decisions and security", "attr": { "note": "§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." } }, "14": { "id": "n224", "title": "[PLAN] §9 Refracting Light W", "attr": { "note": "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." } } }, "attr": { "note": "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." } } }, "attr": { "note": "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." }, "formatVersion": 3 }