Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive

From: alicexbt <alicexbt@protonmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty Protocols Significantly More Expensive
Date: Tue, 10 Jan 2023 09:19:39 +0000	[thread overview]
Message-ID: <OwgJwjPrZWRtBaIDDZ8g-xbFPlryUXUopqUuKYVUNE-mVHzCWHFXl77YzDlItEjHTHcGjpzIC5alGsnFEsOtSgHLm9We92gcWrLTahzPGFk=@protonmail.com> (raw)
In-Reply-To: <Y7ySzDjzx5eDjOH9@petertodd.org>

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