Topic: Does replacement interact with quantum computers? (Read 2113 times)

Ah OK, I think I see what you are saying.  Of course just like nothing has stopped miners from doing a RBF or any other scheme they like for choosing TXes since block 1, nothing could stop them in this scenario from grabbing the privkey and taking the funds. 

if ecdsa is broken through qc we can take a pubkey from a tx and compute the corresponding private key => steal funds from wallet.
the transaction itself would go through and you would not be able to steal it.

now with rbf activated you can even steal the funds in the transaction.

(although the timeframe should be quite short)

Yes, I also don't understand what knightdk is talking about here  

RBF is about which TX goes into a block.  What does this have to do with ECDSAsec? 

Yeah i see, you are correct.
I was just thinking about the publickey - privatekey relation not about the funds in the transaction itself.

It does allow for most of the transaction to be replaced (still has to include at least one input to actually be replacing something). However I don't think most wallets will give you the option to double spend. I think that most wallets will only have an option to boost your fee rather than double spend the transaction. Of course, if someone was being malicious, they probably don't even need a wallet that gives them the option to double spend.

If ECDSA is broken by QCs and the private key can be revealed from the public key in less than 10 minutes, an attacker with a QC could find that private key and attempt to double spend the inputs in the transaction that originally had the public key. With the current node policy, if they made a double spend attempt, it would probably fail due to the first seen behavior of nodes. Those nodes would already have seen the original transaction and thus reject the double spend. With RBF, if the attacker simply increased the fee in his malicious transaction, his transaction would be able to replace the original transaction if the original had opted in to RBF. This would make stealing the coins slightly easier, but only if the transaction opted in to RBF.

Yup. The proposal to only allow changing fee was called FSS RBF (First-Seen-Safe Replace-by-Fee) but afaik it was too complicated to implement.

Oh - I hadn't realised this was the case (that makes me rather less enthusiastic about RBF - I can now envision someone creating a wallet with a "double spend" button).


A double-spend attempt is a double-spend attempt but perhaps the attempt itself is made easier with RBF.

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.

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?

=>


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?

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

RBF should make it much easier, no?

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.     

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

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.

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.

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.

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

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.

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.

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?