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 inputs used in the multi-party funded transaction (MPFT) are all confirmed. While the MPFT is being created, a malicious party can double spends their input to prevent the MPFT from being broadcast. This double spend can include a different input with an RBF-enabled unconfirmed parent, which allows the double spend to be easily invalidated in the future.
Is that correct?
Yes, you've got it now.
The thing I don't understand is why can't the software (of CoinJoin or Lightning) warn the users for RBF-enabled unconfirmed parents. If the users are afraid of being victimized in this way, they only have to avoid dealing with inputs whose parents are RBF-enabled and unconfirmed.
Because, again, the inputs to the MPFT are all confirmed. It is only the malicious double spend which has the unconfirmed parent, which will obviously not be known about at the time of creating the the MPFT.
Here is another post from Riard in the mailing list which explains things in yet another way:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020595.htmlHere the DoS attack situation :
- Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs
- Each of the input is singly controlled by one party, e.g Alice owns input A, Bob owns input B, ...
- Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded transaction (the coinjoin_tx)
- Alice is elected as the multi-party transaction broadcaster once the signatures have been exchanged
- The block feerate is around 10sat/vb
- One of the transaction input signals opt-in RBF, the transaction is attached a compelling feerate 10sat/vb
- Caroll broadcasts a double-spend of her own input C, the double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
- Alice broadcasts the multi-party transaction, it is rejected by the network mempools because Alice Caroll double-spend is already present
- Two alternatives are offered to the coinjoin participants :
Alternative A)
- They estimate the multi-party feerate as not high enough
- They fee-bump at 20sat/vb
- Caroll double-spend one of the input of her malicious double-spend to eject it from the network mempools
- The multi-party transaction is confirmed at a block feerare far above what was necessary
- Alice, Bob, Caroll have loss fee-bumping value without compensation
- Note, even if Caroll is attacker and assuming the fee-bumping burden is fairly spread among participants, the economic loss inflicted is asymmetric
Alternative B)
- They wait until some time-out
- They double-spend their own inputs, Alice double-spend utxo A, Bob double-spend utxo B
- They wasted the timevalue of their inputs for the time-out delay
- Note, even if Caroll is attacker and loss some timevalue too, the economic loss inflicted is asymmetric
Let me know if you see any error or wrong in this DoS scenario exposure. I believe it's fairly simple to execute for a medium-skilled attacker.