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 to safeguard against quantum attacks. However, Cardano founder Charles Hoskinson believes this solution is still insufficient to protect coins belonging to the network's pseudonymous creator, Satoshi Nakamoto, as stated in a recent YouTube video. Hoskinson argues that the proposed defense mechanism, BIP-361, is both technically mislabeled and structurally flawed, making it incapable of protecting the network's oldest coins, including the roughly 1 million bitcoin attributed to Satoshi Nakamoto. He claims that BIP-361 would require a hard fork, as it would invalidate existing signature schemes that users currently rely on. A hard fork is a significant change to the network's rules, which could lead to a split in the network unless all users upgrade. In contrast, a soft fork is a less invasive change that tightens the rules while still allowing old software to function. The BIP-361 proposal suggests using zero-knowledge proofs tied to BIP-39 seed phrases to reclaim frozen funds. However, Hoskinson argues that this approach is ineffective for approximately 1.7 million bitcoin that predate the introduction of BIP-39 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, making it impossible for their owners to provide the necessary cryptographic proof to reclaim 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. Lopp argues that freezing dormant coins would be preferable to allowing a future quantum attacker to recover and dump them on the market. Hoskinson's criticism 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.