path: root/15/83577481229853ede88ea357b26c918a489bd2

Return-Path: <alicexbt@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BDF48C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 09:19:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 98057416D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 09:19:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 98057416D3
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=MXC786xT
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id i8wozUhIyEAe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 09:19:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9FBFB416D1
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 9FBFB416D1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 Jan 2023 09:19:51 +0000 (UTC)
Date: Tue, 10 Jan 2023 09:19:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1673342389; x=1673601589;
 bh=2pFzzAutVocXEnwNcmAnX5kD2wBfiFwH0hx+Qmecq+o=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=MXC786xTOp4A6zE9ZmfFbp0952TiKOAzdNzIAGZTPP0zFzB+7JY4VH9dEz9j24cN9
 yr6Ypnk2EqlqHeo65GCv+eVUyfVJ+4r7welDfpX526j4Fsy6/Udw5ZiBauEZvZFEmK
 fGGrfecNG6JEvbNwB/RAp+aTtp7Du8il9Na5pakBPfpPkJzd6QrOWq+1xaMKbxVZ/B
 JaYv+mZQu56kI/3i8y1JkzqsmRA/ds6NAkyXdRh1+9cFqv7cpW3w+sd5FhTHixl5Ul
 /TOoHBv03tjYQ5/4BysF8CDtyHAk5eqDtcVJowou+2fg1Wq/RoLSts/oL1tEARFW8Z
 YMOtqCiIGMELg==
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
X-Mailman-Approved-At: Thu, 12 Jan 2023 09:59:50 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty
	Protocols Significantly More Expensive
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2023 09:19:53 -0000

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