Hi,
In this post I would like to highlight some DoS attacks against multi-party
Bitcoin protocols during their funding phases. Recent discussions around
DLC funding flow [0] and dual-funding of LN channel [1] remind me that some
timevalue DoS/fee inflation issues are common to any multi-party funded
transactions. I'm not sure how much developers meddle in that kind of
protocols/applications are aware of them and how well they mitigate against
them.
The first issue is a timevalue DoS by exploiting standardness malleability.
The second one is a fee inflation one by exploiting RBF policy rules. User
utxo aren't directly at risk but those attacks might reveal themselves as
severe nuisances. More sophisticated variations do exist, but those ones
are pretty easy and cheap to execute with a high-rate of success.
# The Model : Multi-Party Funded Transaction
Let's say Alice, Bob and Caroll commit one input in a single transaction.
Each of them receive inputs from others, verify the outpoint existence (and
is a segwit one if you have a chain of child transactions) and sign the
whole transaction data with sighash_all to enforce the expected protocol
semantics. One of them collects all the witnesses and broadcasts the
finalized transaction. This broadcaster might be responsible to fee-bump
the transaction through CPFP if the feerate as previously negotiated isn't
good enough for a quick confirmation.
Once the transaction is confirmed, the protocol moves in its operation
phase (e.g start channel updates) or might even end up here (e.g a basic
one-stage coinjoin). But those later phases are out of concern.
I think this rough model applies to a wide set of L2 bitcoin protocols
(DLC, Coinjoin, Payjoin, dual-funded LN channel, swaps ?). Notice that
*single-party funded*, multi-party transactions (e.g batching_tx to N
payouts) are excluded from this discussion. Although they do share the same
risks, exploits against them are a bit harder, as the attacker has to
execute a real RBF-pinning on a payout output, more costly in feerate.
Accepting input and committing coins with a low-trusted counterparty opens
the way to some troubles.
# 1st issue : Standardness Malleability of Counterparty Input
Current Core's script interpreter is applying some stricter checks beyond
the consensus one, like MINIMALIF or NULLFAIL (bip143). While non-compliant
with those checks, witness data might still succeed consensus checks. A L2
client only verifying input for consensus validity will miss standardness
validity and sign/broadcast a non-propagating transaction.
In the model described above, Alice might furnish a non-MINIMALIF compliant
p2wsh spending input to Bob and Caroll, they will accept it as a valid
input, finish the transaction finalization and try to broadcast. It will
fail to propagate and confirm. If Bob and Caroll are relying on a
full-node, they can observe the failure directly and move their coins.
Otherwise, if they don't have access to a mempool policy verifier, they
should move their coins after some timeout.
In both cases, victims of this malleability will waste timevalue on their
coins and likely fees for a double-spend of their honest inputs, as it's
better to cancel out the corrupted multi-party funding transaction. If the
double-spend timeout only occurs after a meaningful timeout, e.g 2048
blocks ahead from signatures exchange like for the recent LN change [2],
this timevalue loss might be in the same range that one's suffered on LN's
revokeable outputs. The attacker coin might be of far lower value than the
victim ones and the asymmetry should be underscored, *one* malicious input
lets you affect *N* victim ones.
As a simple mitigation, participants of the multi-party funded transaction
should verify the absence of standardness malleability of contributed
witnessScripts. Though AFAIK, we don't have such tooling available
ready-to-integrate in L2 stack client [3].
Notice, I'm not considering timevalue DoS inflicted by malicious
broadcaster/orchestrator, where signatures are collected but transaction
broadcast is withheld. This should be minded at counterparty/service
selection but it's beyond the scope of an analysis centered on
mempool/tx-relay risks.
# 2nd issue : RBF opt-out by a Counterparty Double-Spend
Current bip125 RBF rules make signaling mandatory to enable replacement,
otherwise even a better-feerate candidate won't replace a conflicting
transaction with a finalized nSequence field [4]. A L2 client might be in
possession of better-feerate multi-party funded transactions but it won't
propagate on today's network if a opt-out double-spend is already present.
In the model described above, Alice might provide a consensus-and-standard
valid input to Bob and Caroll, they will verify and accept it, finish the
transaction finalization and broadcast. Meantimes, Alice will mass-connect
to the network and announce a double-spend of its input with
nSequence=0x. Alice-Bob-Caroll's funding transaction
