Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

I was reminded recently that while Suhas Daftuar cited tx-pinning as a reason to remove full-rbf, he neglected to mention that tx-pinning greatly increases the cost of attacks on multi-party protocols. Him (rhetorically?) asking(4):

    "Does fullrbf offer any benefits other than breaking zeroconf business
     practices?"

...has caused a lot of confusion by implying that there were no benefits. So I'm writing this to set the record straight and provide an easily cited explanation as to why full-rbf - even with tx-pinning - is a valuable improvement for multi-party protocols like coinjoins that rely on transactions containing multiple inputs exclusively controlled(1) by different parties.

tl;dr: without full-rbf people can intentionally and unintentionally DoS attack multi-party protocols by double-spending their inputs with low-fee txs, holding up progress until that low-fee tx gets mined. This could take days, weeks, or even worse. Modulo intentional tx-pinning, full-RBF fixes this by ensuring that a higher fee transaction gets mined in a reasonable amount of time so the protocol makes forward progress. And as for tx-pinning, exploiting it is very expensive, so full-rbf still makes the situation much better than the status quo.

# The Double-Spend DoS Attack on Multi-Party, Multi-Input, Transactions

If a protocol constructs transactions containing multiple inputs exclusively controlled by different parties, those parties can intentionally and unintentionally double-spend those inputs in alternate transactions. For example, in a Wasabi coinjoin any one of the hundreds of participants could sign and broadcast a transaction spending their input. If they do that at the right time, as much as ~100% of the hashing power may see the double-spend first, prior to the intended coinjoin transaction. This in fact does happen regularly in production to Wasabi coinjoins, probably due to people accidentally running different wallets at the same time using the same seed, as well as people importing their seeds into alternative wallets.

By itself this isn't a significant problem: Wasabi coinjoins are a two phase protocol, and, like any multi-step, multi-party protocol, they have to deal with the fact that participants in the protocol may fail to complete all the steps necessary for a transaction to be completed. It's very common for one or more parties in a Wasabi coinjoin to fail to complete both steps of the protocol, and a majority of Wasabi coinjoin rounds fail. Wasabi deals with this economically by (temporarily or ~permanently) blacklisting UTXOs that failed to complete a round, making DoS attacks expensive by forcing the attacker to tie up funds/create new UTXOs.

Similarly, in use-cases such as multi-party-funded Lightning channels(5), an attacker can always DoS attack the protocol by participating in a channel open, and then failing to allow payments to be routed through it. The solution is again to use economics to ensure the attack is sufficiently costly.

However, under the right circumstances double-spends are an unusually powerful DoS attack on multi-party, multi-input, transaction. When mempool demand is high, low fee transactions can take arbitrarily long to get mined. Bitcoin has seen periods of mempool demand where low-fee transactions would take *months* to get mined. Transaction expiry does not solve this problem, as anyone can rebroadcast transactions at any time. In these circumstances without transaction replacement a multi-party transaction such as a Wasabi coinjoin could be held up indefinitely by a low-fee double-spend.

## How Full-RBF Mitigates the Double-Spend DoS Attack

Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very straightforward way: the low fee transaction is replaced by the higher fee transaction, resulting in the latter getting mined in a reasonable amount of time and the protocol making forward progress.

Note that the converse is not a useful attack: if the attacker broadcasts a high-fee double spend, higher than the intended multi-party transaction, the transaction will get mined in a reasonable amount of time, costing the attacker money and the defender nothing beyond wasted time. Multi-party protocols always have the property that attackers can spend money to DoS attack by creating more UTXOs/identities/etc, so this isn't any worse than the status quo!

## Transaction Pinning

So what about transaction pinning? The term actually refers to a few different techniques that can make it difficult/expensive to fee-bump a transaction. We're interested in the techniques relevant to replacements, namely exploitation of:

1. BIP-125 RBF Rule #3: a replacement transaction is required to pay the higher absolute fee (not just fee rate) than the sum of fees paid by all transactions being replaced.

2. BIP-125 RBF Rule #5: the number of transactions replaced at one time must not exceed 100. Note that this rule only exists due to limitations of the existing Bitcoin Core implementation; it has absolute no economic rational and should be removed by either improving the implementation's scalability issues, or rejecting transactions that could make a transaction unreplaceable(2).

