The signature size explosion is perhaps the most underappreciated challenge here. P2QRH's SPHINCS+-128s signatures are 7,856 bytes - that's 164x larger than current ECDSA signatures. Even the more efficient FALCON-512 at 690 bytes represents a 15x increase. This isn't just a storage problem - it fundamentally alters Bitcoin's economic model. Transaction fees calculated by size would increase proportionally, potentially making small-value transactions economically unfeasible. We could see Bitcoin's throughput drop from ~7 TPS to less than 1 TPS with SPHINCS+.
The quantum threat timeline adds urgency that the BIP doesn't fully capture. IonQ's roadmap targets 1,600 logical qubits by 2028, potentially sufficient for breaking secp256k1. Google's Willow chip demonstrates exponential error reduction with scale. We're not looking at a distant theoretical threat - we're potentially 3-5 years away from cryptographically relevant quantum computers. The 5-year Phase B timeline might already be too generous.
It could bring us more features, than some people may expect. For example, if it would be possible to go from every existing public key, to every existing private key, then OP_CHECKSIG will become just some 256-bit calculator, with built-in addition and multiplication. And then, many interesting Scripts could be deployed on top of that, for example "<signature> <pubkey> OP_CHECKSIG" as the output Script can be spendable, and then it can be used instead of proposed OP_CHECKTEMPLATEVERIFY.
If ECDSA is fully broken - this is actually a fascinating observation. However, the security implications go deeper. Approximately 25% of Bitcoin's supply sits in quantum-vulnerable addresses, including Satoshi's ~1 million BTC in P2PK outputs. If quantum computers emerge before migration completes, we could see a race condition where quantum-capable actors attempt to sweep these vulnerable funds, potentially causing massive market disruption.
The ZK-proof recovery mechanism in Phase C is technically ambitious to the point of being speculative. Proving knowledge of a BIP-39 seed phrase that generates a specific address through HD derivation, all while maintaining zero-knowledge properties, requires cryptographic constructions we haven't fully developed for Bitcoin's context. This isn't just a implementation detail - it's a fundamental research problem that could take years to solve properly.
What's particularly concerning is the minimum 76.16 days of continuous processing time required for network-wide upgrade under optimal conditions. This assumes perfect coordination and no complications - historically, Bitcoin upgrades like SegWit took years to achieve meaningful adoption. The mandatory nature of this migration creates an unprecedented coordination challenge.
Alternative approaches from other projects offer interesting perspectives: QRL's use of stateful XMSS signatures works but requires careful key management that doesn't align with Bitcoin's address reuse patterns. Ethereum's planned integration of zk-STARKs provides quantum resistance while maintaining better performance characteristics, but requires more complex cryptographic assumptions.
The suggestion to use timelocking instead of burning funds is excellent - it maintains optionality while avoiding the philosophical issues of mandatory fund forfeiture. However, this still doesn't solve the fundamental dilemma: how do we coordinate a global, mandatory cryptographic migration in a decentralized system designed to resist exactly this type of coordinated change?
The real challenge isn't technical - it's game theoretical. Early migrants pay higher fees for larger transactions while gaining quantum security. Late migrants risk fund loss but enjoy cheaper transactions longer. This creates a complex prisoner's dilemma that could fragment the network.