disallowing RBF (replace-by-fee)

[yoshimitsu777]

the latest electrum version dont allow user disabling RBF.
i think bitcoin core allows to disable this but i guess you need to run a full node that is not pruned that is not the way i like to go.
is there any other wallet soft that i can use to make a transaction with RBF disabled?
i want to ensure that RBF will not be used at all and nobody can change or cancel that transaction.
is a miner or pool able to override the RBF DISABLED setting and still advertise my transaction with RBF flag enabled on mempool?

please someone advice and teach me which wallet to use and how to disable RBF function.

[1714259638]

1714259638

[1714259638]

1714259638

[tbct_mt2]

the latest electrum version dont allow user disabling RBF.

I don't remember when Electrum makes RBF as their wallet default setting for user but it is their right decision and very helpful for Electrum users especially newbies who broadcast their first Bitcoin transactions through Electrum wallet.

They will even not know about RBF but with this default opt-in RBF, they will be able to bump fee (increase fee) later if they need to use RBF.

It's not wise to allow users to turn it on and off because newbies probably mistakenly turn it off.

[Zaguru12]

i want to ensure that RBF will not be used at all and nobody can change or cancel that transaction.

Then you will need to use some old wallets that do not actually have an RBF opt in. The two wallet I think of now is mycelium and trust wallet. But even though I don’t think someone without access to your keys will not be able to cancel or change your transaction with or without RBF feature.

is a miner or pool able to override the RBF DISABLED setting and still advertise my transaction with RBF flag enabled on mempool?

The issue now some mining nodes actually have Full RBF opt in and if the server is use to broadcast your transaction I think that makes the transaction an RBF enabled.

I don't remember when Electrum makes RBF as their wallet default setting for user but it is their right decision and very helpful for Electrum users especially newbies who broadcast their first Bitcoin transactions through Electrum wallet.

They have actually removed opt in RBF from version 4.4.0 and made it a default according to this announcement . Since the full RBF default is growing everyday on various nodes then I think opt in will soon be a thing of the past.

[Charles-Tim]

Why don't you want to make your transaction support replace-by-fee?

On Bluewallet, after you click on send, at the top right corner, click on the three the dots and disable RBF for that transaction
 
On Samourai, click on icon at the top left corner -> settings -> transactions. Then uncheck RBF.

No RBF on Mycelium.

[Aanuoluwatofunmi]

please someone advice and teach me which wallet to use and how to disable RBF function.

My own question is why is RBF being disabled your major concern, it's been there doesn't mean that you must make use of the function, as to complete your desirability, you can always disable this right from making your transactions by checking the button that disallowed for RBF function, i don't know about blue wallet if it's also allows for RBF like the way electrum wallet did, but am very sure of the two examples given already by zaguru, mycellium and trust wallet.

[Charles-Tim]

My own question is why is RBF being disabled your major concern, it's been there doesn't mean that you must make use of the function, as to complete your desirability, you can always disable this right from making your transactions by checking the button that disallowed for RBF function, i don't know about blue wallet if it's also allows for RBF like the way electrum wallet did, but am very sure of the two examples given already by zaguru, mycellium and trust wallet.

On Electrum, RBF is the default and it can not be disabled anymore. On Bluewallet, you can make use of RBF and also you can disable it just like I have explained above.

Mycelium do not support RBF. Trustwallet also do not support RBF and it is a close source wallet. Aside from those, it is one of the worst bitcoin wallet, only altcoins users are the ones that are using it that may not have complain.

There are many other close source wallets like Coinomi, Atomic wallet and others which do not support replace-by-fee and not advisable or recommend. They are wallets bitcoin users supposed to stay away from because there are many open source bitcoin wallets. There are also many open source bitcon wallet that you can disable the replace-by-fee but which I am lazy to research on for now.

[hosseinimr93]

i want to ensure that RBF will not be used at all and nobody can change or cancel that transaction.

Can I ask you what exactly you worry about? Do you think your wallet may be compromised?

Note that you can replace a transaction with a new one only if you have the private key of one of receiving addresses. If your wallet is compromised, your fund can be stolen right now.
And even if you broadcast a RBF-disabled transaction, as long as it's unconfirmed, anyone who has access to your private key may be able to replace that with a new one.

[LoyceV]

Why don't you want to make your transaction support replace-by-fee?

The only reason to want non-RBF transactions, is to accept zero-confirmation transactions. But, with more and more full-RBF nodes, you shouldn't rely on that. Just wait for a confirmation to be sure.

[Charles-Tim]

