fuckfiat.bit

The developers finding their way to CKB in Q3 are not all starting from scratch. Three teams with production experience elsewhere spent the quarter exploring whether to build here: Lucent Labs, from the Cardano and Midnight ecosystems, working on an open-source order-book DEX; Kaze, active across Bitcoin and Lightning, integrating CKB and Fiber into its geolocation rewards app; and TexLabs, also from Cardano and Midnight, exploring AI and payment channels on CKB. None of them came through a grant program. Full Q3 report 👉 talk.nervos.org/t/nervos-com…

Leading cryptographers met in Cambridge last month for Ethereum's second annual post-quantum research workshop. The recap is worth four minutes, and it doesn't soften the stakes: quantum computers were expected to break cryptography by 2035. "The new estimate is 2029." AI is a big part of why. @GiacomoFenzi of EPFL: "It is almost certain that AI accelerates timelines. It is uncertain by how much it will accelerate it." Despite that uncertainty, the tone is upbeat. Ethereum's researchers have settled on hash-based signatures, and as one puts it near the end: "we just need to put it in place and done." So what does "done" look like? On Bitcoin, it means agreeing a soft fork. Taproot, its last major upgrade, took nearly four years from proposal to activation, and it had broad support. Then every holder has to move their coins, on a network with room for only a few thousand transactions every ten minutes. On Ethereum, standard accounts are tied to one signature scheme checked by the protocol, so it means a hard fork. Then every holder has to move their coins. A proposal called Frame Transactions (EIP-8141) would let accounts set their own verification, so later changes or additions of signature schemes wouldn't need another fork. And if Bitcoin's new scheme ever needs replacing, it goes through it all again. On CKB, signature schemes were never written into the rules every node enforces. Each one is a small program called a lock script, so adding a new scheme is just a software release. Anyone can do it at any time, no forks needed. SPHINCS+, a hash-based scheme, is already live on the network, with an audited lock. "Done" means moving your coins under it in an ordinary transaction. Whichever schemes stand the test of time, CKB can carry them without a protocol upgrade.

CKB has been crypto-agile by design since its mainnet launch in 2019. On many blockchains, a new signature scheme needs a protocol upgrade, and getting a whole network to agree is slow and contentious. On CKB, signature checks run as lock scripts rather than as part of the protocol, so a post-quantum scheme can be deployed as a new lock with no network-wide vote. One is already live on mainnet and three are on testnet. Each scheme below is measured against secp256k1, the signature scheme used today by Bitcoin and Ethereum, as well as by CKB's “default” lock. On CKB it takes up 65 bytes and about 3.5 million computing cycles to check. 1. SPHINCS+ (live on CKB mainnet, audited) Instead of relying on the arcane mathematical problems behind today's signatures, SPHINCS+ uses layers of cryptographic hashes to show that a transaction was authorized by the rightful owner. Its security depends on the hash function and nothing else. Jan Xie, our Chief Architect, calls it the most conservative option. It is also stateless: the wallet does not have to keep count of how many times it has signed, so a seed phrase restores everything. ⦿ Size: about 120 to 770 times larger than a secp256k1 signature ⦿ Checking: about 3 to 14 times longer ⦿ Space: about 12 to 70 transactions per block, against about 1,000 with secp256k1 ⦿ Standard and audit: NIST's SLH-DSA (FIPS 205); ScaleBit audited the lock in 2025 In plain terms: the most conservative choice on the list. It is standardized, audited and built on hash functions alone, at the price of taking up the most space on the chain. 2. SHRINCS (testnet, unaudited) SHRINCS also relies only on hash functions. It is a design from @Blockstream, and the CKB lock on testnet was written by Jiandong Xu. It is built to be small. In normal use the signatures are very short, but the wallet has to keep count of them, because signing twice with the same count would expose the key. If the count is lost, or the wallet would rather not rely on it, it can use a larger signature that works from the seed phrase alone. ⦿ Size: about 5 times larger (324 bytes at the start, growing slightly with each signature), or about 40 times larger on the fallback ⦿ Checking: about 3 times longer at the start, or about 5.5 times on the fallback ⦿ Space: about 370 transactions per block with a fresh counter, against about 1,000 with secp256k1 ⦿ Maturity: a young design, with no independent audit or security proof so far In plain terms: SHRINCS signatures have the smallest footprint of the four at first, but the wallet has to keep careful count, and the design is young and unproven. 3. ML-DSA (testnet, unaudited) ML-DSA is NIST's main general-purpose standard (FIPS 204). It rests on a different kind of mathematical problem, called a lattice problem, which is newer than hash functions. Like SPHINCS+, it needs no counter. The CKB locks were written by community developer toastmanAu. ⦿ Size: about 57 to 81 times larger at its two smaller settings ⦿ Checking: about 1 to 2 times longer ⦿ Space: about 100 to 140 transactions per block, against about 1,000 with secp256k1 ⦿ Standard: final (NIST, 2024) In plain terms: the standard all-rounder. It is reasonably quick to check, but bigger than today's signatures and built on a newer mathematical assumption than the hash-based options. 4. Falcon (testnet, unaudited) Falcon is also lattice-based, and NIST is standardizing it. It produces the smallest signatures of the lattice schemes. Its weak spot is signing, which is complex to implement. Checking a signature, the part the chain does, is simple. The CKB locks are also by toastmanAu. ⦿ Size: about 24 times larger for Falcon-512 ⦿ Checking: about a third of secp256k1's cost, the cheapest of the four ⦿ Space: about 280 transactions per block, against about 1,000 with secp256k1 ⦿ Standard: still a draft (NIST's FN-DSA, FIPS 206) In plain terms: the quickest to check, and small for a lattice scheme, but harder to implement on the signing side. So is there a best one? No. Each wins on one measure and pays for it on another: ⦿ SHRINCS: the smallest signatures at first, provided the wallet keeps its count ⦿ Falcon: the cheapest to check, though signing is hard to implement ⦿ ML-DSA: the most established standard and the simplest to build, but bigger than today's signatures ⦿ SPHINCS+: the most conservative foundation, paid for in space Which matters most depends on what a chain is protecting and what it can afford: block space, checking cost, how much it trusts newer mathematics, and how much it can ask wallets to look after. On October 7, @VitalikButerin said hash-based signatures beat lattice-based ones wherever hash-based is possible at all. Ethereum's roadmap already excludes ML-DSA and Falcon. SPHINCS+ and SHRINCS are hash-based; ML-DSA and Falcon are lattice-based. No break of any of the four has been shown. CKB does not have to choose. Each scheme is a lock script, so anyone can deploy one without a network-wide vote, and each user decides which to trust. If research or a standard points somewhere new, a new lock can join them the same way.