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  and dual-funding of LN channel  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 , 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 . 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 . 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=0xffffffff. Alice-Bob-Caroll's funding transaction won't propagate on the network as it's an attempt to double-spend a rbf opt-out transaction. A L2 client, with only a view of its mempool at best, won't understand why the transaction doesn't confirm and if it's responsible for the fee-bumping, it might do multiple rounds of feerate increase through CPFP, in vain. As the fee-bumping algorithm is assumed to be known if the victim client is open source code, the attacker can predict when the fee-bumping logic reaches its upper bound. When this bound is reached, the attacker might evict its own malicious opt-out double-spend by replacing an unconfirmed parent. At the next rebroadcast attempt by the L2 client, the funding transaction should propagate associated with a maliciously inflated feerate. Currently, we don't have mitigation against this simple pinning, as it exploits the first-seen mempool behavior. Participants of the multi-party funding transaction might double-spend their contributed inputs after some timeout, encumbering the fees and timevalue losses for nothing. # Conclusion Multi-party bitcoin protocols offer a wider attack surface when you consider actual mempool acceptance/tx-relay rules compared to simple bitcoin applications. As all those protocols are currently under design or in early deployment phase, I don't believe DoS attacks described are concerning for now. That said, if we don't address them at some point in the future, they're likely going to be a major source of disruption for users and services providers of such advanced bitcoin protocols. Even if those attacks might sound tricky for now and attacker incentives are relatively loose, always remember how far people have been leveraging Internet infrastructure illnesses to apparently proceed with their Minecraft business  I think the issues described are mostly right but please point out any shortcomings. Cheers, Antoine  https://github.com/discreetlogcontracts/dlcspecs/issues/155  https://github.com/lightningnetwork/lightning-rfc/pull/851  https://github.com/lightningnetwork/lightning-rfc/pull/839  We assume a protocol participant will first receive outpoints from others, validate their witnessScript, then release signatures. I don't think Core's `testmempoolaccept` lets you do a "validate their witnessScript" operation only without yelling first for lack of signature  https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L651  https://krebsonsecurity.com/2017/01/who-is-anna-senpai-the-mirai-worm-author/
_______________________________________________ Lightning-dev mailing list Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev