Does replacement interact with quantum computers?

[AlexGR]

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?

[achow101]

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?

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.

[AlexGR]

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?

[theymos_away]

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.

[AlexGR]

If QC comes into existence, then that is a very major problem which should be fixed ASAP in any case.

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 (?).

[letsplayagame]

-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?

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

[achow101]

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.

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.

[AlexGR]

-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?

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

I'm trying to think about this algorithmically and I don't see why...

a) You broadcast your intention to bump up the fee, the other clients are programmed to accept it.
b) You broadcast your intention to bump up the fee and change the address or the amount or something, and the other client is programmed to reject it / consider it invalid if you do that.

If a miner mines transaction (b) and does not consider it invalid => he is orphaned by those who are running the proper client and say "what the fuck did you include in your block? GTFO"

It sounds trivial to me, but then again I'm not a coder so... I suspect the complexities arise from the soft forking approach and trying to satisfy everyone and retain compatibility with all.

[achow101]

-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?

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

I'm trying to think about this algorithmically and I don't see why...

a) You broadcast your intention to bump up the fee, the other clients are programmed to accept it.
b) You broadcast your intention to bump up the fee and change the address or the amount or something, and the other client is programmed to reject it / consider it invalid if you do that.

If a miner mines transaction (b) and does not consider it invalid => he is orphaned by those who are running the proper client and say "what the fuck did you include in your block? GTFO"

It sounds trivial to me, but then again I'm not a coder so... I suspect the complexities arise from the soft forking approach and trying to satisfy everyone and retain compatibility with all.

No. RBF is not a consensus rule which causes forks. Transaction standardness is a node policy and should not be a consensus rule. By forcing transaction standardness to be a consensus rule and simply not node policy, then you are making experimentation with different transaction formats and nonstandard transactions be against consensus rules, which should not be allowed as that will make it more difficult to experiment and create new stuff.

RBF and relaying RBF transactions are simply node policy. Nonstandard transactions that make it into the blockchain are still accepted because although they aren't standard transactions, they are not technically invalid.

[AlexGR]

-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?

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

I'm trying to think about this algorithmically and I don't see why...

a) You broadcast your intention to bump up the fee, the other clients are programmed to accept it.
b) You broadcast your intention to bump up the fee and change the address or the amount or something, and the other client is programmed to reject it / consider it invalid if you do that.

If a miner mines transaction (b) and does not consider it invalid => he is orphaned by those who are running the proper client and say "what the fuck did you include in your block? GTFO"

It sounds trivial to me, but then again I'm not a coder so... I suspect the complexities arise from the soft forking approach and trying to satisfy everyone and retain compatibility with all.

No. RBF is not a consensus rule which causes forks. Transaction standardness is a node policy and should not be a consensus rule. By forcing transaction standardness to be a consensus rule and simply not node policy, then you are making experimentation with different transaction formats and nonstandard transactions be against consensus rules, which should not be allowed as that will make it more difficult to experiment and create new stuff.

RBF and relaying RBF transactions are simply node policy. Nonstandard transactions that make it into the blockchain are still accepted because although they aren't standard transactions, they are not technically invalid.

Ah yeah, network and miners division, right... makes sense. There could be no invalidation from ...competing broadcasts. Ok got it.

[gmaxwell]

If the potential of your transaction being replaced would be disadvantageous to you, you simply wouldn't make the transaction non-final. Though, of course, miners can replace anyways because the transactions aren't confirmed yet.

A lot of the discussion above is suffering from common misunderstandings of what "first" means, in a asynchronous distributed network there is no such thing as a universal "first"-- what you see as first someone else will see as second.  If not for this fundamental physical truth there would be no need for mining.

[theymos]

If QC comes into existence, then that is a very major problem which should be fixed ASAP in any case.

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.

It seems very unlikely to me that a QC will be created, then the tech will advance to the point that real-world keys can be broken in less than years, and all of this will be kept secret until it becomes an emergency. These government agencies are full of many people, and people are bad at keeping secrets. If this does happen, it can be survived due to the QC-resistance of Bitcoin addresses, but hurrying to plan for this seems like premature optimization. Especially when the current state-of-the-art in QC-proof signatures have massively larger signatures than ECDSA, and bandwidth is currently a pretty big bottleneck.

There is a flag for disabling the RBF policy, -permitrbf=0.

IIRC the Core devs do have code prepared for adding QC-proof signatures to Bitcoin as a softfork (using a variant of Lamport signatures optimized for minimal size, especially in the scriptPubKey), though AFAIK this code isn't public.

[AlexGR]

Nice to have contingencies in place

As for the bloat, I guess we'll have to wait for some kind of genius solution or workaround.

[watashi-kokoto]

I think migration to quantum proof system would be trivial. No funds would be lost.

[funkenstein]

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?

These things have zero to do with one another.  If ECDSA is strongly broken somehow, in that the private key is obtainable from the public, then any transaction broadcast publicly spending a coin is stealable.  Whether or not miners are implementing RBF or not doesn't matter.     

[AlexGR]

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?

These things have zero to do with one another.  If ECDSA is strongly broken somehow, in that the private key is obtainable from the public, then any transaction broadcast publicly spending a coin is stealable.  Whether or not miners are implementing RBF or not doesn't matter.     

RBF should make it much easier, no?

[funkenstein]

RBF should make it much easier, no?

Am I missing something?  I don't see how RBF changes anything here. 

[AlexGR]

=>

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.

If it was the exact same thing with, or without RBF, then there would be no extra protection against such a scenario by disabling it, right?

[CIYAM]

My understanding was that RBF doesn't let you change the tx other than effectively its fee (i.e. inputs could be added but not outputs) - did I miss something?

[criptix]

My understanding was that RBF doesn't let you change the tx other than effectively its fee (i.e. inputs could be added but not outputs) - did I miss something?

Last i read you should be able to change the whole tx which was kinda problematic because of double spending.

I dont see a link between broken ecdsa and rbf.