disallowing RBF (replace-by-fee)

[yoshimitsu777]

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?

[1714589650]

1714589650

[1714589650]

1714589650

[1714589650]

1714589650

[LoyceV]

right it's about bitcoin puzzle 66 and 67.
~
no other solution?

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.

[khaled0111]

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.

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.

[nc50lc]

-snip-

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.

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.

[o_e_l_e_o]

Afaik, it's all about the consensus, not about your nodes settings.

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.

[citb0in]

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.

[hosseinimr93]

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.

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.

[khaled0111]

..

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.

[hosseinimr93]

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.

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.

[LoyceV]

Does anyone know if there is any implemented limit to the number of replacements in RBF?

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.

[o_e_l_e_o]

The consensus is reached when the majority of a group agrees to something or to do something.

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

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.

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