Thoughts on BIP-361?

What are your thoughts on the new BIP-361 proposal aimed at handling Post Quantum Migration and phasing out Legacy Signatures? A bunch of Bitcoin devs, along with Jameson Lopp, are backing this idea that would essentially freeze wallets at risk from quantum attacks, which includes the dormant coins belonging to Satoshi and others too. It's estimated that about 6.7 million BTC is stuck in those legacy wallets, which is nearly 32% of the total Bitcoin supply! There are three proposed options to consider. Check out the details on BIP-361 over on GitHub.

First: I'm far from an expert on quantum decryption, but I've read things As far as I understand, those are only at risk after exposing the public key, although given fast enough quantum decryption that could be enough time to replace a transaction after it's broadcasted and before it's confirmed. I was surprised when I saw that Taproot addresses introduced risks that Segwit fixed. But those 5 years, in some scenarios, may even be too late. How's that going to work for addresses that don't have a corresponding seed phrase? Or just funds sent to pubkey, like Satoshi's mined coins?

Which risks specifically? Not just legacy, SegWit v0 uses ECDSA signature as well, So every bitcoin users will be affected by this if they wont move their bitcoins to the new quantum resistant address during 'Phase A'.

Just for the sake of prove that it is true for Taproot : Yeah, those keys are tweaked, but the tweak is nothing more than mapping secp256k1 points using the same secp256k1 arithmetic, which is believed to be easily reversed by quantum computers with the help of Shor’s algorithm. So the tweak adds nothing toward security.

The specific risk is simple enough: Taproot leaves the pubkey sitting on-chain from day one, while P2WPKH and old P2PKH hide it behind HASH160 until you spend. That is the part SegWit improved, and Taproot gave back in exchange for other benefits. So no, the exposure profile is not identical across all script types, and saying that every user is equally at risk right now, this muddies the picture. They are all living under the same eventual PQ cloud, sure, but some are standing in the rain already and some only get wet when they spend.

I was told (by listening to the Dutch Cryptocast) that Taproot introduced a vulnerability for quantum decryption comparable to legacy addresses with exposed public key. @flapduck: have an avatar

Okay, I asked because you mentioned that it's something that "SegWit fixed". I got curious on what else could it be. In that case, it's not specifically fixed by SegWit but already addressed by P2PKH by hashing the public key. If it's about my reply, it's about the impact of this BIP rather than QC. It'll affect all users regardless whether their pubKey is exposed since PhaseB will invalidate existing signatures. I don't know how viable PhaseC will be since there'll definitely be users that will fail to upgrade in time in case this is implemented.

My opinion doesn't change much since last time. I disagree with phase B, IMO do nothing is less worse option considering nobody supposed able to freeze/lock someone else Bitcoin. P.S. Initial version of this BIP discussed on J. Lopp's Post-Quantum Migration BIP and i believe this thread is more suitable on Development & Technical Discussion .

the proposal is explicitly not intended as a concrete implementation! Jameson Lopp himself emphasizes that it is neither a final specification nor a plan that can be activated immediately. rather, bip-361 should be understood as a theoretical contingency mechanism that could serve as a basis for further discussion in the event of an emergency. JL himself stated that he hopes such a proposal will never have to be implemented. this is a key point that is largely lost in the public debate but is actually crucial, as many critics are already interpreting the bip as if its implementation were imminent. and yet the criticism hits a nerve. for even as a thought experiment, bip-361 shifts the perspective. its no longer just about introducing new rules, but potentially treating existing coins differently. and that is precisely what feels to many like a break with Bitcoin’s previous self-image, which is rightly the subject of heated debate.

I cannot give it more than a few seconds of thought. It's just a terrible idea. I know that a quantum computer can steal the vulnerable coins and send them to the market, but this is just the consequence of having lack of awareness, and leaving your bitcoin vulnerable when you could just update and keep them secure. And since there's so many people concerned about freezing, there cannot be consensus. Just think of another solution. Bitcoins cannot be frozen. Period.

