ECSDA secp256k1 are on borrowed time.

[WhyFhy]

Yall need to get to work on protocol proposals soon.

I dont have a complete solution yet, but its time to seriously consider Taproot upgrades, a new SegWit branch, and double or triple signature signing.

Focus on the lowest common denominator right now.    signatures.

Something like ECDSA + SPHINCS+ + Merkle Tree could be a start but its still just a patch.

Nothing will be secure soon.

nTimelock can buy time temporarily, but this barely scratches the surface.

People are already researching curve collapse functions and log resolution methods.

If youre stuck in infosec field practices and principles its time to get creative and step out of your comfort zone.

Deterministic functions are not truly one way they only feel that way because of current computational limits. Thats temporary.

My 2 Sats FWIW

[NotFuzzyWarm]

Oh bloody hell, yet another SC (Super Computer) & QC (Quantum Computer) calamity FUD thread...
Get over it folks and dig deeper into where progress in computing power actually is and stop repeating crap based on pure speculation.

People are already researching curve collapse functions and log resolution methods.

Just like they have been for decades and still with no real progress.

Just like fusion power, the reality is still very far away from what is circulating on the 'net.

[WhyFhy]

Oh bloody hell, yet another SC (Super Computer) & QC Quantum Computer) calamity FUD thread...
Get over it folks and dig deeper into where progress in computing power actually is and stop repeating crap based on pure speculation.

People are already researching curve collapse functions and log resolution methods.

Just like they have been for decades and still with no real progress.

Just like fusion power, the reality is still very far away from what is circulating on the 'net.

Your complacency bias is actually the biggest threat right now.
Patching after the fact won’t be an option, that’s exactly why I said “if you’re stuck in infosec principles, it’s time to get creative.”
People like you are a predictable factor. Constrained.

[Mia Chloe]

Oh bloody hell, yet another SC (Super Computer) & QC Quantum Computer) calamity FUD thread...
Get over it folks and dig deeper into where progress in computing power actually is and stop repeating crap based on pure speculation.

Actually I see no reason why people are still scared that quantum computing will crash Bitcoin when even they said capabilities of quantum computing haven't even been harnessed yet. Basically everything you see online emphasizing on how much quantum computing beats regular micro computing are just speculations.
I've said this multiple times and the fact is almost no one will waste Quantum computing in crashing bitcoin when they can use it it make a ton of profit from it through a means like mining.

[Cricktor]

~~~

Can you elaborate why you make it sound urgent?

I don't want to say, there's no need to do something, there's already discussions about this and that for potential upcoming threats. You may perceive such processes as too slow or whatnot, but rarely a single person oversees all details and their consequences.

I'm generally curious why you call it out like you did. What do you think to know that you left out in your post? Deliberately? You don't explain at all what could possibly become a real, not imagined, problem. So what's this all about?

[mcdouglasx]

There are enough more urgent classical problems that are moving away from QC at the moment to focus 100% on quantum technology. I think that when quantum is a possible problem, this will probably already be well posed in Bitcoin and in classical cryptography in general. I think that not only Bitcoin depends on this but all current security in the world, so believe me, the arrival of quantum rather than a concern will end up being an improvement for information security.

[pooya87]

People are already researching curve collapse functions and log resolution methods.

I entered Bitcoin world back in 2014 and I remember people working on the same exact thing back then too! In other words this is not new. Hardware has improved but not enough to make a significant difference in order to make this a possibility. That means your attempt at conveying a sense of urgency is wrong.

However, I fully support any discussion about our replacement options.

I dont have a complete solution yet, but its time to seriously consider Taproot upgrades, a new SegWit branch, and double or triple signature signing.

If ECDSA and ECSDSA on secp256k1 curve are to become obsolete, they need to be removed completely IMO; and that requires a hard fork. In such a scenario we no longer need SegWit, it too can be removed.

[stwenhao]

If ECDSA and ECSDSA on secp256k1 curve are to become obsolete, they need to be removed completely IMO

I don't know if people will decide to destroy the only 256-bit calculator in Script, that we currently have. And also: it is possible to use OP_CHECKSIG in a way, where it would be safe, if ECDSA will be broken, but if SHA-256 will still stay strong (for example by using it to check Proof of Work in output scripts, so second-layer protocols on top of Bitcoin could be mineable).

and that requires a hard fork

No, because even if all existing UTXOs will be made unspendable, and the block will be required to have zero coin amounts in the coinbase transaction, and nothing else, then it would still be a soft-fork. More about evil soft-forks: https://petertodd.org/2016/forced-soft-forks#radical-changes

In such a scenario we no longer need SegWit, it too can be removed.

So, you want to soft-fork-out of Segwit? Interesting. Because if everything will be done only in legacy space, and no additional commitment will be done anywhere (for example in the coinbase transaction), then it will reintroduce malleability, O(n^2) transaction hashing, and other problems, for no reason.

It is technically possible, but I would say unlikely. Rather, I would expect "second witness", where you would have "legacy space", "witness space", and for example "commitment space", created only for new address types. Which means, that we could have "max_block_size = N * ((4 * legacy) + witness) + commitment", and instead of 1 MB legacy, or 4 MB witness limit, we could have "N" MB commitment limit, as a new max block size definition (along with other restrictions, to make new outputs JPEG-resistant).

[BitBastard]

AI/Quantum FUD has nothing to do with abstract algebreic and number theory innovations.

They will one day find that it's not actually computationally hard to perform the calculations. Perhaps they map the system over another system like Sinewaves or they find that some esoteric concept turns the curve into Gouda cheese.

[Medusah]

Hardware has improved but not enough to make a significant difference in order to make this a possibility. That means your attempt at conveying a sense of urgency is wrong.

I interpret his urgency as to "begin finding consensus".  I too agree that it might take a long time until a quantum computer breaks ECDSA, but we must not wait until it's relatively, possibly feasible.  We cannot upgrade to a quantum-safe algorithm the same way that a Windows update can.  It will take many years.  Just imagine that even if we have everything ready, developers done writing code and miners done signaling, we still need at least one year of nearly optimal consolidations in a hypothetical clogged up network to migrate most of the coins to quantum-safe addresses.  (And that's just hypothetical, it'll take many years for most bitcoiners to move to quantum-safe.)

And I'm not even discussing about the dilemma with the satoshi-era coins and whether to freeze them or not to freeze. 

[pooya87]

So, you want to soft-fork-out of Segwit? Interesting. Because if everything will be done only in legacy space, and no additional commitment will be done anywhere (for example in the coinbase transaction), then it will reintroduce malleability, O(n^2) transaction hashing, and other problems, for no reason.

Part of SegWit is about keeping things backward compatible which has created a slight overhead. That can be removed with a hardfork and everything else including the malleability related changes can become the default behavior. For example what we call P2PKH right now could use the same sighash mechanism as SegWit v0 is right now without needing the overhead and definitely without needing the wrapped SegWit scripts.

we still need at least one year of nearly optimal consolidations in a hypothetical clogged up network to migrate most of the coins to quantum-safe addresses.

Exactly. This is why I support discussion about replacement options even though it is still too soon.