The only reason to want non-RBF transactions, is to accept zero-confirmation transactions. But, with more and more full-RBF nodes, you shouldn't rely on that. Just wait for a confirmation to be sure.

Yes, exactly. In the past, I accepted no confirmation transaction if the fee used is high enough to make the transaction get confirmed in the next block. But since nodes can enable full RBF and non RBF transactions can still be replaced, I do not do that anymore. At least I wait for one confirmation. I also see no reason why OP need transactions that is not supporting RBF.

[citb0in]

Why don't you want to make your transaction support replace-by-fee?

The only reason to want non-RBF transactions, is to accept zero-confirmation transactions. But, with more and more full-RBF nodes, you shouldn't rely on that. Just wait for a confirmation to be sure.

I can think of another one:

There are some Bitcoin puzzle hunters who are currently struggling at the 66bit puzzle. The following scenario. Alice finds the correct private key to the address and will generate a transaction to send the 6.6 BTC to her private wallet address. From the moment Alice sends the transaction, it ends up in the mempool and the publickey becomes visible there. The private key can be generated from the publickey within a few seconds or minutes (depending on the hardware and computing capacity used) because of the low bit-range of only 66bit.

Mallory used a self-written script to monitor the mempool constantly for a transaction that has this 66bit wallet address as input. As soon as the script finds this transaction, the pubkey attack is carried out and Mallory reveals the private key in a short time. Mal now creates a new transaction with a higher fee and his own private wallet address as the output. The 6.6 BTC would now go to Mallory and Alice would look stupid.

In my opinion, it doesn't matter which wallet software you use, because even if it gives you the option of switching off RBF, it doesn't mean that the mempool will adhere to it. Your wallet software would signal that you don't want to use RBF, but if the node is configured that way (and from bitcoin core 24 it does by default) then it will activate and use full-rbf anyway.

The only way I can see here would be to run a full node, explicitly deactivate full-rbf (not to be confused with opt-in rbf!) and put your transaction in there. However, I'm not sure if that would be the ultimate solution. My doubt would be that the forwarded transaction could be overwritten by the local full-RBF setting of the node forwarded. You would have to clarify whether the setting of the initial node has priority, or whether the mempoolfullrbf=0 setting can be overwritten by subsequent nodes with mempoolfullrbf=1.

[gunhell16]

In my opinion, RBF is beneficial to bitcoin holders when they deal here, or, in other words, it creates options contracts that allow bitcoin investors to lock in a specific price in their holdings.

Then it protects against abrupt price declines. Furthermore, as far as I know, it may be utilized for bitcoin exposure and in a portfolio that is less connected with other traditional assets. This can help to minimize the total risk of the portfolio.

[nc50lc]

In my opinion, it doesn't matter which wallet software you use, because even if it gives you the option of switching off RBF, it doesn't mean that the mempool will adhere to it. Your wallet software would signal that you don't want to use RBF, but if the node is configured that way (and from bitcoin core 24 it does by default) then it will activate and use full-rbf anyway.

The only way I can see here would be to run a full node, explicitly deactivate full-rbf (not to be confused with opt-in rbf!) and put your transaction in there. However, I'm not sure if that would be the ultimate solution. My doubt would be that the forwarded transaction could be overwritten by the local full-RBF setting of the node forwarded. You would have to clarify whether the setting of the initial node has priority, or whether the mempoolfullrbf=0 setting can be overwritten by subsequent nodes with mempoolfullrbf=1.

The option mempoolfullrbf is exclusively set to the owner's node's mempool setting and not to the relayed transaction.
Its more of an option that tells if the node should accept replacement for any transaction from its mempool.
So it wont change the relayed transaction's rbf flag, it will just accept a replacement regardless of the transaction's opt-in rbf false flag, while others wont.

The success rate depends on the number of nodes (mempools) that enabled that option and if it can reach a miner (solo/pool) that has mempoolfullrbf=1.

Otherwise, it a good example since a 10-minute blocktime is enough for the attacker to steal the puzzle reward.
At least for now, while not all nodes and miners are using full-rbf, having false opt-in rbf flag makes a difference in that use-case.

[LoyceV]

I can think of another one:

There are some Bitcoin puzzle hunters who are currently struggling at the 66bit puzzle.

That's a good point, I guess those puzzles will (eventually) have the faith as transactions from leaked private keys: most if not all funds will go to miners. It was predicted here and already happened here.

The only way I can see here would be to run a full node, explicitly deactivate full-rbf (not to be confused with opt-in rbf!) and put your transaction in there.

That doesn't matter, other nodes can do full RBF anyway. And miners would be dumb not to do it: higher fees mean more income for them.

[citb0in]

