Topic: Full RBF - page 6. (Read 2271 times)

Let me sum things up.

We have transaction_1. It is non-RBF, it uses UTXO A as an input (along with others) and it's a CoinJoin transaction.
We have transaction_2. It is non-RBF, it has two inputs; UTXO A and UTXO B.
We have transaction_0. It has RBF enabled, it creates UTXO B, it's currently unconfirmed. We call this the parent of transaction_2.

We send transaction_1 in node_1 and transaction_2 in node_2 at the same time.
The network is split to those who have transaction_1 and to those who have transaction_2 in their mempools.

One of the CoinJoin makers wants to speed up the confirmation (of transaction_1) and does CPFP.
The attacker sees that CoinJoin is overspent in fees and reverses transaction_0.
Now that transaction_0 is invalidated (because it's opted-in to RBF and is double-spent), transaction_2 is also invalidated, because it's its child.

Now (all) nodes have transaction_1 in their mempool, but it's overspent in fees.

---

Is that correct?

The coinjoin transaction is using UTXO A and is non-RBF. UTXO A doesn't have any unconfirmed parent and there is no problem here.
There's another transaction made using UTXO A. In this transaction, there's another input which is UTXO B. This transaction is also non-RBF.

The two above transactions have been made at the same time. So, some nodes (including the other party of the coinjoin transaction) see the coinjoin transaction first and some nodes see the other one first.

The transaction that has created UTXO B is still unconfirmed. This transaction has been flagged as RBF. As this transaction is RBF-enabled, the sender can easily double-spend that.
With doing this, the transaction spending UTXO A and UTXO B is invalidated and now the coinjoin transaction is the only transaction that uses UTXO A. Now, the coinjoin transaction can be propagated and confirmed without any problem.

Note that the attacker isn't trying to invalidate the coinjoin transaction at all.
The attacker is only trying to force the other party to pay more fee for the coinjoin transaction. (The other party doesn't know what's causing the issue and think that the problem is with the low fee.)

Again, this is what I understood from o_e_l_e_o's post and I think it's very very unlikely that the attacker can succeed.


From my understanding, this is not the case here.

If each of the inputs that are used in the RBF-disabled CoinJoin don't have an RBF-enabled unconfirmed parent, then what's the problem?

The CoinJoin transaction is consisted of some parties' inputs. One of those inputs might be an RBF-enabled unconfirmed parent, which can be abused by an attacker to disrupt mixing. Can't you give a solution to this if you make CoinJoin unavailable for RBF-enabled unconfirmed inputs?

I must have messed things up.

The UTXO used in the coinjoin transaction doesn't have any unconfirmed parent at all.
That UTXO was combined with another UTXO in a different transaction at the same time as the coinjoin transaction. This is the transaction which was invalided with doubling-spending its parent.
As both transactions have been made at the same time, it's possible that the client see the coinjoin transaction before the other one and doesn't understand what's causing the issue.
This is my understanding from o_e_l_e_o's post and I really don't know how likely this is.

Me too.


No.

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?