Topic: Full RBF - page 8. (Read 3043 times)

Very marginally. Most of the transactions shouldn't require RBF especially with periods of low fee rates and low fee volatility. Miners are known to be fairly slow at signalling support for various different protocol upgrades so that by itself already means that there is low incentives when there isn't a lot of tangible impact to their own earnings. It does come with some testing and manpower which can be insufficient for them to really change it.

I'm not saying that they won't do it, but then there will definitely be time lag.

I confess that I'm still confused.

In this case, shouldn't the CoinJoin/Lightning software warn for unconfirmed parent(s)? I wouldn't accept a non-RBF transaction which has an unconfirmed RBF-enabled parent as "settled".

You mean can't be propagated and confirmed?

You mean Transaction B? You haven't mentioned of any Transaction 2.

Isn't compulsory RBF benefiting miners? Why wouldn't they want to change their policy accordingly?

I think that after the change this should be more predictable (but still not 100%). Since a new tx is treated as RBF (maybe if it has bigger fee though?) it should have "the upper hand" when picked by miners.
Of course, since one's mempool is different from other's, the chance for the initial tx get confirmed first, even if the second one has the bigger fee, cannot be reduced to 0.
Isn't it the same now with all the tx that have RBF flag on?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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:

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.

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.

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

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.

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.

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.