Does replacement interact with quantum computers?

[CIYAM]

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

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

I dont see a link between broken ecdsa and rbf.

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

[1715278092]

1715278092

[pawel7777]

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.

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.

[achow101]

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

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

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.

I dont see a link between broken ecdsa and rbf.

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

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.

[criptix]

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

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

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.

I dont see a link between broken ecdsa and rbf.

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

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.

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

[funkenstein]

=>

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?

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? 

[criptix]

=>

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?

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? 

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)

[funkenstein]

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)

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.