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

It is about joining and splitting one-input-one-output entries, where all participants can do that, but if things will finalize, then they will look like any ordinary SIGHASH_ALL transaction.

Can't we implement some sort of OP_IF, OP_ELSE penalty mechanism for this matter? It'd increase the transaction fee, though.

Creates a fine mess on the network, defeating essentially the purpose of non-RBF; especially due to the former.

[...]

But it is neither a rule nor being enforced.

I don't really see how this is a problem: if a part of the "joined" transaction becomes invalid, I assume the coinjoin can just recreate a new transaction without that input and broadcast it again, right?

While I do acknowledge the problem here, I don't like that a possible attack on CoinJoin or Lightning transactions can be resolved only by enforcing a rule on all the transactions.

Point of sale unconfirmed transactions become less attractive for the merchants, pushing them to adopting off-chain solutions. The question is if, say, Lightning is ready to be adopted by every merchant.

Trying to see if BitPay will make allowances for this then finally but don't see anything to suggest it on their site -- In fact, the latest RBF threads updated in June on their FAQs still show you how to disable them.

By making it far more costly an attack to perform, and by giving the coinjoin transaction the ability to overcome the blockage.

I don't see how you could. By the time you come to punishing Carol for it, she has already achieved what she wanted to achieve - wasting the time and/or money of the other participants.

Here is an example of this attack happening on a Wasabi coinjoin (on testnet)
~
the same input which was used in the attempted coinjoin transaction

So, how does mandatory RBF help the situation?

Can't we implement some sort of OP_IF, OP_ELSE penalty mechanism for this matter? It'd increase the transaction fee, though.

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.

In Wasabi an attacker can broadcast a transaction spending input used in coinjoin after sending signature in the round. This would result in a coinjoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920

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?

Is that correct?

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.

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

For being successful, it's needed that majority of nodes see transaction_2 first and the honest party (the one who does CPFP) sees transaction_1 first.

Is that correct?

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.

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.

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?