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 freeze 8 million coins in order to defend against potential quantum attacks. However, according to Cardano founder Charles Hoskinson, this plan is still insufficient to protect the coins belonging to the network's creator, Satoshi Nakamoto, as stated in a video posted on his YouTube channel. Hoskinson believes that the proposed solution, BIP-361, is both technically incorrect and structurally flawed, making it incapable of safeguarding the network's oldest coins, including the approximately 1 million bitcoin attributed to Satoshi Nakamoto. He claims that BIP-361 would require a hard fork, as it invalidates existing signature schemes that users currently rely on. A hard fork is a significant change to the network's rules, which would require all users to upgrade their software, whereas a soft fork is a less invasive change that still allows old software to function. The BIP-361 proposal suggests that users with frozen funds could reclaim them by creating a zero-knowledge proof tied to their BIP-39 seed phrase. However, Hoskinson argues that this approach is unable to rescue the 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, which relied on a local key pool rather than a deterministic seed. As a result, if the proposal is adopted in its current form, those coins would remain permanently frozen, regardless of whether their original owners attempt to migrate. Jameson Lopp, the core developer who co-authored BIP-361, has acknowledged that the proposal is not ideal and hopes it will never be necessary. Hoskinson's criticism extends beyond the technical details, arguing that Bitcoin's lack of formal on-chain governance makes it challenging to resolve tradeoffs through a structured process, leading to contentious upgrades being negotiated through developer mailing lists and social pressure.