Learn by exam

Two hands-on exams you can read, run and change. Both run in seconds, use a fresh random seed each time (a surprise exam), and have a --debug mode that prints the raw bytes so you can see what each test checks.

Exam

What it tests

Result

1. A real transaction

building, signing and checking a payment

6 of 6 ✅

2. The hash itself

Refracting Light v3, E46’s proof-of-work hash

6 of 6 ✅

Exam 1: how an E46 transaction works

A hands-on file you can read, run and change: e46/tests/exam_wo12.py. It builds real E46 transactions, byte by byte, signs them with real post-quantum keys, and asks the node’s own checker to accept or reject them.

It was written one function at a time by the project owner and Claude. Every step was explained, questioned and rewritten in plain English before it was saved, so the comments answer the questions a newcomer actually asks. Set aside an hour to read it before you run it; the comments are the point.

What you’ll learn

Step

Function

The idea, in one line

1

compact_size

How a count is written in as few bytes as possible, and why a “signpost” byte moves the rest along without overwriting anything

2

varbytes

Why every signature and address carries its length in front

3

tagged_hash

Labelled fingerprints, why “txid vs wtxid” is not a hunt, and the no-SHA-2 rule

4

serialize_input / _output / _tx

Coins are slots in old transactions; inputs point at them like cheque numbers; change and fees; post-dated payments with lock_time

5

sighash

Exactly what your key signs, and why it includes the coins you’re spending

6

keys, lock, signing

Real SLH-DSA keys from one backup seed; the address lock computed in pure Python

7

the exam

Six real transactions judged by the C++ checker

The result (8 October 2026)

Test

What we built

Checker said

A

honest payment: 10.00 in, 7.00 + 2.99 out

✅ ACCEPT

A2

spend a coin worth the full supply, pay out exactly that

✅ ACCEPT

S

test A with one signature bit flipped

✅ REJECT

B1

one output of the full supply + 1 base unit

✅ REJECT

B2

two outputs that together pass the full supply

✅ REJECT

B3

pay out more than you spend

✅ REJECT

6 of 6 passed, in about 3 seconds. Because A and A2 pass with the same keys, format and real signatures, B1–B3 can only have been rejected by the amount rules: the guard against Bitcoin’s 2010 bug that created 184 billion BTC.

Run it yourself

From the repository root, after building the C++ tools (cmake --preset release, then cmake --build --preset release):

python3 -I e46/tests/exam_wo12.py

It uses only Python’s standard library and the repository’s own pure-Python Refracting Light reference. The one exception is signing: Python has no built-in SLH-DSA, so it calls the project’s C++ key tool (decision #19).

Try changing it: flip a different byte, pay 46,000,000.00000001 E46, or add a third output, and see what the checker says.

Exam 2: Refracting Light v3, the hash itself

e46/tests/exam_rl_v3.py puts E46’s own proof-of-work hash through six tests, comparing the pure-Python reference with the C++ library the node uses.

What “avalanche” means

Like a snow avalanche: one small push at the top, and the whole slope comes down. For a hash, one tiny change to the input, a single bit, should change about half of the output, in places nobody can predict. The two results then look completely unrelated, so an attacker learns nothing by nudging the input.

"hi"  ->  111C0591 5036A35F EED5CE70 A5DE0C5B
"hj"  ->  45F16FED 03919A82 362D5322 4D9026D5     one letter changed, 69 of 128 bits differ
flipped   0101010011101101011010100111110001010011101001110011100111011101
          1101100011111000100111010101001011101000010011100010101010001110
          (1 = this bit flipped: scattered everywhere, no pattern)

The Hawking radiation link (owner’s note). In physics, a black hole slowly leaks Hawking radiation, and the great open question, the “information paradox”, is whether everything that fell in can, in principle, be recovered from that scrambled radiation. Refracting Light borrows the picture: the 128-bit digest is the radiation, and the 384 hidden bits are the black-hole core. So “can a digest be translated back to its message?” is E46’s own version of the paradox, and it’s exactly mission v1, Decrypt Hawking Radiation. Today’s answer: nobody knows how, every test so far says it holds up, and E46 invites the world to try. (A picture, not physics: the hash is ordinary integer maths.)

Every txid is a mirror (owner’s note). A txid is a fixed reflection of its transaction: anyone holding the transaction can recompute it and check the reflection matches; change anything (an amount, an address, the date) and the reflection changes completely (avalanche); but you can’t step through the mirror and rebuild the transaction from the txid (one-way). It pairs with the event-horizon picture: the txid mirrors the payment’s body, and the witness sits behind it, there but outside the reflection.

Not a crypto oracle. “Oracle” means two different things, and E46 only means the second:

“Oracle” means…

Does a txid fit?

Crypto-industry oracle: something that feeds outside facts into a chain (prices, weather, sports scores)

❌ No. E46 has no price-feed or data oracle. A txid brings nothing in from outside; it only reflects the transaction.

Cryptographers’ “random oracle”: an imaginary perfect box that answers every new question with a fresh random answer, and the same question with the same answer every time

✅ Yes, as a model. That’s how cryptographers treat hash functions in security proofs (SLH-DSA’s proofs are “in the random oracle model”). Each txid is the oracle’s answer for that transaction. Whether Refracting Light truly behaves like one is the open question: mission v1.

The six tests

Test

The question

Result (8 Oct 2026)

1 two_ways

Do Python and C++ agree on every message?

✅ 559 of 559

2 in_pieces

Does hashing in chunks (1, 7, 64 bytes) equal hashing whole?

✅

3 avalanche

Flip one input bit: do about 64 of 128 output bits flip?

✅ average 64.02

4 balance

Is every output bit 1 about half the time?

✅ all 47.5%–52.4%

5 length

Is “abc” different from “abc” + one zero byte?

✅

6 mini_rad

Does a 24-bit collision (a tiny Rad) take as long as the birthday maths predicts, about 5,100 tries?

✅ 1.05× the prediction

Seeing it: the debug run

TEST 1  two_ways: Python and C++ must agree
  b'hi'      python 111C0591 5036A35F EED5CE70 A5DE0C5B
             C++    111C0591 5036A35F EED5CE70 A5DE0C5B  same

TEST 2  in_pieces: chunks must equal the whole
  whole          A89B4DE6 544723F9 61D15AFD 8E7C4248
   1-byte chunks A89B4DE6 544723F9 61D15AFD 8E7C4248
  64-byte chunks A89B4DE6 544723F9 61D15AFD 8E7C4248

TEST 5  length: a message and the same + one zero byte
  'abc'        826E57DD 2B187132 A8DD2B84 11E32DAE
  'abc' + 00   FA5499B5 725BE6BA 9FA4A94B 28485D85

TEST 6  mini_rad: two messages whose digests share the top 24 bits
  message A  ->  ACBD7947 491E5E23 FF9E803F D4CC7822
  message B  ->  ACBD7975 653BEC12 EA90764C 55B1195E
                 ^^^^^^ the first 6 hex characters (24 bits) match

A single mini-Rad search varies a lot (this one took 10,537 tries; others take 3,900), like rolling dice. The real exam averages 20 searches, which lands close to the prediction. On the live chain, Rads use 41+ bits; a hash that found them much faster than predicted would be leaking structure, and everyone could see it.

Honest limits

These tests catch obvious flaws: a broken implementation, a lazy mixer, a biased output. Passing them does not prove Refracting Light is secure; no test can. That’s why mission v3 invites people to attack it.

python3 -I e46/tests/exam_rl_v3.py
python3 -I e46/tests/exam_rl_v3.py --debug