Exploiting either rule is expensive. To exploit rule #3 the attacker has to broadcast fee-paying transactions paying a total amount of fees higher than the defender is willing to pay. Since transactions don't expire, in almost all circumstances those transactions will eventually be mined, costing the attacker much more money than they would have spent without full-rbf.

To exploit rule #5, the attacker has to broadcast 100x more fee-paying transactions than they otherwise would have. As with rule #3, those transactions will almost always eventually be mined, costing the attacker significantly more money than they would have spent without full-rbf. And, as mentioned above(2), rule #5 is merely an artifact of the existing implementation which can and should be fixed.

The only avenue for an attacker to avoid transaction pinning costs is amortisation: reusing the extra transactions required for pinning for other attacks/other purposes. But of course, amortisation is *already* a potent cost reduction strategy for attacks on multi-party protocols such as coinjoin, so the existence of transaction pinning doesn't appreciably change the situation. Again, there are mitigations such as requiring participants to post nLockTime'd fee-paying transactions(3), and limiting attacks to parties who are heavily invested in Bitcoin for other reasons is a valuable improvement on the status quo.

# Conclusion

Far from not "offering any benefits other than breaking zeroconf business practices"(4), full-rbf clearly improves Bitcoin for multi-party protocols, among the many other reasons to adopt it.

# Footnotes

1. What do I mean by "exclusively controlled"? Let's compare coinjoin, to an
   ordinary single-payer Lightning channel. In a coinjoin, the goal is to get a
   transaction mined containing multiple inputs from different parties. Each of
   these inputs is individually, exclusively controlled by a single party:
   without the cooperation of any other party that input that be spend. This is
   unlike an ordinary single-payer Lightning channel: while the commitment
   transactions are multi-party transactions, the multisig transaction outputs
   involved are *jointly* controlled by both parties, and thus neither party can
   spend it without the cooperation of the other at some point.

