Idea for a watchdog fork

[swfsql]

This is a simple and small idea, but not that it necessarily could/should be implemented.
Related to the prevention of quantum attack on the cryptography, on some hypothetical situation where all of the private keys of the entire history are calculated and published, which would render the entire history useless.

Let Bitcoin ("original" Bitcoin) be forked twice, into Bitcoin-A and Bitcoin-B.
Bitcoin-A operates mostly identically to Bitcoin-original, so it is sort of it's "successor".
Bitcoin-B will be the watchdog, it will use a more (likely) quantum-resistant crypto for the ownership/spending.
When someone spends on Bitcoin-A, that person will also have to replicate/translate that transaction on Bitcoin-B. When blocks of A are being formed, only transactions that are duplicated in B are allowed in A. And a markle tree root (or something) from Bitcoin B's "block" must be present in Bitcoin A's block - and ofc validators from A would have to "read data" from B to function.
Then initially, Bitcoin A is the source of truth, as far as mining is concerned, and Bitcoin B follows that truth arbitrarily.

Let's say one day all of the keys from Bitcoin A are exposed. So Bitcoin A's history goes to the trashbin, but the users can, say, rollback a few days and switch into Bitcoin B, and then B would now operate independently from (the now defunct) A - assuming B survives that attack. This could also help to inhibit the attack in the first place, since there would be a backup around.

What you think?

[1715072069]

1715072069

[DannyHamilton]

...When someone spends on Bitcoin-A, that person will also have to replicate/translate that transaction on Bitcoin-B...
...Bitcoin A's history goes to the trashbin, but the users can, say, rollback a few days and switch into Bitcoin B...

If the transactions in Bitcoin-A are exactly replicated in Bitcoin-B, then they are subject to the same vulnerability, and therefor Bitcoin-B would go to the trashbin right along with Bitcoin-A.

If new transactions in Bitcoin-B are required to NOT have outputs that use ECDSA, then what's the purpose of keeping Bitcoin-A around at all? A user can't create a Bitcoin-A transaction without ALSO creating a non-ECDSA transaction, so why allow the ECDSA transactions at all?

[swfsql]

Yes the transactions couldn't be just copy-pasted on B, since the whole point would be to change into a different signature.

On the purpose on keeping Bitcoin-A, it would be for being conservative regarding such change into B. Ofc A would still be a hard-fork from the original, and users would still be required to keep keys from both A and B in order to just use A, but oh well. I'd say it's for the sake of not jumping entirely into B, or to still keep having one feet at A.  

I think this is the closest to having a B as backup while being as inertial as possible on the original. The purpose of the backup could be extended to as having multiple backups as well, with different crypto algorithms - but I think that would be waay beyond "messy," if the first backup wouldn't already be.

edit: so you made me realize that what this brings is no different from just adding extra signatures with different algorithms on Bitcoin. No need for duplicated systems to achieve that..

[dkbit98]

What you think?

Honestly, this is probably one of the worst ideas I ever heard on this forum, and I heard some that are terrible.

This is pure waste of time and resources for some imagined quantum threat that would wipe out all security if it existed, not just Bitcoin related.
Nobody is going to agree to make forks like this and nobody would mine double coins like this, or maybe you planned to eliminate mining and make one more ''better'' and more secure version of Bitcoin?

[garlonicon]

The simplest way to achieve quantum resistance I can imagine is creating a soft-fork with some future-Segwit-version address. In this way, people will move coins from ECDSA addresses to new addresses and when all coins will be moved, the system can be trusted again. Coins locked into ECDSA keys can be spent only by revealing ECDSA keys, it is possible to limit that somehow, but still, creating any fork is not needed, just regular signalling and soft-fork as usual is the simplest way.

For some ECDSA keys it may be possible to prove somehow that some coins belong to the true owner (for example by revealing how HD wallet was constructed), but still, there will be keys generated in totally random way where there will be no way to tell apart attackers from real users and in such cases coins will be stolen. But I expect that coins from some puzzles will be taken faster, alerting everyone that something is wrong and needed changes will be implemented long before (also because attacking the chain will make stolen coins worthless and their value will be diminished by the act of collecting them).

[swfsql]

nobody would mine double coins like this, or maybe you planned to eliminate mining and make one more ''better'' and more secure version of Bitcoin?

this' already clear on post #0

[pooya87]

In this way, people will move coins from ECDSA addresses to new addresses

That's a false assumption. Take a look at SegWit, even though P2WPKH exists and it is more beneficial to use it, a lot of people still don't. In case of a security concern, there is an additional problem that you can't say the system as a whole is secure just because SegWit version n is secure and everything else (in this hypothetical scenario) is insecure.

[garlonicon]

That's a false assumption. Take a look at SegWit, even though P2WPKH exists and it is more beneficial to use it, a lot of people still don't.

People are not forced to use Segwit. In case of breaking ECDSA someone will move that coins: the true owner or the attacker. There is not much that can be done to protect funds, P2PK outputs could be moved directly if ECDSA is broken, P2PKH and P2WPKH outputs will be safe if public key is hidden, the same with P2SH and P2WSH, but that key have to be revealed in some safe way, which could be hard. For P2TR outputs spending with a script could be mandatory, but that may not be enough. The whole Lightning Network is based on raw public keys, known for both parties forming a channel, so in case of breaking ECDSA any such second-layer network will have to switch or all coins will be taken by someone.

