Topic: disallowing RBF (replace-by-fee) (Read 303 times)

I agree it is confusing, but in my post above the word "consensus" is referring to the consensus rules as hosseinimr93 has explained, and not to a "general agreement" between all node runners. RBF rules are a local policy, and even if 100% of nodes enforce the same RBF policy, a block containing a valid transaction which breaks that policy (such as a replacement transaction which evicts >100 other transactions) will still be valid and will still be accepted by all these nodes because it does not break the consensus rules.

You might be interested in reading this page: https://en.bitcoin.it/wiki/Consensus

This was actually the original use of the nSequence field in transactions. Any unconfirmed transaction which had an input with an nSequence of less than 0xFFFFFFFF was not yet considered finalized and could be replaced by a conflicting transaction with a higher nSequence value. And so the upper limit was effectively 4,294,967,295 (0xFFFFFFFF in decimal).

An upper limit means each node would have to keep track of all previous replacements, and not every note may have seen all of them. So it won't work.

Consensus rules are the rules that must be obeyed, so that the transaction or the block is valid and accepted by other nodes.

For example, one of consensus rules is that the the total value of inputs must be equal or greater than total value of outputs.
If a miner includes a transaction in which the total value of outputs is bigger than the total value of inputs, the block would be rejected by nodes, because it doesn't follow consensus rules.

Some rules are usually followed by nodes and miners, but it's not that miners and nodes have to follow them. These rules are called standard rules.
For example, almost all nodes would reject any transaction with the fee rate of less than 1 sat/vbyte, but miners are free to include a transaction with zero fee.

BIP125 isn't a consensus rule.
Assume that I have broadcasted a transaction paying 50 sat/vbyte and that's still unconfirmed.
If I broadcast a new transaction with the same input(s) paying 1 sat/vbyte, almost all nodes will reject the new transaction, but there's nothing that stop a miner from including the second transaction and a block including the second transaction would be valid.

What I said in my previous post is a policy that is followed by almost all nodes. That's standard rule, not a consensus rule.
Assume that I have made 110 transactions and they are all unconfirmed. Now I want to make a new transaction that would invalidate all those 110 transaction. Almost all nodes will reject my trasnaction, because it doesn't follow BIP125 rules.
What will happen if a miner include my new transaction? Would the block including that transaction be valid? Yes, the miner wouldn't break consensus rules and the block would be valid.

I think I have to disagree with you here! The consensus is reached when the majority of a group agrees to something or to do something. The 100 policy is a consensus in this case and no longer a policy because we all know that the majority of node operators will not change this setting. If the majority of nodes agree to something then this becomes a consensus, not a policy or a default setting.

There is no limit when it comes to consensus rules. Miners can include any valid transaction in the blockchain.
But according to BIP125 (which is a policy and not a consensus rule), nodes accept the replacement transaction if the number of transactions that would be evicted from the mempool by doing so doesn't exceed 100.

Does anyone know if there is any implemented limit to the number of replacements in RBF? Or is this also up to each full-node the miner used for mining the corresponding block and there is absolutely no upper limit for the number of RBF replacements? I vaguely remember reading something about this somewhere, but I can't find it anywhere.

RBF is not consensus - it's policy.

There has been nothing stopping nodes from accepting full RBF transactions, or from miners mining full RBF transactions, since day one of bitcoin. It is a local policy in Bitcoin Core to enforce opt-in RBF, but any node could have opted out of that and accepted full RBF transactions at any time, which is why zero confirmation transactions were never safe. The recent change to implement the full RBF setting simply makes it easier for nodes to do that, and will eventually move towards that being the default setting. But again, that will be policy, not consensus. Any node will still be free to reject full RBF transactions if they wish.

Since we're in Electrum board, his suggestion to utilize nSequence field is equivalent to disabling replace-by-fee setting in older Electrum versions.
Opt-in RBF is still being enforced by nodes that didn't enabled "mempoolfullrbf" settings.
So it makes sense but not different from the original concern of opting-out from opt-in rbf being less effective.

This is like saying we need to go back prior to core 24 and prior to implementing full-rbf.
What you are suggesting is to flag a transaction as full-rbf or not-rbf which doesn't make much sense. Please enlighten me if I'm getting this wrong. Afaik, it's all about the consensus, not about your nodes settings.

It's not really a Bitcoin problem: the real "solution" is of course to create random private keys, instead of using a very limited range. I'd like to see how many addresses get RBFed when the puzzle creator decides to move all funds.

thanks for your answers. right it's about bitcoin puzzle 66 and 67.
as soon as the public key becomes visible in the mempool anyone can calculate the privkey within a few seconds and grab coins.
as far as i understand RBF is no solution for the mentioned problem. is there no other solution without submitting the transaction
to a miner pool- that wouldn't be an option either as lack of trust. so with mempool there is no hope and the privkey would be
compromisable,no other solution?

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.

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.

I see

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

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.

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 ?

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

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#

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)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.


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.

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.

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.