Refracting Light → Rads → two Merkle roots

7 October 2026 · Learning map and build checkpoint

Subsequent owner update: decisions 12–13 resolved; next-tier trigger approved. This supersedes section 5 below.

Open the interactive map · Complete outline · MindMup export

Read branches 01–11 in order. Expand a branch to see the exact formulas, worked examples, attack boundaries and source references. Search opens matching branches. CODE is inspected implementation; MEASURED is recorded evidence; MATH is a derivation; MODEL is an estimate under assumptions; PLAN/REVIEW is unfinished work or an unresolved claim. This is a source-grounded map, not a replacement consensus specification.

1. Follow one message through RL v3

Message bytes and original length
  → four contiguous data shards D0…D3
  → two polynomial parity shards P and Q
  → encoded record, read one bit at a time
  → signed input digits −16 / +16
  → four coupled lanes, 512 bits of state
  → eight finalization steps
  → rotate/XOR fold
  → 128-bit digest

“ROT alternating shards” needs a distinction. The current implementation does not alternate left/right rotations of input shards. The four data shards are contiguous slices. Rotations act on internal state words and on the four final lanes. Each round updates every lane from the same old state.

A byte can represent a polynomial with binary coefficients. XOR adds those polynomials. Multiplication for the parity layer reduces modulo x^8+x^4+x^3+x^2+1 (0x11d). For example, field multiplication 0x80 × 2 = 0x1d; rotating 0x80 left by one bit gives 0x01. These are different operations.

Per column, P=D0⊕D1⊕D2⊕D3 and Q=D0⊕2D1⊕3D2⊕4D3, using field multiplication. This redundancy does not add entropy or guarantee collision freedom. The map includes a change to three data symbols that leaves both parity symbols unchanged.

The core then uses ordinary signed integer arithmetic, floor division, modular reduction, XOR and rotations. Polynomial arithmetic and state arithmetic must not be conflated. Nor does the outward integer map eliminate collisions after compression.

2. Understand the fold before attacking it

Each final lane is 128 bits. The output is:

H = L0 XOR rot128(L1,29) XOR rot128(L2,61) XOR rot128(L3,97)

This is a linear map from 512 bits to 128 bits. Its kernel has dimension 384: many arbitrary internal states fold to the same output. Branch 04 gives an explicit cancelling state difference.

The unresolved attack is reachability: can an attacker cheaply find two valid messages whose computed states differ by such a cancelling value? Choosing arbitrary state differences is not the same as finding messages that produce them.

Branch 05 separates parity cancellation, reduced-round attacks, related inputs, fold cancellation, complete collisions, truncated collisions and Grover search. Historical v2 results are distinguished from v3 retests. A successful 8-bit or 64-bit prefix collision is not automatically a complete 128-bit collision. Statistical tests and the small table-oracle Grover simulation do not establish full-width security.

3. Turn intentional partial collisions into Rads

The approved bounded domain is:

stamp = SHAKE256-256(context and nonce, with the E46-rad tag)
candidate(i) = u64_LE(i) || eight zero bytes, i < S
ha = RL_v3(stamp || candidate(i))
hb = RL_v3(stamp || candidate(j)), numeric i < j < S
Z = number of equal leading bits in ha and hb

S=2^20 and Z_base≈41 are provisional runtime inputs. All distinct qualifying pairs sharing a nonce are allowed. The verifier checks the domain, ordering, context, declared Z and required threshold. Numeric index order is different from bytewise event-ID order.

Object	Actual RL input length	RL steps
Historical short search	12 bytes	216
One Rad candidate hash	48 bytes	648
Commitment stamp	55 bytes	744
Rad ID	64 bytes	840

This is Paradox A: measurements on short messages cannot be reused as the real puzzle’s mining cost. For independent uniform outputs, a full S-candidate scan has expected pair count S(S−1)/2^(Z+1). At S=2^20, Z=41, that is approximately 0.25 pairs per nonce, not a guaranteed hit or a measured throughput. Multiple hits and zero-hit puzzles are possible.

4. Put Rads beside transactions in the header

Validated transactions → txids → transaction tree → merkle_root ┐
                                                               ├→ block header
Validated Rads/commits → event leaves → event tree → event_root ┘

These are two trees alongside each other, not a Rad tree nested inside the transaction tree. Merkle hashing uses SHAKE256. Tags distinguish leaves (0x00), internal nodes (0x01) and count seals (0x02). For either nonempty tree:

bound_root = SHAKE256-256("E46-merkle\0" || 0x02 || u64_LE(count) || tree_root)

Empty roots are 32 zero bytes. Events sort by type then supplied ID; leaves commit to type || body. WO-08/09 must validate the relationship between the supplied ID and the body. The generic Merkle library does not perform those semantic checks.

A proof establishes membership against an authenticated expected root. The count seal binds the count used in reconstruction; it does not validate every transaction, establish unspent status or make an untrusted header trustworthy. Light-client membership was possible before count binding; the seal adds count authentication.

5. Review points surfaced by the map

New entries 12–13 are recorded in DECISIONS-NEEDED.md and WO-08-REPORT.md:

• A bounded candidate domain does not prove that a miner computed all S hashes. Full-scan cost describes the prototype strategy. Claims about enforced work, fairness and optimal strategy need separate analysis.

• With accepted Rads requiring Z≥Z_base, every accepted Rad already reaches the current byte-tier floor 8·floor(Z_base/8). Thus any block containing an accepted Rad triggers the current collision-block condition. A roughly ten-block interval cannot be assumed independently of the measured valid-Rad rate and inclusion policy.

These do not change the approved formulas. They remain open review items; no new consensus choice was silently made. Earlier items 4–10 remain held for Sunday by the owner.

6. Where the build actually stands

The RL and count-bound Merkle libraries have existing implementation reports. Decision #11 has been resolved. New WO-08 Python reference code and vectors have been generated, not yet frozen or compared against a new C++ Rad engine. No full-size WO-08 Rad calibration has run.

The next implementation flow is: review/freeze the new vectors → C++ stamp/encoding/ID/Z/verifier → differential and rejection tests → release/sanitizer/fuzz gates → real-format calibration → report → independent review. This map does not mark WO-08 complete or authorize moving to WO-14.

Source fingerprints are in the source snapshot; tiny arithmetic examples are in the example results. No new security attack campaign or quantum-hardware run was performed to create this map.