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 |
|---|---|---|
building, signing and checking a payment |
6 of 6 ✅ |
|
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 |
|
How a count is written in as few bytes as possible, and why a “signpost” byte moves the rest along without overwriting anything |
2 |
|
Why every signature and address carries its length in front |
3 |
|
Labelled fingerprints, why “txid vs wtxid” is not a hunt, and the no-SHA-2 rule |
4 |
|
Coins are slots in old transactions; inputs point at them like cheque numbers; change and fees; post-dated payments with lock_time |
5 |
|
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