Topic: disallowing RBF (replace-by-fee) (Read 329 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.