2. [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable
   Invariant, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021175.html

3. [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime,
   https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021176.html

4. https://github.com/bitcoin/bitcoin/pull/26438

5. There are even more exotic proposed Lightning-related protocols where a failure
   of transaction replacement can cause the loss of funds. I'm not covering
   those scenarios because they have such strong requirements - beyond what
   full-rbf offers - that the technical community does not have consensus that
   these proposed protocols are even viable.

On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:

> [The quote:]
>
>     "Does fullrbf offer any benefits other than breaking zeroconf
> business
>      practices?"
>
> ...has caused a lot of confusion by implying that there were no
> benefits. [...]
>
> tl;dr: without full-rbf people can intentionally and unintentionally
> DoS attack
> multi-party protocols by double-spending their inputs with low-fee txs,
> holding
> up progress until that low-fee tx gets mined.

Hi Peter,

I'm confused. Isn't this an easily solvable issue without full-RBF? Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction. Mallory either intentionally or unintentionally creates a conflicting transaction that does not opt-in to RBF.

You seem to be proposing that the other participants force the coinjoin to complete by having the coinjoin transaction replace Mallory's conflicting transaction, which requires a full-RBF world.

But isn't it also possible in a non-full-RBF world for Alice, Bob, and Carol to simply create a new coinjoin transaction which does not include any of Mallory's inputs so it doesn't conflict with Mallory's transaction? That way their second coinjoin transaction can confirm independently of Mallory's transaction.

Likewise, if Alice and Mallory attempt an LN dual funding and Mallory creates a conflict, Alice can just create an alternative dual funding with Bob rather than try to use full-RBF to force Mallory's earlier dual funding to confirm.

> ## Transaction Pinning
>
> Exploiting either rule is expensive.

I think this transaction pinning attack against coinjoins and dual fundings is also solved in a non-full-RBF world by the honest participants just creating a non-conflicting transaction.

That said, if I'm missing something and these attacks do actually apply, then it might be worth putting price figures on the attack in terms most people will understand. The conflicting inputs attack you described in the beginning as being solved by full-RBF costs about $0.05 USD at $17,000/BTC. The transaction pinning attack you imply is unsolved by full-RBF costs about $17.00. If both attacks apply, any protocol which is vulnerable to a $17.00 attack still seems highly vulnerable to me, so it doesn't feel like a stretch to say that full-RBF lacks significant benefits for those protocols.

Thanks,

-Dave

On Mon, Jan 09, 2023 at 09:11:46PM -1000, David A. Harding wrote:

> On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:
> > [The quote:]
> >
> >     "Does fullrbf offer any benefits other than breaking zeroconf
> > business
> >      practices?"
> >
> > ...has caused a lot of confusion by implying that there were no
> > benefits. [...]
> >
> > tl;dr: without full-rbf people can intentionally and unintentionally DoS
> > attack
> > multi-party protocols by double-spending their inputs with low-fee txs,
> > holding
> > up progress until that low-fee tx gets mined.
>
> Hi Peter,
>
> I'm confused.  Isn't this an easily solvable issue without full-RBF?
> Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction.
> Mallory either intentionally or unintentionally creates a conflicting
> transaction that does not opt-in to RBF.
>
> You seem to be proposing that the other participants force the coinjoin
> to complete by having the coinjoin transaction replace Mallory's
> conflicting transaction, which requires a full-RBF world.
>
> But isn't it also possible in a non-full-RBF world for Alice, Bob, and
> Carol to simply create a new coinjoin transaction which does not include
> any of Mallory's inputs so it doesn't conflict with Mallory's
> transaction?  That way their second coinjoin transaction can confirm
> independently of Mallory's transaction.

How do you propose that the participants learn about the double-spend? Without knowing that it happened, they can't respond as you suggested.

> Likewise, if Alice and Mallory attempt an LN dual funding and Mallory
> creates a conflict, Alice can just create an alternative dual funding
> with Bob rather than try to use full-RBF to force Mallory's earlier dual
> funding to confirm.

Same issue.

And of course, in both cases full-rbf makes Mallory have to actually pay full price for the attack. Either because the intended transaction goes through. Or because their double-spending DoS attack had to be much more expensive in the first place.

> > ## Transaction Pinning
> >
> > Exploiting either rule is expensive.
>
> I think this transaction pinning attack against coinjoins and dual
> fundings is also solved in a non-full-RBF world by the honest
> participants just creating a non-conflicting transaction.
>
> That said, if I'm missing something and these attacks do actually apply,
> then it might be worth putting price figures on the attack in terms most
> people will understand.  The conflicting inputs attack you described in
> the beginning as being solved by full-RBF costs about $0.05 USD at
> $17,000/BTC.  The transaction pinning attack you imply is unsolved by
> full-RBF costs about $17.00.  If both attacks apply, any protocol which
> is vulnerable to a $17.00 attack still seems highly vulnerable to me, so
> it doesn't feel like a stretch to say that full-RBF lacks significant
> benefits for those protocols.

Coinjoins are an automated process that happens constantly. As I described in my email, it's totally normal for them to fail constantly - I was told by Wasabi that only ~25% of coinjoin rounds succeed right now, a figure that frankly was much higher than I expected. Being forced to spend $17/round rather than $0.05/round is a huge improvement that adds up to serious money at the scale at which Wasabi and similar protocols operate at.

Hi Peter,

> ## How Full-RBF Mitigates the Double-Spend DoS Attack
>
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> straightforward way: the low fee transaction is replaced by the higher fee
> transaction, resulting in the latter getting mined in a reasonable amount of
> time and the protocol making forward progress.

Asking this question based on a [discussion on twitter][0]. How would you get extra sats to increase the fees? It seems this would be possible with Joinmarket, Wasabi and even joinstr although things would get worse for Whirlpool. Whirlpool coinjoin transactions do not signal BIP 125 RBF so they were not replaceable earlier, however attacker would be able to perform DoS attacks now by double spending their inputs used in coinjoin.

[0]: https://twitter.com/dammkewl/status/1599692908860706818

/dev/fd0 floppy disc guy

Sent with Proton Mail secure email.

------- Original Message ------- On Tuesday, January 10th, 2023 at 3:48 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> I was reminded recently that while Suhas Daftuar cited tx-pinning as a reason
> to remove full-rbf, he neglected to mention that tx-pinning greatly increases
> the cost of attacks on multi-party protocols. Him (rhetorically?) asking(4):
>
> "Does fullrbf offer any benefits other than breaking zeroconf business
> practices?"
>
> ...has caused a lot of confusion by implying that there were no benefits. So
> I'm writing this to set the record straight and provide an easily cited
> explanation as to why full-rbf - even with tx-pinning - is a valuable
> improvement for multi-party protocols like coinjoins that rely on transactions
> containing multiple inputs exclusively controlled(1) by different parties.
>
> tl;dr: without full-rbf people can intentionally and unintentionally DoS attack
> multi-party protocols by double-spending their inputs with low-fee txs, holding
> up progress until that low-fee tx gets mined. This could take days, weeks, or
> even worse. Modulo intentional tx-pinning, full-RBF fixes this by ensuring that
> a higher fee transaction gets mined in a reasonable amount of time so the
> protocol makes forward progress. And as for tx-pinning, exploiting it is very
> expensive, so full-rbf still makes the situation much better than the status
> quo.
>
>
> # The Double-Spend DoS Attack on Multi-Party, Multi-Input, Transactions
>
> If a protocol constructs transactions containing multiple inputs exclusively
> controlled by different parties, those parties can intentionally and
> unintentionally double-spend those inputs in alternate transactions. For
> example, in a Wasabi coinjoin any one of the hundreds of participants could
> sign and broadcast a transaction spending their input. If they do that at the
> right time, as much as ~100% of the hashing power may see the double-spend
> first, prior to the intended coinjoin transaction. This in fact does happen
> regularly in production to Wasabi coinjoins, probably due to people
> accidentally running different wallets at the same time using the same seed, as
> well as people importing their seeds into alternative wallets.
>
> By itself this isn't a significant problem: Wasabi coinjoins are a two phase
> protocol, and, like any multi-step, multi-party protocol, they have to deal
> with the fact that participants in the protocol may fail to complete all the
> steps necessary for a transaction to be completed. It's very common for one or
> more parties in a Wasabi coinjoin to fail to complete both steps of the
> protocol, and a majority of Wasabi coinjoin rounds fail. Wasabi deals with this
> economically by (temporarily or ~permanently) blacklisting UTXOs that failed to
> complete a round, making DoS attacks expensive by forcing the attacker to tie
> up funds/create new UTXOs.
>
> Similarly, in use-cases such as multi-party-funded Lightning channels(5), an
> attacker can always DoS attack the protocol by participating in a channel open,
> and then failing to allow payments to be routed through it. The solution is
> again to use economics to ensure the attack is sufficiently costly.
>
> However, under the right circumstances double-spends are an unusually powerful
> DoS attack on multi-party, multi-input, transaction. When mempool demand is
> high, low fee transactions can take arbitrarily long to get mined. Bitcoin has
> seen periods of mempool demand where low-fee transactions would take months
> to get mined. Transaction expiry does not solve this problem, as anyone can
> rebroadcast transactions at any time. In these circumstances without
> transaction replacement a multi-party transaction such as a Wasabi coinjoin
> could be held up indefinitely by a low-fee double-spend.
>
>
> ## How Full-RBF Mitigates the Double-Spend DoS Attack
>
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> straightforward way: the low fee transaction is replaced by the higher fee
> transaction, resulting in the latter getting mined in a reasonable amount of
> time and the protocol making forward progress.
>
> Note that the converse is not a useful attack: if the attacker broadcasts a
> high-fee double spend, higher than the intended multi-party transaction, the
> transaction will get mined in a reasonable amount of time, costing the attacker
> money and the defender nothing beyond wasted time. Multi-party protocols always
> have the property that attackers can spend money to DoS attack by creating more
> UTXOs/identities/etc, so this isn't any worse than the status quo!
>
>
> ## Transaction Pinning
>
> So what about transaction pinning? The term actually refers to a few different
> techniques that can make it difficult/expensive to fee-bump a transaction.
> We're interested in the techniques relevant to replacements, namely
> exploitation of:
>
> 1. BIP-125 RBF Rule #3: a replacement transaction is required to pay
> the higher absolute fee (not just fee rate) than the sum of fees paid by all
> transactions being replaced.
>
> 2. BIP-125 RBF Rule #5: the number of transactions replaced at one time must
> not exceed 100. Note that this rule only exists due to limitations of the
> existing Bitcoin Core implementation; it has absolute no economic rational and
> should be removed by either improving the implementation's scalability issues,
> or rejecting transactions that could make a transaction unreplaceable(2).
>
> Exploiting either rule is expensive. To exploit rule #3 the attacker has to
> broadcast fee-paying transactions paying a total amount of fees higher than the
> defender is willing to pay. Since transactions don't expire, in almost all
> circumstances those transactions will eventually be mined, costing the attacker
> much more money than they would have spent without full-rbf.
>
> To exploit rule #5, the attacker has to broadcast 100x more fee-paying
> transactions than they otherwise would have. As with rule #3, those
> transactions will almost always eventually be mined, costing the attacker
> significantly more money than they would have spent without full-rbf. And, as
> mentioned above(2), rule #5 is merely an artifact of the existing
> implementation which can and should be fixed.
>
> The only avenue for an attacker to avoid transaction pinning costs is
> amortisation: reusing the extra transactions required for pinning for other
> attacks/other purposes. But of course, amortisation is already a potent cost
> reduction strategy for attacks on multi-party protocols such as coinjoin, so
> the existence of transaction pinning doesn't appreciably change the situation.
> Again, there are mitigations such as requiring participants to post nLockTime'd
> fee-paying transactions(3), and limiting attacks to parties who are heavily
> invested in Bitcoin for other reasons is a valuable improvement on the status
> quo.
>
>
> # Conclusion
>
> Far from not "offering any benefits other than breaking zeroconf business
> practices"(4), full-rbf clearly improves Bitcoin for multi-party protocols,
> among the many other reasons to adopt it.
>
>
> # Footnotes
>
> 1. What do I mean by "exclusively controlled"? Let's compare coinjoin, to an
> ordinary single-payer Lightning channel. In a coinjoin, the goal is to get a
> transaction mined containing multiple inputs from different parties. Each of
> these inputs is individually, exclusively controlled by a single party:
> without the cooperation of any other party that input that be spend. This is
> unlike an ordinary single-payer Lightning channel: while the commitment
> transactions are multi-party transactions, the multisig transaction outputs
> involved are jointly controlled by both parties, and thus neither party can
> spend it without the cooperation of the other at some point.
>
> 2. [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable
> Invariant, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021175.html
>
> 3. [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021176.html
>
> 4. https://github.com/bitcoin/bitcoin/pull/26438
>
> 5. There are even more exotic proposed Lightning-related protocols where a failure
> of transaction replacement can cause the loss of funds. I'm not covering
> those scenarios because they have such strong requirements - beyond what
> full-rbf offers - that the technical community does not have consensus that
> these proposed protocols are even viable.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

On 2023-01-09 22:47, Peter Todd wrote:

> How do you propose that the participants learn about the double-spend?
> Without
> knowing that it happened, they can't respond as you suggested.

I can think of various ways---many of them probably the same ideas that would occur to you. More concise than listing them is to just assume they exist and realize that any protocol software which wants to defeat the $17.00 pinning attack needs to implement some sort of conflict monitoring system---but by using that monitoring system to defeat the $17.00 pinning attack, the software also defeats the $0.05 individual conflicting input attack without any need for full-RBF.

Full-RBF provides no benefits here except those which are already provided by other necessary tools.

Thanks,

-Dave

On Tue, Jan 10, 2023 at 09:19:39AM +0000, alicexbt wrote:

> Hi Peter,
>
> > ## How Full-RBF Mitigates the Double-Spend DoS Attack
> >
> > Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> > straightforward way: the low fee transaction is replaced by the higher fee
> > transaction, resulting in the latter getting mined in a reasonable amount of
> > time and the protocol making forward progress.
>
> Asking this question based on a [discussion on twitter][0]. How would you get extra sats to increase the fees?

You're misunderstanding the issue. There is no need for extra sats to increase fees. Coinjoin transactions already have fees set at a level at which you'd expect them to be mined in a reasonable amount of time. Full-RBF ensures that, modulo tx pinning, either the coinjoin gets mined, or any double-spend has to have a high enough feerate that it will be mined in a reasonable amount of time as well.

> It seems this would be possible with Joinmarket, Wasabi and even joinstr although things would get worse for Whirlpool. Whirlpool coinjoin transactions do not signal BIP 125 RBF so they were not replaceable earlier

Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at best, some rather insane technical decisions. Quite likely downright malicious with their xpub collection. Their opinion isn't relevant. Cite reputable sources.

Anyway, Wasabi would like to move to making coinjoins opt-in to RBF. Though full-rbf may come sooner; for technical reasons opt-in RBF is ugly to implement now as activation needs to be coordinated accross all clients:

https://github.com/zkSNACKs/WalletWasabi/issues/9041#issuecomment-1376653020

> however attacker would be able to perform DoS attacks now by double spending their inputs used in coinjoin.

As I explained, attackers can already do this with or without full-rbf simply by picking the right time to broadcast the double spend. It's not an effective attack anyway: with a UTXO you can already hold up a coinjoin round by simply failing to complete stage #2 of the coinjoin. Actually doing a double-spend simply guarantees that you're spending money on it. It's only effective with low-fee double-spends in the absence of full-rbf.

> [0]: https://twitter.com/dammkewl/status/1599692908860706818

This tweet is nuts. Eg "Gives well connected mining pools an added advantage" is simply false. Full-RBF does the exact opposite.

On Tue, Jan 10, 2023 at 12:02:35AM -1000, David A. Harding wrote:

> On 2023-01-09 22:47, Peter Todd wrote:
> > How do you propose that the participants learn about the double-spend?
> > Without
> > knowing that it happened, they can't respond as you suggested.
>
> I can think of various ways---many of them probably the same ideas that
> would occur to you.

Rather than playing games, how about you actually list those ways.

> More concise than listing them is to just assume
> they exist and realize that any protocol software which wants to defeat
> the $17.00 pinning attack needs to implement some sort of conflict
> monitoring system---but by using that monitoring system to defeat the
> $17.00 pinning attack, the software also defeats the $0.05 individual
> conflicting input attack without any need for full-RBF.

Remember, we'd like decentralized coinjoin implementations like Joinmarket to work. How does a decentralized coinjoin implement "conflict monitoring"?

Hi Peter,

> Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at best,
> some rather insane technical decisions. Quite likely downright malicious with
> their xpub collection. Their opinion isn't relevant. Cite reputable sources.

I didn't want this thread to become a wasabi vs samourai debate instead wanted to focus on full-rbf and how it affects different coinjoin implementations. Samourai wallet can be used with [dojo][0] that includes full node and Whirlpool can be used in [sparrow Wallet][1] as well. There are several reasons to not use wasabi and consider their opinion irrelevant. Wasabi has many privacy issues including address reuse and consolidation in a coinjoin tx. They completely lost their reputation after deciding to work with chain analysis firms that help governments for censorship of some UTXOs.

Even _nothingmuch_ who has contributed to Wasabi's coinjoin implementation has [no major issues][2] with whirlpool if used properly. Some [tweets][3] in this thread even show their incompetence and major issues with wabisabi.

Anyway thanks for responding to other things I mentioned in last email.

[0]: https://code.samourai.io/dojo/samourai-dojo [1]: https://sparrowwallet.com/docs/mixing-whirlpool.html [2]: https://twitter.com/search?lang=en&q=whirlpool%20(from%3AmHaGqnOACyFm0h5)&src=typed_query [3]: https://twitter.com/mHaGqnOACyFm0h5/status/1538748210210013184

/dev/fd0 floppy disc guy

Sent with Proton Mail secure email.

------- Original Message ------- On Tuesday, January 10th, 2023 at 3:33 PM, Peter Todd <pete@petertodd•org> wrote:

> On Tue, Jan 10, 2023 at 09:19:39AM +0000, alicexbt wrote:
>
> > Hi Peter,
> >
> > > ## How Full-RBF Mitigates the Double-Spend DoS Attack
> > >
> > > Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> > > straightforward way: the low fee transaction is replaced by the higher fee
> > > transaction, resulting in the latter getting mined in a reasonable amount of
> > > time and the protocol making forward progress.
> >
> > Asking this question based on a discussion on twitter. How would you get extra sats to increase the fees?
>
>
> You're misunderstanding the issue. There is no need for extra sats to increase
> fees. Coinjoin transactions already have fees set at a level at which you'd
> expect them to be mined in a reasonable amount of time. Full-RBF ensures that,
> modulo tx pinning, either the coinjoin gets mined, or any double-spend has to
> have a high enough feerate that it will be mined in a reasonable amount of time
> as well.
>
> > It seems this would be possible with Joinmarket, Wasabi and even joinstr although things would get worse for Whirlpool. Whirlpool coinjoin transactions do not signal BIP 125 RBF so they were not replaceable earlier
>
>
> Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at best,
> some rather insane technical decisions. Quite likely downright malicious with
> their xpub collection. Their opinion isn't relevant. Cite reputable sources.
>
> Anyway, Wasabi would like to move to making coinjoins opt-in to RBF. Though
> full-rbf may come sooner; for technical reasons opt-in RBF is ugly to implement
> now as activation needs to be coordinated accross all clients:
>
> https://github.com/zkSNACKs/WalletWasabi/issues/9041#issuecomment-1376653020
>
> > however attacker would be able to perform DoS attacks now by double spending their inputs used in coinjoin.
>
>
> As I explained, attackers can already do this with or without full-rbf simply
> by picking the right time to broadcast the double spend. It's not an effective
> attack anyway: with a UTXO you can already hold up a coinjoin round by simply
> failing to complete stage #2 of the coinjoin. Actually doing a double-spend
> simply guarantees that you're spending money on it. It's only effective with
> low-fee double-spends in the absence of full-rbf.
>
>
> This tweet is nuts. Eg "Gives well connected mining pools an added advantage"
> is simply false. Full-RBF does the exact opposite.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

On 2023-01-10 00:06, Peter Todd wrote:

> Remember, we'd like decentralized coinjoin implementations like
> Joinmarket to
> work. How does a decentralized coinjoin implement "conflict
> monitoring"?

1. Run a relay node with a conflict-detection patch.  Stock Bitcoin Core
    with -debug=mempoolrej will tell you when it rejects a transaction
    for conflicting with a transaction already in the mempool, e.g.:

       2022-11-01T02:53:17Z
867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from
peer=58 was not accepted: txn-mempool-conflict

    I think it would be easy to extend this facility to list the inputs
    which conflicted.  So if Alice sees a conflict created by Mallory,
    she can create a new coinjoin transaction without Mallory.  This
    method has the advantage of being fast and attributing fault,
    although it does require Alice's node be online at the time Mallory's
    conflict is propagated.

2. Simply assume a conflict exists for otherwise unexplainable failures.
    For example, if Alice sees several new blocks whose bottom feerates
    are well below the feerates of an unconfirmed coinjoin transaction
    that Alice helped create and broadcast, she can assume it's a
    conflict that is preventing preventing confirmation of the coinjoin.
    She can find an entirely different set of collaborators and create a
    non-conflicting transaction without ever needing to know which inputs
    from the original transaction conflicted.  This method has the
    disadvantage of being slow (on the order of hours) and not
attributing
    fault, although it doesn't require Alice has any information beyond
copies
    of recent blocks.

I didn't list these methods or others before because the specific method used to detect conflicts doesn't matter to the realization that software which uses conflict detection and evasion to defeat the $17.00 attack also defeats the $0.05 attack without any need for full-RBF.

-Dave

On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote:

> On 2023-01-10 00:06, Peter Todd wrote:
> > Remember, we'd like decentralized coinjoin implementations like
> > Joinmarket to
> > work. How does a decentralized coinjoin implement "conflict monitoring"?
>
> 1. Run a relay node with a conflict-detection patch.  Stock Bitcoin Core
>    with -debug=mempoolrej will tell you when it rejects a transaction
>    for conflicting with a transaction already in the mempool, e.g.:
>
>       2022-11-01T02:53:17Z
> 867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from
> peer=58 was not accepted: txn-mempool-conflict
>
>    I think it would be easy to extend this facility to list the inputs
>    which conflicted.  So if Alice sees a conflict created by Mallory,
>    she can create a new coinjoin transaction without Mallory.  This
>    method has the advantage of being fast and attributing fault,
>    although it does require Alice's node be online at the time Mallory's
>    conflict is propagated.

So for something as simple as reliable coinjoining - an important privacy feature that we'd like all wallets to use - you expect people to run well-connected 24/7 nodes running specialty software?

Even if you run a node as you suggest, there's certainly no guarantee that you'd learn about any double-spend without doing a severe sybil attack against the network; the 8 outgoing nodes a typical node has samples a tiny fraction of the network. And *even if* you sybil attack to try to detect conflicts there's still no guarantee as attackers can use all kinds of special techniques to get transactions into miner mempools and not others.

> 2. Simply assume a conflict exists for otherwise unexplainable failures.
>    For example, if Alice sees several new blocks whose bottom feerates
>    are well below the feerates of an unconfirmed coinjoin transaction
>    that Alice helped create and broadcast, she can assume it's a
>    conflict that is preventing preventing confirmation of the coinjoin.
>    She can find an entirely different set of collaborators and create a
>    non-conflicting transaction without ever needing to know which inputs
>    from the original transaction conflicted.  This method has the
>    disadvantage of being slow (on the order of hours) and not attributing
>    fault, although it doesn't require Alice has any information beyond
> copies
>    of recent blocks.

You're suggesting that to avoid enabling full-rbf, coinjoin's and other decentralized multi-party protocols risk getting coins tied up for hours trying to do conflict resolution rather than just fixing the underlying problem with what's literally a one-line code change that 17% of the v24.x nodes have decided to enable.

> I didn't list these methods or others before because the specific method
> used to
> detect conflicts doesn't matter to the realization that software which
> uses conflict detection and evasion to defeat the $17.00 attack also
> defeats the $0.05 attack without any need for full-RBF.

Fact is, full-rbf defeats those attacks much better. And I'm amazed that you don't consider raising the cost of attacks on coinjoins and similar decentralized protocols by almost three orders of magnitude to be important: why are you prioritizing a few highly centralized, often AML/KYC'd, unconfirmed tx acceptance services over decentralized protocols which provide privacy and security to a lot more users?

On Tue, Jan 10, 2023 at 05:10:37PM +0000, alicexbt via bitcoin-dev wrote:

> Hi Peter,
>
> > Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at best,
> > some rather insane technical decisions. Quite likely downright malicious with
> > their xpub collection. Their opinion isn't relevant. Cite reputable sources.
>
> I didn't want this thread to become a wasabi vs samourai debate instead wanted to focus on full-rbf and how it affects different coinjoin implementations. Samourai wallet can be used with [dojo][0] that includes full node and Whirlpool can be used in [sparrow Wallet][1] as well. There are several reasons to not use wasabi and consider their opinion irrelevant. Wasabi has many privacy issues including address reuse and consolidation in a coinjoin tx.

Lol, the "address reuse" thing I actually mentioned in my email. Avoiding address reuse from user errors like loading the same seed into different wallets isn't realistic, and it has no real impact on other users.

No reasonable person things Samourai's default option of uploading xpubs is sane. The debate here is over and arguing otherwise is just wasting everyone's time on this mailing list.

> They completely lost their reputation after deciding to work with chain analysis firms that help governments for censorship of some UTXOs.

Citation on them working with chain analysis firms? Or did they just roll their own blacklist?

Anyway, the blacklisting is just a bit of cowardness. That's not a big deal. Lots of Bitcoin entitites have done the cowardly thing and implemented blacklists on the suggestion of their lawyers. We're probably better off if we don't set the bar so high that while you're risking jail time implementing coinjoin, we demand you to take even more risks by not implementing some mostly symbolic blacklists that affect hardly anyone.