Complete RBF is on the horizon

Looks like we're gonna see complete RBF in Bitcoin pretty soon, but I haven't noticed anyone talking about it here yet. Check out these links for more info and discussions: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html https://github.com/bitcoin/bitcoin/pull/25353 https://github.com/bitcoin/bitcoin/pull/25373 For those who haven't been following, the short version is that there's a plan to add a new setting for nodes. This would make every unconfirmed transaction in a node's mempool treated as RBF enabled, no matter if it signals for RBF or not. Right now, the default will still be that this setting is off, so we'll stick with the current opt-in RBF rules, but nodes can choose to switch to full RBF if they want. There are some solid reasons to go this route, like enhancing security and making multi-party funded transactions (think coinjoins, Lightning, and other layer 2 stuff) safer. But it does mean businesses will likely stop accepting zero-confirmation transactions for small amounts since any transaction (even those not opting in) could be replaced with RBF. I'm also really curious about what happens when half the nodes have full RBF turned on and the other half don’t, and I try to replace a transaction that opted out. And what if I'm using a hot wallet and not my own node?

It is likely that most nodes will implement the Full RBF and here are my reasons: The mining Nodes will benefit in this aspect because having transaction default with Full RBF allows signers to boost transactions with more fees whenever the mempool becomes congested making them earn more sats from transactions fees. There is also a high chance that other SPV wallets will follow the adoption just to keep their customers in the circle so that they don't move to other hots wallets that run their own nodes with full RBF feature for users but how soon I can't say. If a transaction has been flagged as RBF by a node, does block explorer has the ability to exclude it from transaction details? If the node you are connected has an RBF enable, that shouldn't be a problem with any explorer or is there going to be a change in RBF when nodes relay transactions within the network?

What I am thinking too, also just because of what you stated already, it will also help the mempool to be less congested as some people will be able to pump the fee and increase the chance for the unconfirmed transaction'to be included into a block. But that is not what o_e_l_e_o is asking. Even if 90% nodes signal for it, there will be a time at the start that just less than 50% nodes will signal for it and the number of nodes that will be signalling it will be increasing. If it is 50% to 50% of the nodes that signal and that do not signal, that it is possible some transactions in the mempool of the signal nodes to flag the transaction as RBF while those that did not signal will have the transaction as non RBF. So which one will be included into a block and be confirmed? Yes, just like https://www.blockchain.com/explorer?view=btc do exclude it while some do include it. The thing is it is possible an unconfirmed transaction which is non RBF will be flagged as RBF on some mempool (mempool of the nodes that have signalled for it already) and remain not flagged as RBF on some other mempool (mempool of the nodes that have not signalled for it).

I guess that for a while there may look like a lottery. A replacement transaction of a non-RBF may have a bigger (than 50%) chance to get rejected even if 50% of the nodes are using the new code (unless I misunderstood something). But it should be pretty much okay, we do know that if we want RBF it should be signaled and we do know that a transaction cannot be trusted unless it's mined. And I do think that after this implementation (when the vast majority will have it in use) the way the mempool works will be more predictable. Yeah, it's a somewhat bad news for the services that were boasting 0-confirmation deposits. But they can use LN now.

Most SPV wallets, such as Electrum, do not run their own nodes. It will be entirely up to the individuals running Electrum servers whether they enable full RBF, or leave it turned off (as is the default). There will also be plenty of nodes running older software and plenty of nodes who simply don't bother to enable it because they don't see the point, can't be bothered, are unaware of the change, etc. We will probably get to a network wide enabled scenario eventually (if not through individual nodes enabling it then through it becoming enabled by default in future versions), but we must still move through the part-enabled part-disabled phase to get there. The transaction won't be flagged as RBF by a node. A transaction is only ever flagged as RBF by the person who creates that transaction. Nodes with full RBF enabled will treat all transactions as RBF enabled even if a transaction is not RBF flagged. That wouldn't have made a difference. Read from "# 2nd issue : RBF opt-out by a Counterparty Double-Spend" on this link: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html. The very ability to broadcast a non-RBF transaction, whether or not some wallets use it by default or not, creates an attack vector for such transactions. Speaking from personal experience, the number of merchants I use which accept zero confirmations for low value transactions is much higher than the number of merchants I use which use Lightning. I suppose this change will force them to adapt.

