Secure the centuries. Post-quantum, decentralized money.

Multi-worlds
The crypto industry is waking up to post-quantum safety. We never slept.
12
23
74
9,374
A new estimate puts breaking Bitcoin’s signature curve at 19,397 physical qubits. Previous trapped-ion estimates were 1.2–9.4 million. Not because somebody suddenly built a quantum computer 100× better. Because the estimated cost of fault tolerance collapsed. And it wasn’t the only paper this month. Days later, another team estimated RSA-2048 could be factored with roughly 120,800 superconducting qubits in about one month. Neither machine exists today. But that’s not the interesting part. The interesting part is where all those qubits went. 1/ Bitcoin’s curve IonQ compiled Shor’s algorithm against secp256k1 — the elliptic curve behind Bitcoin signatures — down to a proposed trapped-ion architecture: • 19,397 physical qubits • 1,457 logical qubits • ~39 million Toffoli gates • 25.7 days per attempt The paper gives a 40.7% conservative success bound and a 63.3% heuristic estimate. Earlier trapped-ion estimates for the same problem were in the 1.2–9.4 million physical-qubit range. 2/ RSA-2048 Iceberg Quantum took a very different route using superconducting hardware: • 120,820 physical qubits • ~1 month runtime • 10⁻³ assumed physical error rate • 1 μs error-correction cycles Two different cryptographic targets. Two very different quantum architectures. Both now landing in roughly the same order of runtime: weeks, not years. 3/ Where the numbers went Many older resource estimates relied heavily on 2D surface codes for quantum error correction. Surface codes are attractive because they can work with local connectivity. But the physical-qubit overhead is enormous. Both new architectures instead make heavy use of much denser quantum LDPC codes. IonQ gives a particularly striking comparison. Storing roughly 1,500 logical qubits with its surface-code comparison would require about: 243,000 physical qubits just for memory. Its complete qLDPC-based machine — including memory, computation, routing and magic-state infrastructure — comes out at: 19,397 physical ions. Its Q102 code encodes 22 logical qubits into 102 data qubits. Iceberg uses a different construction protecting 16 logical qubits with 510 data qubits, or 1,020 physical qubits when syndrome ancillas are included. The hardware didn’t suddenly leap forward. The fault-tolerance stack got cheaper. That distinction matters. 4/ The necessary reality check These are engineering blueprints, not working quantum computers. IonQ assumes two-qubit error rates around 10⁻⁴ across a large fault-tolerant trapped-ion machine involving thousands of ions, transport and repeated error correction. That has not been demonstrated at this scale. Iceberg assumes 10⁻³ physical errors, 1 μs cycles and degree-8 fixed connectivity, while extrapolating the performance of its full-size code from smaller simulations. And all fourteen authors of the secp256k1 paper work at IonQ. Its hardware assumptions deserve the same scrutiny we would apply to any vendor-authored roadmap. So no: this does not mean Bitcoin can be broken today. But dismissing these papers because the machines don’t exist yet misses the more important signal. Hardware capability is moving upward while the estimated resource threshold for an attack is moving downward. Both sides of the equation are moving. 5/ What does a 26-day attack actually mean for Bitcoin? At this runtime, it is not a practical 10-minute mempool race. The more interesting targets are coins whose public keys are already exposed while the coins remain at rest: • early P2PK outputs • bare multisig • Taproot outputs • reused addresses whose public keys have already been revealed Glassnode recently estimated that roughly 6.04 million BTC — 30.2% of issued supply — is currently exposed at rest under this broader definition. About 1.92M BTC is structurally exposed through output types such as P2PK, P2MS and P2TR. Another 4.12M BTC comes from operational exposure such as address reuse. An attacker doesn’t need to outrun the next block when the relevant public key has already been sitting on-chain for years. 6/ The real problem: migration debt The exact quantum threshold will keep moving. Someone may publish a 10,000-qubit architecture next year. Someone else may discover an overlooked engineering cost and push the estimate back upward. The number is uncertain. The migration problem is not. Moving a live decentralized monetary network from elliptic-curve signatures to post-quantum signatures means much more than choosing another cryptographic primitive. It touches: • wallet and address formats • transaction sizes • validation costs • software compatibility • hardware wallets and custody infrastructure • and legacy UTXOs whose owners may never migrate That is cryptographic migration debt. Tidecoin took a different path. When Tidecoin launched on December 27, 2020, transaction signatures already used Falcon-512 instead of elliptic-curve cryptography. Falcon was later selected by NIST and is now being standardized as FN-DSA. So Tidecoin does not have a legacy ECC transaction-signature set that must someday be swept into post-quantum addresses. Choosing a post-quantum algorithm is only part of the problem. The harder part is surviving the migration. Tidecoin started on the other side of it. The Tide was early.
2
10
22
800
Papers: IonQ — secp256k1 resource estimate, 19,397 trapped-ion qubits / 25.7 days arxiv.org/abs/2609.05625 Iceberg Quantum — RSA-2048, ~120,820 superconducting qubits / ~1 month arxiv.org/abs/2609.21249 We’ll keep reading the quantum-security literature and publishing what actually changes — and what doesn’t.
1
8
201
A new paper (IACR ePrint 2026/2069, "Default Correct") shows how a clock glitch can make ML-KEM/Kyber accept any ciphertext, leading to secret key recovery. We reviewed our implementation against it right away. Tidecoin uses ML-KEM-512 to encrypt P2P connections. The attack needs physical access to the device's clock line and thousands of decapsulations with the same key. It can't be done over the network. Our node generates a fresh ML-KEM key for every connection and uses it for exactly one decapsulation. So even an attacker with physical access has no long-lived key to recover. Tidecoin is not affected. No major ML-KEM library has published a fix for this yet. We're watching upstream closely and will add further hardening. Thanks to the researchers at IIT Bhilai.
2
6
24
530
proof of work
1
11
270
Tidecoin retweeted
post-quantum
Made with AI
3
8
27
576
Falcon is not affected.
Replying to @AnthropicAI
Full technical details of both attacks are provided in our new papers: On HAWK: anthropic.com/document/hawk_… On AES: anthropic.com/document/aes_m… And the associated model chain-of-thought for AES: anthropic.com/document/aes_m…
1
7
21
963
Tidecoin lore hits different now. In 2020, the idea was simple: When the quantum threat became real, there should already be a Bitcoin-like supply of quantum-resistant coins in the wild. Not launched after the panic. Not migrated during the panic. Already mined. BTC: ~20M issued. TDC: ~18.8M issued. The clock was the thesis.
1
14
40
1,473
Falcon is the quiet part of post-quantum crypto. Not the loudest signature scheme. The compact one. Falcon-512: 666-byte signatures. NTRU lattices. NIST-selected. Built for chains where every byte lives forever. Most blockchains still need a migration story. Tidecoin doesn’t. Genesis: December 27, 2020. Falcon from block zero.
2
7
30
1,045
Tidecoin genesis: December 27, 2020. Coinbase message literally quoted the first photonic quantum supremacy paper: Jiuzhang. Not a roadmap. A timestamp. About 1 in 3 BTC is already sitting behind exposed public keys. Post-quantum addresses don’t save a chain retroactively. Old coins still have to migrate. Harvest today. Decrypt tomorrow. Tidecoin started on the other side.
1
10
32
875
While @solana just chose Falcon for post-quantum security… Tidecoin has been running Falcon 512 natively from genesis since Dec 27, 2020. ✅ 5+ years live ✅ 2.3M+ blocks secured ✅ Zero incidents ✅ Smallest PK+sig (~1,563 bytes) ✅ NIST Category 1 quantum resistance
4
18
42
1,049
something something post-quantum safe cryptocurrency vibes
1
7
29
564
Quantum just cracked a 15-bit ECC key on public hardware, winning Project Eleven’s 1 BTC Q-Day Prize. Bitcoin isn't at risk today - 256-bit security still stands. But the tide is clear: post-quantum upgrades are coming. Memetics → awareness → adaptation 🌊 $TDC
1
10
31
702
Happy World Quantum Day!
5
10
31
754
nitter.net/nic_carter/status/2038… New paper from Google Quantum AI, shows breaking ECC-256 may require far fewer quantum resources than previously thought. Tidecoin has been post-quantum since genesis - Dec 2020. Falcon-512 signatures, CPU-mineable, 5+ years live on mainnet. Upcoming: AuxPoW merged mining with LTC @litecoin, ML-DSA multi-scheme support, witness v1 upgrades. 5+ years of post-quantum operation. No retroactive migration needed. We didn't wait.
Replying to @nic_carter
Specifically, this paper. It's a brand new resource estimate that's wildly lower than prior estimates of what it would take to break ECC-256. Featuring the Google Quantum AI team + Justin Drake + Dan Boneh quantumai.google/static/site…
14
17
46
5,027
Official post-quantum secure mobile wallet for the Tidecoin network. Now available on your Android device. play.google.com/store/apps/d…
8
11
54
5,838
Even @VitalikButerin is talking about quantum-resistance. Meanwhile tidecoin is quantum-resistant from genesis and is operating over 5 years. Our thousands years journey has only begun.
Ethereum itself must pass the walkaway test. Ethereum is meant to be a home for trustless and trust-minimized applications, whether in finance, governance or elsewhere. It must support applications that are more like tools - the hammer that once you buy it's yours - than like services that lose all functionality once the vendor loses interest in maintaining them (or worse, gets hacked or becomes value-extractive). Even when applications do have functionality that depends on a vendor, Ethereum can help reduce those dependencies as much as possible, and protect the user as much as possible in those cases where the dependencies fail. But building such applications is not possible on a base layer which itself depends on ongoing updates from a vendor in order to continue being usable - even if that "vendor" is the all core devs process. Ethereum the blockchain must have the traits that we strive for in Ethereum's applications. Hence, Ethereum itself must pass the walkaway test. This means that Ethereum must get to a place where we _can ossify if we want to_. We do not have to stop making changes to the protocol, but we must get to a place where Ethereum's value proposition does not strictly depend on any features that are not in the protocol already. This includes the following: * Full quantum-resistance. We should resist the trap of saying "let's delay quantum-resistance until the last possible moment in the name of ekeing out more efficiencies for a while longer". Individual users have that right, but the protocol should not. Being able to say "Ethereum's protocol, as it stands today, is cryptographically safe for a hundred years" is something we should strive to get to as soon as possible, and insist on as a point of pride. * An architecture that can expand to sufficient scalability. The protocol needs to have the properties that allow it to expand to many thousands of TPS over time, most notably ZK-EVM validation and data sampling through PeerDAS. Ideally, we get to a point where further scaling is done through "parameter only" changes - and ideally _those_ changes are not BPO-style forks, but rather are made with the same validator voting mechanism we use for the gas limit. * A state architecture that can last decades. This means deciding, and implementing, whatever form of partial statelessness and state expiry will let us feel comfortable letting Ethereum run with thousands of TPS for decades, without breaking sync or hard disk or I/O requirements. It also means future-proofing the tree and storage types to work well with this long-term environment. * An account model that is general-purpose (this is "full account abstraction": move away from enshrined ECDSA for signature validation) * A gas schedule that we are confident is free of DoS vulnerabilities, both for execution and for ZK-proving * A PoS economic model that, with all we have learned over the past half decade of proof of stake in Ethereum and full decade beyond, we are confident can last and remain decentralized for decades, and supports the usefulness of ETH as trustless collateral (eg. in governance-minimized ETH-backed stablecoins) * A block building model that we are confident will resist centralization pressure and guarantee censorship resistance even in unknown future environments Ideally, we do the hard work over the next few years, to get to a point where in the future almost all future innovation can happen through client optimization, and get reflected in the protocol through parameter changes. Every year, we should tick off at least one of these boxes, and ideally multiple. Do the right thing once, based on knowledge of what is truly the right thing (and not compromise halfway fixes), and maximize Ethereum's technological and social robustness for the long term. Ethereum goes hard. This is the gwei.
1
7
30
2,716
Tidecoin wallet chrome extension is now available from official chrome webstore. Post-quantum crypto. 5 years. We are early. chromewebstore.google.com/de…
1
7
30
1,706
I'm 5 years old👶
2
5
47
2,128