Date: Tue, 10 Jan 2023 09:19:39 +0000
To: Peter Todd <pete@petertodd.org>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <OwgJwjPrZWRtBaIDDZ8g-xbFPlryUXUopqUuKYVUNE-mVHzCWHFXl77YzDlItEjHTHcGjpzIC5alGsnFEsOtSgHLm9We92gcWrLTahzPGFk=@protonmail.com>
In-Reply-To: <Y7ySzDjzx5eDjOH9@petertodd.org>
References: <Y7ySzDjzx5eDjOH9@petertodd.org>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty
	Protocols Significantly More Expensive
Precedence: list

Hi Peter,

> ## How Full-RBF Mitigates the Double-Spend DoS Attack
>=20
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a ve=
ry
> straightforward way: the low fee transaction is replaced by the higher fe=
e
> 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 g=
et extra sats to increase the fees? It seems this would be possible with Jo=
inmarket, Wasabi and even joinstr although things would get worse for Whirl=
pool. Whirlpool coinjoin transactions do not signal BIP 125 RBF so they wer=
e not replaceable earlier, however attacker would be able to perform DoS at=
tacks 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 <bitc=
oin-dev@lists.linuxfoundation.org> wrote:


> I was reminded recently that while Suhas Daftuar cited tx-pinning as a re=
ason
> to remove full-rbf, he neglected to mention that tx-pinning greatly incre=
ases
> the cost of attacks on multi-party protocols. Him (rhetorically?) asking(=
4):
>=20
> "Does fullrbf offer any benefits other than breaking zeroconf business
> practices?"
>=20
> ...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 transac=
tions
> containing multiple inputs exclusively controlled(1) by different parties=
.
>=20
> tl;dr: without full-rbf people can intentionally and unintentionally DoS =
attack
> multi-party protocols by double-spending their inputs with low-fee txs, h=
olding
> 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 ensurin=
g 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 sta=
tus
> quo.
>=20
>=20
> # The Double-Spend DoS Attack on Multi-Party, Multi-Input, Transactions
>=20
> If a protocol constructs transactions containing multiple inputs exclusiv=
ely
> 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 cou=
ld
> 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-spen=
d
> first, prior to the intended coinjoin transaction. This in fact does happ=
en
> regularly in production to Wasabi coinjoins, probably due to people
> accidentally running different wallets at the same time using the same se=
ed, as
> well as people importing their seeds into alternative wallets.
>=20
> By itself this isn't a significant problem: Wasabi coinjoins are a two ph=
ase
> protocol, and, like any multi-step, multi-party protocol, they have to de=
al
> 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 o=
ne 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 wit=
h this
> economically by (temporarily or ~permanently) blacklisting UTXOs that fai=
led to
> complete a round, making DoS attacks expensive by forcing the attacker to=
 tie
> up funds/create new UTXOs.
>=20
> 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.
>=20
> However, under the right circumstances double-spends are an unusually pow=
erful
> DoS attack on multi-party, multi-input, transaction. When mempool demand =
is
> high, low fee transactions can take arbitrarily long to get mined. Bitcoi=
n has
> seen periods of mempool demand where low-fee transactions would take mont=
hs
> to get mined. Transaction expiry does not solve this problem, as anyone c=
an
> rebroadcast transactions at any time. In these circumstances without
> transaction replacement a multi-party transaction such as a Wasabi coinjo=
in
> could be held up indefinitely by a low-fee double-spend.
>=20
>=20
> ## How Full-RBF Mitigates the Double-Spend DoS Attack
>=20
> Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a ve=
ry
> straightforward way: the low fee transaction is replaced by the higher fe=
e
> transaction, resulting in the latter getting mined in a reasonable amount=
 of
> time and the protocol making forward progress.
>=20
> 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 at=
tacker
> money and the defender nothing beyond wasted time. Multi-party protocols =
always
> have the property that attackers can spend money to DoS attack by creatin=
g more
> UTXOs/identities/etc, so this isn't any worse than the status quo!
>=20
>=20
> ## Transaction Pinning
>=20
> So what about transaction pinning? The term actually refers to a few diff=
erent
> techniques that can make it difficult/expensive to fee-bump a transaction=
.
> We're interested in the techniques relevant to replacements, namely
> exploitation of:
>=20
> 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.
>=20
> 2. BIP-125 RBF Rule #5: the number of transactions replaced at one time m=
ust
> not exceed 100. Note that this rule only exists due to limitations of the
> existing Bitcoin Core implementation; it has absolute no economic rationa=
l and
> should be removed by either improving the implementation's scalability is=
sues,
> or rejecting transactions that could make a transaction unreplaceable(2).
>=20
> Exploiting either rule is expensive. To exploit rule #3 the attacker has =
to
> broadcast fee-paying transactions paying a total amount of fees higher th=
an the
> defender is willing to pay. Since transactions don't expire, in almost al=
l
> circumstances those transactions will eventually be mined, costing the at=
tacker
> much more money than they would have spent without full-rbf.
>=20
> 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.
>=20
> The only avenue for an attacker to avoid transaction pinning costs is
> amortisation: reusing the extra transactions required for pinning for oth=
er
> attacks/other purposes. But of course, amortisation is already a potent c=
ost
> reduction strategy for attacks on multi-party protocols such as coinjoin,=
 so
> the existence of transaction pinning doesn't appreciably change the situa=
tion.
> Again, there are mitigations such as requiring participants to post nLock=
Time'd
> fee-paying transactions(3), and limiting attacks to parties who are heavi=
ly
> invested in Bitcoin for other reasons is a valuable improvement on the st=
atus
> quo.
>=20
>=20
> # Conclusion
>=20
> Far from not "offering any benefits other than breaking zeroconf business
> practices"(4), full-rbf clearly improves Bitcoin for multi-party protocol=
s,
> among the many other reasons to adopt it.
>=20
>=20
> # Footnotes
>=20
> 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 ge=
t 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 outpu=
ts
> involved are jointly controlled by both parties, and thus neither party c=
an
> spend it without the cooperation of the other at some point.
>=20
> 2. [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replace=
able
> Invariant, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-N=
ovember/021175.html
>=20
> 3. [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLock=
Time,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021=
176.html
>=20
> 4. https://github.com/bitcoin/bitcoin/pull/26438
>=20
> 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 th=
at
> these proposed protocols are even viable.
>=20
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev