E46 / Tessera¶
An experimental post-quantum test chain built around a new proof-of-work hash, Refracting Light v3. The last thing Bitcoin teams should look at. The first thing we should test for them.
“A Blackhole, Shaken & Not Stirred Captain…”
The whole story in one document. Everything below is the short, plain-English version.
Science and replication: reproduce the genesis block with the Genesis Hasher.
Block 0, decoded: the Commander's write-up of the testnet genesis timestamp, coinbase, header, hashes, and proof of work.
The design, decoded: why every piece exists, where the quantum and black-hole ideas came from, and what is (and isn't) really quantum.
Learn by exam: build, sign and test a real E46 transaction, then put the Refracting Light hash itself to the test, explained line by line in plain English.
Golden numbers: every key constant, plus the frozen test files anyone can check their own code against.
Core missions¶
Mission |
In plain English |
|---|---|
v1: Decrypt Hawking Radiation |
Black holes slowly leak “Hawking radiation”. Physicists still ask whether the information that fell in comes back out, scrambled like an encrypted message. E46 borrows that picture: Rads are decay events, and scrambling and unscrambling information is the whole job of a hash. For anyone interested: the KITP lecture series (UC Santa Barbara); one of its talks covers Hawking radiation. |
v2: Anti-Quantum |
Build every part to survive a future quantum computer: post-quantum signatures (SLH-DSA), no SHA-2, and security sizes chosen with Grover’s algorithm in mind. |
v3: Hack my chain, so Bitcoin can last forever |
E46 is a target on purpose. Every weakness found here, in a test chain with no real money, is a lesson Bitcoin can use without paying for it. Please try to break it, and tell us how. |
v4: Honest evidence |
Every claim on this site must match a test someone can rerun. When the evidence is weaker than the words, we fix the words. |
The core of the chain, in plain English¶
E46 is a test blockchain. It works like Bitcoin in the basics: people called miners bundle payments into blocks, and each block points to the one before it, making a chain. A new block arrives about every 2½ minutes. Coins have no real-world value; the point is to learn and to test new ideas safely.
Three ideas make E46 different. This page explains each one without maths.
1. Rads: tiny “radioactive” events found while mining¶
To mine a block, a miner’s computer makes guess after guess, looking for a lucky result. While doing that, it can also notice something rarer: two different inputs whose hashes start with the same long run of bits. That near-match is called a Rad (short for Radium, like a decay event in a Geiger counter).
Why it’s fair: each Rad is tied to the block it was found in and to the miner’s own address. Nobody can find Rads in advance, and nobody can steal someone else’s Rad: changing the address breaks the match.
Why it’s checkable: finding a Rad takes about a million hashes; checking one takes 2.
Rarity (Z-level): the more bits match, the rarer the Rad. Each extra bit is twice as rare. A typical block is expected to hold about 9 Rads at the starting level.
What it’s for: Rad finders share 10% of each block reward. And if Rads ever start appearing far more often than maths predicts, everyone can see it: a public early-warning alarm that the hash function has a weakness.
Collision blocks: now and then a block holds an extra-rare Rad (the next “byte tier”, 48 matching bits). That block is special and triggers the staking payout.
2. Two Merkle roots: one fingerprint for payments, one for events¶
A block can hold thousands of items. Instead of listing them all in the small block header, E46 squeezes each list into one 32-byte fingerprint called a Merkle root: items are hashed in pairs, the pairs are hashed in pairs, and so on until one value is left. Change any single item and the root changes.
Bitcoin has one root. E46 has two:
Root |
What it fingerprints |
|---|---|
|
the block’s payments (transactions) |
|
the block’s events: Rads, and time-lock commitments |
Why two: payments and events can be checked separately, and a phone wallet can prove “my payment is in this block” with a short proof, without downloading the whole block.
Why the count is sealed in: each root also locks in how many items it holds, so nobody can fake a shorter or longer list.
Safer than Bitcoin’s design: Bitcoin’s root once allowed two different lists to give the same fingerprint (a 2012 bug). E46 labels leaves and branches differently and never copies an odd item, so that trick is impossible.
3. The wallet entrance: a lock that makes you wait (QTL)¶
Most wallets open the moment you type the right password. That’s convenient, but it means a thief with a fast computer can try billions of passwords quickly.
E46’s research lock, QTL (Quantum Time Lock), adds a time puzzle: a chain of maths steps that must be done one after another. Extra computers don’t help, the way nine people can’t make a baby in one month. Opening the wallet takes about 1 to 5 minutes, for you and for any attacker, on every single try.
Why a correct password still feels instant. The password is checked first, in under a second. If you typed it wrong, you’re told straight away; you never wait 5 minutes just to find out about a typo. Only when the password is right does the puzzle start. The puzzle doesn’t depend on your password, so the early check gives an attacker no shortcut.
QTLO (QTL lockout) and how we stopped it. In version 1, someone who could edit your locked file could quietly make the puzzle huge, so you would wait forever. That’s a lockout. Version 2 checks the cheapest things first: a fingerprint of the file (kept somewhere else), the allowed puzzle sizes, then the password. A tampered file is refused in under a millisecond, and progress is saved at checkpoints so a crash never makes you start over.
Safety rule: QTL protects test data only. It must never lock a door, vehicle or anything a person could be trapped behind.
Try the toy¶
This is a simulation for learning: it does no real cryptography, and the wait is shortened to about 15 seconds. The toy password is tessera. Try a wrong one first.
The real wallet lock will use Argon2 (it makes every password guess cost a lot of memory) plus an optional FIDO2 hardware key (a USB or phone security key you tap), and it keeps the same 1–5 minute time delay.
4. When can I spend my E46?¶
How you got the E46 |
When you can spend it |
|---|---|
Someone sends it to you (an ordinary payment) |
Once it’s in a block, about 2½ minutes. For big amounts, wallets may suggest waiting a few more blocks, as with Bitcoin. |
You mined it: a block reward, a Rad reward (E46i) or a pool payout |
After 100 blocks, about 4 hours (“coinbase maturity”). |
Why only mined coins wait. Sometimes two miners find a block at almost the same moment, and the network keeps only one. The losing block’s reward never existed. If its miner had already spent it, everyone paid with those coins would lose them too, in a chain reaction. Waiting 100 blocks makes that practically impossible. An ordinary payment doesn’t have this problem: if its block is dropped, the same payment simply goes into the next one.
Mined reward: block ──[100 blocks ≈ 4 h]──► spendable
Normal payment: block ──► spendable (≈ 2½ min)
Bitcoin has the same 100-block rule; it takes about 16 hours there because its blocks are slower.
5. How big will the chain get?¶
A block arrives every 150 seconds, so the chain grows by 210,240 blocks a year. Each block is capped at 4 MB, and one payment is about 8 KB, almost all of it the quantum-safe signature. How much disk space the chain needs depends on how busy it is.
How busy |
Per block |
1 year |
3 years |
5 years |
|---|---|---|---|---|
Quiet test chain (Rads, almost no payments) |
~1 KB |
0.2 GB 🟢 |
0.6 GB 🟢 |
1 GB 🟢 |
Small community (10 payments per block) |
~80 KB |
17 GB 🟢 |
50 GB 🟢 |
84 GB 🟢 |
Busy (100 payments per block) |
~800 KB |
170 GB 🟡 |
505 GB 🟡 |
840 GB 🔴 |
Every block full (the hard ceiling) |
4 MB |
840 GB 🔴 |
2.5 TB 🔴 |
4.2 TB 🔴 |
After 1 year
Quiet ▏ 0.2 GB
Community ▍ 17 GB
Busy ████ 170 GB
Full ████████████████████ 840 GB (max possible)
After 3 years
Quiet ▏ 0.6 GB
Community ▍ 50 GB
Busy ████ 505 GB
Full ████████████████████ 2.5 TB (max possible)
After 5 years
Quiet ▏ 1 GB
Community ▍ 84 GB
Busy ████ 840 GB
Full ████████████████████ 4.2 TB (max possible)
Bitcoin, all 16 years ≈ 650+ GB, for comparison
Realistically, a young test chain sits near the top rows: a few gigabytes, which fits on any laptop.
Why the ceiling is high: post-quantum signatures are about 110× bigger than Bitcoin’s. That’s the price of being quantum-safe from block 0.
Built-in relief:
Old signatures can be pruned. They’re kept apart from the txid, so a node that has already checked old blocks can delete their signatures and keep only the small part, about 95% smaller.
The list of unspent coins stays small (about 72 bytes per coin, no signatures), so the part a node must keep fast is megabytes, not gigabytes.
The 4 MB cap sets the ceiling. If it ever looks too big, it can be lowered with a soft fork.
These are estimates from the spec’s sizes, not measurements; WO-12 will give real transaction sizes to check them against.
6. Block 0: where the chain begins¶
Every blockchain starts from one fixed block that every node can rebuild for itself. E46’s testnet block 0 was mined on 8 October 2026:
Headline E46 08/Oct/2026 NASA’s SpaceX Crew‑12 Splashes Down, Sets Briefing to Discuss Mission
Nonce 14,449,748 (about 14 million tries on a laptop)
Block ID 808be9c6 3f218066 409e125a 3a594689 …
Why a headline: it’s a real NASA headline from that day, stored byte for byte inside block 0. It proves the block couldn’t have been made before that date, the same trick Bitcoin used with The Times in 2009.
No premine: block 0 pays 0 E46 to anyone. Its only outputs are the headline and the signature fingerprint.
Anyone can check it: the headline flows into the coinbase transaction, then into its txid, then the Merkle root, then the 120-byte header. Change a single letter and the block ID changes completely.
Checked independently: rebuilt from the spec with separate Python; all 8 values match.
Read the full story: Block 0, decoded, the Commander’s write-up, from headline to header bytes.
Explore¶
Choose your path:
The white paper: the whole story, start to finish.
The spec: every rule, byte and number (§0–§9).
Plain-language glossary, then the mind map below.
Security checklist S1–S17 and the QTL anti-lockout design.
Lost? Open the interactive mind map
(branch 12 = where the build stands, branch 13 = the spec at a glance), or the
decisions log for anything waiting on you.
Need stronger colours? Press ◐ High contrast (bottom right): black background, colour-blind-safe palette, underlined links.
Contact: email Mik3XC at 3xcypher@proton.me. Please let me know if any elements are not visible.
Start here
Specification
- E46 chain design (draft 1)
- 0. Names
- 1. Primitives: experiment where a break is survivable
- 2. Blocks and timing
- 2a. Addresses and IDs (decided 7 Oct 2026)
- 2b. Block header, Merkle roots and the genesis block (proposed for review)
- 2c. Checkpoints (proposed for review)
- 2d. Chain parameters (chainparams)
- 2e. Transactions, coinbase, public keys and scriptPubKey (proposed for review)
- 2f. Block QTL: commit–delay–reveal (opt-in, decided 7 Oct 2026)
- 2g. Serialization: exact bytes (proposed 7 Oct 2026, for review)
- 3. Emission: monthly decay events (no halvings)
- 4. Radium: collision events (Rads) and Z-level
- 5. Supply partition, E46 Life Tokens and the two reward pools
- 6. Decisions
- 7. Security review checklist
- 9. Planned: Refracting Light W (1024-bit state, 512-bit output)
- 8. What this document does not claim
- Genesis, targets and overflow
- Block QTL, decoded
- Golden numbers
- Refracting Light v3: a 128-bit experimental hash for proof-of-work
- Refracting Light v2: formal specification
- QTL v2: anti-lockout (QTLO) design
- UNC Quantum Time Lock construction
- QTL timing formula and glossary
- Result in plain English
- One timing model
- The 312-second example
- Calibration before creating a new lock
- Memory and time
- Why parameters cannot be adjusted during unlock
- Why a local clock-cycle read does not enforce the target
- Relationship to ART QEpoch
- Reserved subformula for physical time dilation
- Glossary and definitions
- Reviewable decision
Build
Work-order reports
- WO-01: quick independent review (Claude)
- WO-01 — Refracting Light C++20 library
- WO-02 — SHAKE256 / KMAC256 wrapper
- WO-03 — Merkle and event roots
- WO-03b — Count-bound Merkle roots
- WO-04 — Bech32m codec
- WO-05 — Addresses and IDs
- WO-06 — Header, PoW, ASERT
- WO-07 — Emission, pools, E46i
- WO-08 — Rad engine and prototype
- WO-10 — Genesis miner and chain parameters
- WO-11 — SLH-DSA keys and KMAC derivation
- WO-12 — Transactions
- WO-14 — Grover re-run on the built libraries
Research notes (5 Oct 2026)
- RedTail clamp modification trials
- Event horizon inspired hash assessment
- Searching for an acceptable hash
- Hayden–Preskill decoder: first experiment
- Keyed unlock research direction
- KITP: Hawking radiation and proposed decoding
- Message encoding and a 64 bit hash
- Outward digit mapping for RedTail
- Refracting Light 128 bit trial
- Refracting Light revision
- Qubits entanglement and radiation recovery
- RedTail polynomials ternary and clamp research
- RedTail experiments with entropy qubits radiation and reflection
