Cardano Founder Disputes Bitcoin's Quantum Solution, Claims It Cannot Protect Satoshi's Holdings

Earlier this week, Bitcoin's core developers suggested freezing 8 million coins as a defense mechanism against quantum attacks. However, Cardano's Charles Hoskinson believes this approach is still insufficient to safeguard coins belonging to the network's creator, Satoshi Nakamoto, as stated in a recent YouTube video. Hoskinson argues that the proposed solution, BIP-361, is technically incorrect and incapable of protecting the oldest coins in the network, including the roughly 1 million bitcoin attributed to Satoshi. He claims that BIP-361 would functionally require a hard fork, as it would invalidate existing signature schemes, despite being presented as a soft fork. A hard fork is a significant change to the network's rules, which could lead to a network split unless all users upgrade. In contrast, a soft fork tightens the rules, allowing old software to still work but without access to new features. The BIP-361 proposal suggests that users with frozen funds could reclaim them by creating a zero-knowledge proof linked to their BIP-39 seed phrase. Nevertheless, Hoskinson disputes this approach, stating that it cannot recover approximately 1.7 million bitcoin that predate the introduction of BIP-39 in 2013, including the coins associated with Satoshi's early mining activities. These early coins were generated using a different key derivation method and would remain permanently frozen if the proposal passes in its current form. Jameson Lopp, the core developer behind BIP-361, has expressed his dissatisfaction with the proposal, describing it as a rough 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 sell them on the market. Hoskinson's criticism 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, resulting in contentious upgrades being negotiated through developer mailing lists and social pressure.