The difference between Segwit and breaking ECDSA is that in Segwit you can switch or you can still use old version and pay fees for that choice. In case of security issue, it is more similar to Value Overflow incident: you can stick with the old version, but it can quickly become worthless, forcing you to switch no matter what. In reality it depends how hard it will be to break ECDSA: 2^64 operations?, 2^32?, 2^96?, as long as mining a new block is more profitable than attacking some existing address with huge balance, we are safe.

In case of a security concern, there is an additional problem that you can't say the system as a whole is secure just because SegWit version n is secure and everything else (in this hypothetical scenario) is insecure.

In the currently existing system there are insecure scripts you can use if you are a miner, for example "2 2 OP_ADD 4 OP_EQUAL", you can also lock coins to a hash of something with no keys, that could be captured by other miners. Is that system insecure, because it is possible to do so? No, because that scripts are nonstandard, in the same way the future system will be secure if creating new insecure outputs will be nonstandard (and when all such outputs will be cleared, then spending such scripts can be nonstandard in future versions).

[pooya87]

~~

You ignored the main argument I made: if there is a flaw in the system, it must be removed. A soft-fork is not the best way to remove a security flaw.

Is that system insecure, because it is possible to do so?

That was a very bad example. 2+2=4 is working exactly as it is supposed to work. On the other hand if you could compute private key from public key, then ECDSA is NOT working as it is supposed to work.

[ABCbits]

It's neither simple or small idea, why don't we create soft-fork which introduce new quantum-resistant cryptography and payment scheme (such as P2QTR) in next few years? That way, there'll many years for Bitcoiner to move their funds to quantum-resistant address.

[Wind_FURY]

OP, is that shower thought to be ready for Quantum Computers?

If indeed OP’s attempt is to solve the problem that Quantum Computers could cause, I heard Adam Back said something about new signature schemes with Schnorr or other signature schemes that can protect against QC, and that it will not be a problem.

[j2002ba2]

... quantum-resistant ...

What you think?

Creating quantum-resistant crypto algorithm is very easy: all algorithms are quantum-resistant. All of them. Quantum computing is, and will always be slower than classical one. All quantum computers are noise-generators, and can only be superior in generating garbage. Of course for some applications tons of noise is beneficial, but not for solving ECDLP or reversing SHA256.

It is very easy to see it: somewhere halfway through solving the problem, the magical qubits have to represent a whooping 2²⁵⁶ bits of information. Then a single neutrino passes through and all is gone, the information is disrupted. And neutrinos pass all the time in large quantity. And not only neutrinos.

The word "quantum" in many cases is equivalent to "scam". So is any "scam computer" a threat to bitcoin?

[Pmalek]

Let's say one day all of the keys from Bitcoin A are exposed. So Bitcoin A's history goes to the trashbin, but the users can, say, rollback a few days and switch into Bitcoin B, and then B would now operate independently from (the now defunct) A - assuming B survives that attack.

That now reminds me of the way Ethereum handled the infamous DAO hack. Rolling back the history to prevent big players from losing their investments. If you introduced that into Bitcoin as well, you are interfering and decreasing the decentralized aspect of the network.

If I discover your private key and steal some of your funds, you can't ask for a timeout and request a rollback. The network worked the way it was supposed to work. The person who had the private key spent the coins. It's up to the developers to keep an eye out on evolving threats and have Bitcoin switch to a quantum-resistant algorithm if needed.   

[BlackHatCoiner]

People are not forced to use Segwit. In case of breaking ECDSA someone will move that coins: the true owner or the attacker.

In case of breaking ECDSA, someone who reuses addresses should move the coins. If you never reuse an address, you're not fearing of such scenario. Your public key is been seen hashed by the attacker, which leaves them no other option than diving into the brute force of 2^160 addresses.

Of course for some applications tons of noise is beneficial, but not for solving ECDLP or reversing SHA256.

Isn't that a bad formulation? Saying that you can reverse an SHA256 hash, means that there is, specifically, one. But, there may be more. In MD5 there have been collisions, but reversing that hash would be considered utopian, because there at least two opposites of what it was.

Also why would an attacker want to reverse an SHA256 hash in Bitcoin other than getting the ECDSA public key?

[ranochigo]

Don't need to double the resources needed for every user to use Bitcoin, that is completely unnecessary. If there is a hypothetical scenario that ECDSA, or whatever signature algorithm Bitcoin is using gets cracked, then too bad. We have better things to worry about at that point, Bitcoin isn't the main priority.

If a quantum computer manages to derive the private key from the public key, then either you accept that it is inevitable or we burn them before that. QCs are not cheap, if you manage to get a private key of some Bitcoin address with it, then you've at that point, either completely wasted your time (could've probably done something else with it) or QCs are mature enough such that everyone is already aware of it. Ps. QC is not a magical machine that takes minutes or hours to crack an address.