I personally think Bitcoin has plenty of time to devise a post-quantum cryptography plan. It's been demonstrated that even with supercomputers and advanced AIs like Mithos, capable of finding vulnerabilities with brutal intelligence, I don't see any new ways of breaking the curve being discovered. Everything we've seen so far has been brute-force shortcuts, which, given the difficulty of cracking a non-vulnerable Bitcoin address, is a daunting task even for these technologies. So, at this point, one could say that Bitcoin remains secure. Cryptographic research takes decades, and it's being investigated, as is the duty of technological advancements, to ensure we're not caught off guard.

Rather than freezing the coins It seems more consistent to keep the system unchanged. I believe it would cost the network more in the long run even if it may seem good in the short With Bitcoin it's quite common that users are responsible for their security. Individuals with known pubkey can move to another address. Freezing UTXO seems like thin line to dance on.

I'm not really looking forward to seeing 6.7 million Bitcoin dumped on the market. It's going to be one hell of an altcoin season if that happens.

I doubt they would want to dump everything once that would be stupid It would be slow and I don't see it been in the hands of an average man. It's like picking losing the coins forever and making Bitcoin total supply lower And Letting it be and increasing Bitcoin circulating supply thereby affecting the price But Not Your Keys, Not your coins I guess

The question is who is going to have early access to QC, who is going to control and for how long before it became a public tool. What if the government gets to decided who use QC? This are rhetorical questions that need to be fix before QC becomes powerful to break Bitcoin. The Bitcoin community atmosphere is tense now but if people are objecting this proposal, what's the best alternative to make Bitcoin bullet proof to QC. We can't bring a proposal with "hope", its better to do something we can control. The same people that are wailing calling Lopp all sort of name will be the first to complain if the market is dump tomorrow. I'm more concerned about people that hold Bitcoin and wouldn't transition even if there is deadline when existing signature becomes invalid than Satoshi wallet some people are using for excuse.

There is no "the government", I expect competing governments to all want in on this. I'm concerned about both. I've given away legacy paper wallets in the past, and wouldn't like them to become invalid if the current owner doesn't take action. Bitcoin private keys are supposed to be forever.

It's important to let everyone know that this is unnecessary since it it also means an attack on the entire network  (in form of price attack) . There is already an extraordinary solution that protects the entire network from attacks . This solution will automatically go into effect when a malicious hacker steals bitcoins (especially those with potentially strong effect on the market) and tries to dump them. But if you are faithless or don't believe me, you can go this path specified below... we consider it one of the best qc attack mitigation. You are free to freeze all relevant addresses, but their owners should be able to unfreeze them once they setup up security questions and answers, which is an additional security layer. But the feature has to first be implemented  by developers before questions and answers can be setup by address owners. Inputing a private keys (whether correct keys or not) without the security question shows: "this account is frozen to protect it from sophisticated attack, please setup  security question and answer to further secure the account and unfreeze it". Once the security is setup and the private keys is correct, the account unlocks.. This method is QC and brute force proof because even if the right private key is guess, it does nothing until a security question is setup. An attackers will have to manually setup a security question for each private keys in order to find the right keys that unlocks the account. But If it is done too fast or automatically with AI or bot the system could get the attacker to solve puzzles .. This slows things down, and will likely take forever to guess the right keys even with the fastest QC ever invented This solution does not violate the censorship resistant principle of Bitcoin

From my understanding biggest risk are for bitcoin addresses that already had sent coins in the past. I am not quantum expert also, but someone with unlimited money printing could invest a lot in cracking this sooner than people expect it. Maybe I don't agree fully with BIP-361 proposal, but doing nothing and just hoping quantum won't affect bitcoin sounds terrible to me. If bitcoin is going to get cracked than same thing will happen to most shitcoins also. As far as I know only monero is close to achieving quantum resistance with FCMP++.

Correct. That's one of the reasons to avoid address reuse.

As a reference to the terms used in the BIP, this is particular to "Long-Range Attack" that's mentioned there. It's high risk because QC attackers will have a lot of time to work on the user's private key. So even a relatively slower QC with enough qubits could pose a threat. But it also mentioned "Short-Range Attack", that one is about the ability to hack a private key in <10 minutes in average right after the pubKey made public which is most of the time, when the user broadcasted a transaction that used it as input. But as you know it (based from your April Fools joke about QC), it needs a sufficiently fast QC to achieve. I agree, this is why I'm closely following QC-related proposals to see which one looks more promising. Although I'm skeptical on Quantum Computers (hardware-specific), it wouldn't hurt for the network to be ready.