Full RBF

[NeuroticFish]

~ I'll have no idea which one will actually get mined until one of them is mined?

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

[1715228971]

1715228971

[1715228971]

1715228971

[BlackHatCoiner]

I confess that I'm still confused.

The non-RBF transaction is invalidated with double-spending its unconfirmed parent (which is RBF-enabled).

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

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.

You mean can't be propagated and confirmed?

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.

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

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.

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

[ranochigo]

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

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.

[hosseinimr93]

In this case, shouldn't the CoinJoin/Lightning software warn for unconfirmed parent(s)?

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.

I wouldn't accept a non-RBF transaction which has an unconfirmed RBF-enabled parent as "settled".

Me too.

You mean can't be propagated and confirmed?

No.

[BlackHatCoiner]

The UTXO used in the coinjoin transaction doesn't have any unconfirmed parent at all.

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?

That UTXO was combined with another UTXO in a different transaction at the same time as the coinjoin transaction.

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.

[hosseinimr93]

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

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.

[BlackHatCoiner]

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?

[hosseinimr93]

Is that correct?

Yes.
The thing I don't understand is how the attacker can manage to do this and that's why I said it's very very unlikely.
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.

[BlackHatCoiner]

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.

I'm not convinced that this change will have a good impact, unless there's another danger I haven't thought of (or understood). Sure, nodes could replace non-RBF transactions since 2009 if their owners changed the source code, but it feels like we're now moving into something else.

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.

I guess the attacker knows the victim's node URI?

[o_e_l_e_o]

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

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.

[o_e_l_e_o]

Here is an example of this attack happening on a Wasabi coinjoin (on testnet) which developer /dev/fd0 just shared with the mailing list and on their Twitter:

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

You can see the double spend transaction here: https://mempool.space/testnet/tx/a57e46e8a69752802ca83caa37b32bebcaa2965b5572fa805f2b48f1846fd3df
The third input in this transaction for 0.00006561 tBTC was the same input which was used in the attempted coinjoin transaction as you can see from the screenshots.

The Wasabi client reported the invalid coinjoin as "broadcast".

[BlackHatCoiner]

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.

I see the problem. The CoinJoin makers have to either bump their fees with CPFP or have their CoinJoin rejected. So, how does mandatory RBF help the situation? The attacker wants to make us spend more in fees or delay our mixing.

• Suppose we have Alice, Bob and Carol, with their respective inputs A, B and C.
• Carol is the attacker.
• Alice, Bob and Carol sign the CoinJoin transaction, and it's ready to be broadcasted.
• Carol has signed a transaction wherein she replaced CoinJoin with her reversal.
• Both are broadcasted, but Carol's transaction replaces the CoinJoin.
• Alice and Bob can either raise their fees or let Carol's replacement transaction become confirmed and create another CoinJoin later.

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

[o_e_l_e_o]

So, how does mandatory RBF help the situation?

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

At present, Carol can attack by broadcasting a non-RBF transaction at 1 sat/vbyte. It doesn't matter what fee the coinjoin pays; the malicious double spend will not be replaced. With full RBF, Carol must be willing to pay a much higher fee. If she only says 1 sat/vbyte, then the coinjoin can be bumped to an equivalent of 1.1 sats/vbyte and displace her malicious double spend. Further, at present, Carol can leave her 1 sat/vbyte transaction in the mempool as long as she wants, and let the coinjoin operator repeatedly attempt to bump the coinjoin with a higher and higher fee, with effectively no limit (other than the limit of what the participants would find acceptable). With full RBF, the coinjoin operator only ever needs to bump the fee as high as the fee on Carol's double spend (+ 0.1 sats/vbyte).

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

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.

[LoyceV]

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

Isn't that risk inherent of "joining" your transaction with someone else's? 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?

[BlackHatCoiner]

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

Right.

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.

She won't dare to cheat if a fairness protocol she uses disincentivizes her do so. I can neither think of a script that does it, I was just saying. Even if there is, that I doubt, it'll increase the size of all CoinJoin and Lightning transactions, making things more costly to operate.

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. I was thinking of a rather slower and smoother transition.

[buwaytress]

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.

They've been forcing people to overpay on fees (and rejecting RBF-enabled ones so you're forced to finalise a fee), one of the few things I put up with for the sake of spending that Bitcoin on pizza where I live. Or is that merely merchant settings on their end of BitPay?

I see this as a win, maybe one reason it's happening? To push merchants to accept a tool designed to help users compensate for miscalculations?

[o_e_l_e_o]

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?

Maybe. Or maybe a malicious attacker (maybe some other coinjoin wallet who wants to attack their competitors) is flooding your coinjoin service with inputs that they are double spending, so it happens again on your next attempt, and your next one, and your next one, rendering it impossible for you to coinjoin any coins at all. The same could apply to any custodial Lightning wallet, as another example.

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.

But it is neither a rule nor being enforced. This is a change with the Bitcoin Core software, not the Bitcoin protocol, giving node operators the easy option to accept replacements for all transactions in their mempool. Node operators can already do this if they wish, and some alternative full node software (such as Knots) have had this option for years already.

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.

This is my main concern too.

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.

Given how long it took BitPay to get on board with things like segwit, then there is exactly zero chance they are going to react to upcoming changes before they have even been finalized yet, let alone released.

[BlackHatCoiner]

[...]

Any merchant who's using BitPay should switch to BTCPay Server the soonest possible. It doesn't make sense to use an intermediary for this purpose when the currency's software already exists for eliminating this kind of third parties.

I have never used BitPay, but I'd read somewhere that they even demanded KYC for a purchase. Unbelievable or just reasonable and probable considering today's sniffing standards?

But it is neither a rule nor being enforced.

It isn't enforced, but having it as an option officially on Bitcoin Core rather than as a potential change that requires altering the source code:

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

[o_e_l_e_o]

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

This will indeed be the beginning of the end for non-RBF transactions, as I suspect before long most miners will choose to look at mempools which have enabled full RBF to allow them to maximize their profits from fees. I guess zero confirmations transactions will be a thing of the past unless the two parties involved completely trust each other.

Here are the final commits to be merged in to the main branch: https://github.com/bitcoin/bitcoin/pull/25353/commits

If all goes to plan then this will be live in the next version of Core, 24.0.

[garlonicon]

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

We can, and it currently exists. It is called SIGHASH. So, by signing your CoinJoin with SIGHASH_ANYONECANPAY, you sign only your input, and all outputs. That means, Alice and Bob can detach Carol if needed, and attach some other source of coins, but then the destination has to remain the same (which means Carol will be paid, so that's not the solution). Because if you have CoinJoin, you have to sign all outputs, if you sign only some of them, then you have no privacy boost, because it is possible to link your coins.

So, to solve the problem of CoinJoin, there is a need to construct transactions in a non-interactive way (and to provide that, transaction joining (and splitting) needs to be implemented). A good start is SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, each participant could sign a single input and a single output in this way. What is needed, is taking N such entries, and make signatures in a way, where they could be turned into SIGHASH_ALL, to be indistinguishable from any normal transaction. 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.