Topic: Does replacement interact with quantum computers? - page 2. (Read 2101 times)

With the opt-in feature of RBF, people won't have to use RBF which provides some protection. However, if the attacker with a QC is able to break the keys in the time it takes to get a confirmation and to send out a transaction in that time, they will still be able to create a double spend transaction. RBF makes it easier, but it is still fairly trivial to create a competing double spend which could have a good change of getting confirmed without RBF enabled.

An option has been recently merged into Bitcoin Core to disable RBF relaying. In the case that this scenario does happen, people can use that flag to disable RBF and thus we can have more protection against such an attack.

That is likely to be both difficult to program and have unintended consequences limiting legitimate usage of RBF.

From a game theory perspective it doesn't make much sense for us to wait for the day where it is public knowledge that a QC exists. Given QC attributes as crypto-breaking machines, there's a history of similar crypto-breakthroughs remaining hidden.

If I were the US government / NSA, and I just had a QC developed, why would I disclose it to the world? It would go against my advantage to break cryptography, to have a bitcoin kill-switch, even to hack specific addresses or cold wallets that could disrupt the market, without anyone understanding what hit'em. People would just see money moving from a large address and suppose an exchange got hacked or the owner just took the money and run. "He probably stole the money or got hacked... What QCs? That's science fiction - they don't exist..." - kind of.

So my view is that the game theory is leaning (far) more to the side where a QC would remain undisclosed - at least for several years.

When the network is (openly) attacked, there should be an option (for RBF) where everyone running nodes should be able to disable rbf through some kind of flag until a QC transition is complete. At least that way some transactions involving addresses with 100% unspent coins can still go through without getting attacked, although the first target will definitely be the addresses with spends that are idle / not transacting.

QC-contingency code / different algos should also be ready for deployment, just as alternative pow code has been written for other nightmarish scenarios (as I've read recently). Ideally it should be implemented before the danger is in the open but then again, I read that QC-resistant algorithms are severely bloated - so some kind of smart implementation must be found to bypass the bloat (?).

If QC comes into existence, then that is a very major problem which should be fixed ASAP in any case. If the only protection people have against QC is addresses + the (likely) fact that it'll take at least a little while for even QC to break keys, then that is very poor security. Depending on the exact circumstances, opting out of RBF might be wise in that case, or it might even be necessary to extend the protocol to do ZKPs or something so people can more safely transition from ECDSA to something QC-proof. I don't view the possibility that you might one day need to opt out to be secure as a good argument against opt-in RBF now, when QC looks 15+ years away.

It will be possible to disable the RBF policy if you are absolutely morally opposed to it for some reason, but I don't recommend it.

It's not reasonably possible to allow only the fee-bump case. Look up arguments against FSS-RBF, which attempts this.

When money is concerned, perhaps we should not be basing our assumptions on the best-case scenario (?).

Either way

-will the new client have a parameter to disable RBF?
-would it be difficult to make RBF only relevant for a "I made a mistake by insterting a low fee, I want to raise it and skip the queue" scenario and nothing else, like sending money elsewhere or back to yourself?

At this time, it is a safe assumption that a usable QC currently doesn't exist except in research institutions where they would not be malicious.

Although RBF has that problem, in the future, we can upgrade all of the algorithms to quantum resistant algorithms. We will have to do that anyways.

I just realized something about RBF - please correct any misunderstandings I may have, I'm not a btc developer.

We are all operating under the assumption that a quantum computer doesn't exist - but I'm not so sure that there isn't, or that there won't be pretty soon. In any case, the greatest safeguard we have against such a possibility is storing coins in addresses that have no prior spending in them. So when a QC is on the loose, the best one can do is to spend the full amount in order to not leave any coins behind for priv. key extrapolation and hacking. But this is based on a first seen-first serve scenario. RBF would allow an attacker to see a transaction, extrapolate the priv key and issue a respending with a higher fee, hijacking one's money.

So, from what I understand, RBF reduces the futureproofing / quantum resistance of BTC. Is there a way where it can only be implemented by honoring the initial transactions, plus a higher fee - for those desiring to jump the queue - and reject any other attempts to change the destination?