Charles Hoskinson Claims Bitcoin's Quantum Solution is a Hard Fork That Fails to Protect Satoshi's Coins
Earlier this week, Bitcoin's core developers suggested freezing 8 million coins as a defense mechanism against quantum attacks. However, according to a video posted on his YouTube channel, Cardano founder Charles Hoskinson believes that this solution still cannot protect the coins belonging to the network's creator, Satoshi Nakamoto. Hoskinson claims that Bitcoin's proposed defense against quantum computers is technically incorrect and structurally incapable of safeguarding the network's oldest coins, including the roughly 1 million bitcoin attributed to Satoshi Nakamoto. He argues that BIP-361, a proposal aimed at phasing out quantum-vulnerable bitcoin addresses, is being misleadingly presented as a soft fork when it would actually require a hard fork due to its invalidation of existing signature schemes. Hoskinson emphasizes that the distinction between a soft fork and a hard fork is crucial, as Bitcoin's development culture has historically opposed hard forks. The proposal suggests that users with frozen quantum-vulnerable funds could reclaim them by constructing a zero-knowledge proof tied to their BIP-39 seed phrase. Nevertheless, Hoskinson argues that this approach is unable to rescue approximately 1.7 million bitcoin that predate BIP-39's introduction in 2013, including the roughly 1 million coins associated with Satoshi's early mining activity. These early coins were generated using a different key derivation method, which relied on a local key pool rather than a deterministic seed, making it impossible for their owners to provide the necessary cryptographic proof to migrate them. Jameson Lopp, the core developer who co-authored BIP-361, has expressed his dislike for the proposal, describing it as a rough idea for a contingency plan rather than a finalized specification. Hoskinson's critique extends beyond the technical details, arguing that Bitcoin's lack of formal on-chain governance hinders the network's ability to resolve tradeoffs through a structured process, forcing contentious upgrades to be negotiated through developer mailing lists and social pressure.