I fear the same, without starting another debate about Full-RBF vs. No Full-RBF.

In the example shown, what other options would the lucky finder of the puzzle have to minimize this risk? He doesn't know when the next block will be mined, so he sends the transaction to the mempool a few seconds beforehand, which is simply impossible. I also see it as critical to send the transaction to one of the large mining pools and hope that they grab the block and mine it so that the transaction never becomes visible in the mempool. There would be an immense amount of trust involved in sending such sensitive information to them in such a case.

the only way out of this mess that I can see here would be the correct use of nsequence. If you use 0xfffffffe the new transaction will not be explicitly bip-125 replaceable (though it may still be replaceable in practice, for example if it has unconfirmed ancestors which are replaceable). You could also use the maximum possible value of 0xffffffff however I'm not sure if this will be interpreted at all (in former version of bitcoin core it was useless)

[tbct_mt2]

Why don't you want to make your transaction support replace-by-fee?

It is very inconvenience to have No RBF transaction. Because if mempools suddenly loaded and congested, the user will have only one choice, using Child Pay For Parents but it requires more expensive fee than using Replace by Fee to increase the fee. It also requires the user has control of the receiving transaction that sometimes the user will not have that control.

Not all times we will need to use RBF but always have RBF opt-in for all transaction is good as reserve for emergency when we need bumping fee for a pending transaction. We can completely control it.

No RBF only can be accepted in mempools that support Full RBF but not all do this.

https://mempool.space/rbf#

[nc50lc]

In the example shown, what other options would the lucky finder of the puzzle have to minimize this risk?
-snip-
the only way out of this mess that I can see here would be the correct use of nsequence. If you use 0xfffffffe the new transaction will not be explicitly bip-125 replaceable (though it may still be replaceable in practice, for example if it has unconfirmed ancestors which are replaceable).

Nodes with mempoolfullrbf=1 still won't acknowledge if a transaction has opted-out, aka used 0xfffffffe/0xffffffff nSequence.
It basically removed the nSequence requirement for a transaction to be replaceable.

It's not a different thing from OP-in RBF since BIP-125 "Opt-in Full RBF Signaling" is the OP-in RBF that we use.
The nSequence is the actual data that's changed in the transaction if it opted-in/out to be replaceable.
There's still risk if someone managed to broadcast a replacement with higher fee to a pool or solo miner that supports full-rbf (mempoolfullrbf=1).

[citb0in]

There's still risk if someone managed to broadcast a replacement with higher fee to a pool or solo miner that supports full-rbf (mempoolfullrbf=1).

even if the mempool has already seen a transaction that has nSequence=0xffffffff despite it has lower fee that the attacker tries to beat by higher fee ?

[o_e_l_e_o]

even if the mempool has already seen a transaction that has nSequence=0xffffffff despite it has lower fee that the attacker tries to beat by higher fee ?

Yes. The nSequence is irrelevant when it comes to full RBF. Full RBF means any transaction can be replaced, provided the replacement transaction meets the other requirements as stipulated in BIP125 regarding unconfirmed inputs, fees, and evictions.

In the case of the puzzle hunters that you have brought up, the only safe way for the puzzle hunter to get their transaction mined will be to mine it themselves, in secret. As soon as they broadcast the transaction using any method (even their own full-RBF-disabled node), then it is at risk of being replaced. If they share it privately with a third party miner, then that miner could replace it as well.

[citb0in]

I see

https://en.bitcoin.it/wiki/BIP_0125
https://en.bitcoin.it/wiki/Transaction_replacement

[Synchronice]

i want to ensure that RBF will not be used at all and nobody can change or cancel that transaction.

RBF doesn't mean that others will be able to cancel your transaction or change something. RBF means that only you will be able to increase fee or cancel transaction by doing double spend. Even without double-spend, if your transaction's fee is very low and nodes forget it, it will be automatically cancelled. The only way to prevent it is to rebroadcast your transaction every time but that doesn't make sense either.
You can use old version of Electrum but keep in mind that soon every transaction will automatically be RBF enabled.

The only way I can see here would be to run a full node, explicitly deactivate full-rbf (not to be confused with opt-in rbf!) and put your transaction in there.

That doesn't matter, other nodes can do full RBF anyway. And miners would be dumb not to do it: higher fees mean more income for them.

Miners will profit more from non-RBF transaction because full-RBF gives everyone possibility to match the fee to what's recommended but when people make non-RBF transactions with low fee, they have to use 3rd party services like mempool.space accelerator, paid ViaBTC accelerator, Binance accelerator and so on. These services are partnered with miners and together charge ten times more than what would be necessary via simple RBF increase.