Post
Topic
Board Development & Technical Discussion
Merits 5 from 2 users
Re: Full RBF
by
hosseinimr93
on 24/06/2022, 16:28:03 UTC
⭐ Merited by o_e_l_e_o (4) ,JayJuanGee (1)
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 using UTXO A and is non-RBF. UTXO A hasn't 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, I 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 be 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 an attacker can succeed.


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.
From my understanding, this is not the case here.