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 proposed a plan to protect 8 million coins from quantum attacks. However, Charles Hoskinson, the founder of Cardano, believes this plan is still unable to safeguard the coins belonging to Satoshi Nakamoto, the network's pseudonymous creator, as stated in a video on his YouTube channel. Hoskinson claims that Bitcoin's proposed defense against quantum computers is both technically incorrect and structurally incapable of protecting the network's oldest coins, including the roughly 1 million bitcoin attributed to Satoshi Nakamoto. He argues that the proposal, BIP-361, which aims to phase 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. According to Hoskinson, this distinction is crucial because Bitcoin's development culture has traditionally opposed hard forks, viewing them as a violation of the network's immutability. 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 cannot 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 means their owners would be unable to provide the necessary cryptographic proof to migrate their coins, resulting in permanent freezing. Jameson Lopp, the core developer who co-authored BIP-361, has expressed his dissatisfaction with the proposal, describing it as a rough idea for a contingency plan rather than a finalized specification. Hoskinson's critique extends beyond the technical aspects, 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.