If you use light wallet and managed to connect to server which relay full RBF transaction, it's likely your transaction will receive on miner mempool. Each node connect to at least 8 other node, so in average 4 of them will continue to relay your transaction. It's also bad news for user who only occasionally spend their Bitcoin on such services. It's unlikely they'll bother use LN wallet or lock their Bitcoin on LN channel when they only make transaction once in a month.

I didn't see much talk about this RBF news outside bitcointalk forum, maybe because everyone is talking about crash and bear market now   I think there is a good chance that companies and regular members will rather accept Lightning payments for smaller values instead of using Bitcoin on main chain. Fees are smaller this way especially during the time when there is congestion in mempool like we saw recently.

Does this mean that the RBF will be the default only if the majority of node operators enable the setting?  The other question is if this the first step, and  will the default setting eventually become RBF enabled?  Probably too early to say. I read the post by Antoine Riard, much of the technical stuff is over my head.  I'm not sure how RBF adds security to Multi-Party transactions, is just to get people used the fact that a transaction isn't guaranteed (or on it's way to becoming guaranteed) until there's at least one confirmation? For brick and mortar shops who've been accepting bitcoin already I don't think this is a big deal as most people tend to be honest when dealing locally and face to face.  For online retailers it may be an issue if they're selling digital items that customers want to download instantly.  As LN becomes more and more common, it'll become a non-issue. This is an interesting question.  It seems like it's up to the node operators to enable this feature, and it's purely democratic i.e. it'll take a majority of nodes enabling the feature to make the whole network full RBF.  Am I correct in my understanding?  Or will clients be able to pick and choose regardless of how may nodes enable the feature?

I don't really have experience with that, I use RBF even when I shouldn't really, so I am used to wait for confirmations. If the use of LN is that good, that's a good news. Good point. People will have to wait for at least one confirmation if they go on-chain. If I'd do that I would at least consider using a custodian LN wallet (like blue wallet). Not a perfect solution, but it does the job once in a while.

The default is for full RBF to not be enabled. Individual nodes can choose to enable it for transactions in their mempool, but if I enable it and you don't, then you will continue to run with the current opt-in RBF rules. Even if every other node enables it and you don't, then you will continue to run with the current rules. I think almost certainly yes. Here is the relevant section. I'll try to simplify it below: Consider any transaction which requires inputs from more than one party. Coinjoins and Lightning channels are the most common examples. I can DoS such a transaction by providing my input, and then while all the other inputs are being collated, double spend that input in a non-RBF transaction, meaning the original transaction will fail and the other parties will all have wasted their time. The next step up is to consider your layer two client which is connected to your node. You submit the Lightning channel transaction (for example) to your node, but I'm already spreading my non-RBF double spend through the rest of the network. Your client then repeatedly tries to use CPFP to bump the fee since it just sees the transaction not confirming, at which point I can invalidate my non-RBF double spend by replacing an RBF enabled unconfirmed parent, allowing your transaction to propagate and forcing you to pay the full excessive CPFP fee. This could become a serious issue if various wallets, services, platforms, etc. decide to start DoSing their competitors in order to attract business to themselves. No. This isn't a case of signalling for a network wide change, but rather a case of node operators choosing the behavior for their own node.

Why don't we utilize first-seen-safe RBF then? If the problem is to annoy the other party/parties by cancelling the CoinJoin or channel opening transaction, we can give a solution by accepting only transactions that spend to the same outputs, equal or greater amounts. I don't understand this part. Since you've let a non-RBF transaction been propagated, how can you cancel it with an RBF unconfirmed parent?

If I have got o_e_l_e_o correctly: The non-RBF transaction is invalidated with double-spending its unconfirmed parent (which is RBF-enabled). With invalidating the parent, the child (which was spending the same UTXO as the coinjoin transaction) is removed from the mempool and the coinjoin transaction can be propagated and confirmed.

I might be missing something too, but I don't think the purpose is merely to annoy/harass the other parties, but to delay confirmations until the RBF/CPFP algorithm gets close to maximum fee range, then the attacker sends his own RBF transaction and forces everyone to pay that high fee.  The attack vector would require a a miner with a lot of hashing power to take advantage of the attack.  I don't know how practical/profitable of an attack vector it really is, I mean if the miner's equipment is as finicky as mine I'm sure he's got bigger fish to fry.

With FSS, if the rest of the network sees my malicious double spend first (which is how the attack takes place), then they will refuse to replace it even with the higher fee paying multi-party transaction (coinjoin, Lightning channel, etc.) hosseinimr93 is correct. For further expansion: I make Transaction A, which spends UTXO 1 and creates UTXO 2, and is opted-in to RBF. I then use UTXO 3 to join a multi-party transaction. At the same time, I make Transaction B, which spends the unconfirmed UTXO 2 and UTXO 3 and is opted-out of RBF, and broadcast Transaction 2 to the rest of the network. As the rest of the network has seen Transaction 2 first, which is non-RBF, they consider the multi-party transaction to be a double spend and reject it. Once the affected party has maxed out their fee reserves with repeated CPFP attempts, I can then replace Transaction A (which is RBF enabled), send UTXO 1 somewhere else which means UTXO 2 no longer exists, means Transaction B is now invalid, frees up UTXO 3 to be used by the multi-party transaction, and the rest of the network will now accept the multi-party transaction and its excessively high fee paying CPFP children. It can be either - wasting time or wasting fees. It doesn't require any mining power at all. The attack can take place as I've described just above in this post.

Wait, if I don't upgrade my full node to a newer version, I am risking getting an incomplete (wrong) version of mempool and, therefore, won't be able to verify independently everything that happens in the blockchain? It all sounds like, with this change, we are doing intentional hardfork forcing everyone to upgrade to modified software, albeit without changing consensus rules. That still may cause network partition and a decrease in decentralization because part of the nodes (pre-full RBF ones) will lose their status as being considered full nodes since they no longer will be able to conduct full verification of valid transactions.

Even if some nodes don't enable full RBF, there won't be any new chain and we won't have any hard fork. It's possible that a transaction exists in a mempool while it doesn't exist in another mempool, but all nodes will still have the same blockchain.

Here's the way I see it: Let's say Alice does not enable full RBF, but Bob does. Carol broadcasts a transaction which is not opted in to RBF, which propagates to both Alice and Bob's mempools. Carol then broadcasts a replacement transaction. Alice, running the old rules, rejects the replacement transaction as a double spend, while Bob, running the new rules, accepts the replacement transaction as an RBF. Alice therefore has the old transaction in her mempool, while Bob has the new transaction in his. At some point, one of these two transactions will be mined in to a block. Which one is mined will depend on a variety of factors, such as how many nodes are running the old or the new rules, how much hashrate sees the original transaction or the new transaction, the fees both transactions pay, which miner is lucky enough to find the next block, and so on. Once the next block is found, then all nodes, regardless of which rule set they are using, will be able to validate the transaction which was included in the block, and if necessary, remove the other one from their mempools. If the original transaction confirms, full RBF enabled nodes like Bob will eject the replacement, and if the replacement confirms, full RBF disabled nodes like Alice will eject the original.

The only problem is that Alice verifies the confirmed transaction post factum, and, therefore, plays less significant role in enforcing the consensus rules. If all transactions are to be replaced using full RBF rules, then Alice is basically cut off from the rest of the network.

This was the primary way of RBF at that time when there were plans to either get FSS-RBF or Opt-in RBF on the network. There are many different risks and hassle with FSS-RBF, namely with it being subjective to the different miners and that it provides a false sense of security with no security benefits whatsoever. It was only adopted by Discus Fish (AKA. F2Pool) and dropped shortly afterwards. RBF (Opt-in or not) does not prevent fraud or anything like that, merely making it slightly harder for the average person but doesn't make them immune. I don't foresee it to be a problem. Users generally do update their nodes, and currently 18% of the network runs 0.23 and 50% of the network runs 0.22. The number of hops that it takes to reach a miner should still be acceptable and you shouldn't have a case where it gets stuck due to nodes stopping the propagation of the transaction. Miners are generally very well connected to a myriad of nodes. However, the main concern should be whether the miners are willing to change their policy and start accepting these kind of transactions. Peering should be a no issue because it is usually done by recognizing the service flags of their peers. It shouldn't be too difficult to have a service flag where the node attempts to connect to another which has full-rbf enabled.

That's unfortunate, I do like the occasional zero confirmation transaction that's instantly accepted. RBF doesn't empty mempool, for every transaction that gets into a block because of the increased fee, there's another transaction that doesn't make it anymore. Isn't that the same now? If you use RBF, there are 2 valid signed transactions out there, and it's up to the miner to choose which one to include. The one with the highest fee is most likely to get confirmed, but there are no guarantees. I admire your confidence in people's honesty And even though I agree most people would be honest, I fear this would attract dishonest people who see an opportunity to scam a shop.