Hi AJ,
Adding a few more thoughts here on what coinjoins/splicing/dual-funded folks can do to solve this DoS isse in an opt-in RBF world only.
I'm converging that deploying a distributed monitoring of the network mempools in the same fashion as zeroconf people is one solution, as you can detect a conflicting spend of your multi-party transaction. Let's say you have a web of well-connected full-nodes, each reporting all their incoming mempool transactions to some reconciliation layer.
This "mempools watchdog" infrastructure isn't exempt from mempools partitioning attacks by an adversary, where the goal is to control your local node mempool view. A partitioning trick is somehow as simple as policy changes across versions (e.g allowing Taproot Segwit v0.1 spends) or two same-feerate transactions. The partitioning attack can target at least two meaningful subsets. Either the miner mempools only, by conflicting all the reachable nodes in as many subsets with a "tainted" transaction (e.g set a special nSequence value for each), and looking on corresponding issued block. Or targeting the "watchdog" mempools only, where the adversary observation mechanism is the multi-party blame assignment round itself. There is an open question on how many "divide-and-conquer" rounds from an adversary viewpoint you need to efficiently identify all the complete set of "mempools watchdog". If the transaction-relay topology is highly dynamic thanks to outbound transaction-relay peers rotation, the hardness bar is increased.
Though ultimately, the rough mental model I'm thinking on, this is a "cat-and-mouse" game between the victims and the attacker, where the latter try to find the blind spots of the former. I would say there is a strong advantage to the attacker, in mapping the mempools can be batched against multiple sets of victims. While the victims have no entry barriers to deploy "mempools watchdog" there is a scarce resource in contest, namely the inbound connection slots (at least the miners ones).
Victims could batch their defense costs, in outsourcing the monitoring to dedicated entities (akin to LN watchtower). However, there is a belief in lack of a compensation mechanism, you will have only a low number of public ones (see number of BIP157 signaling nodes, or even Electrum ones). Outsource mempools monitoring will hit the same issue of bounded public resources, and as such be a "single-point-of-censorship" vector. Reminder, we would like LN mobile clients from low-budget users to access those fancy joint funding protocols (or at least I).
So as a first partial conclusion, not only the security efficiency but also the economic scalability of such defensive "mempools watchdog" infrastructure remains an open question to me.
Assuming we can solve them, there is still the issue of assigning blame reliably among a set of trust-minimized joint funding protocol participating UTXOs. Indeed, you're running quickly into issues like *two* double-spend from two sybilling participants, aiming to halt the assignment process. There is likely a need to introduce some "UTXO-satoshi-weight" vote to efficiently converge towards assignment. At the very least it would require the attacker to control more than 51% of the contributed UTXO to manipulate the outcome of the blame assignment process. Assuming an economically honest majority, you still have the timevalue cost inflicted for each round of blame assignment. Assuming 255 inputs (current LN's interactive construction protocol limit) and a transaction propagation delay of 2min (30s ?) on the p2p network, an attacker controlling all the inputs minus 1 might be able to DoS for ~50 blocks (do we have other factors to think of in the design of the blame assignment process ?). In a future where the timevalue of circulating coins is priced in (IMO when we have competitive LN routing markets), this is probably a significant damage.
On the other hand, you have a full-rbf world, where instead to deploy or gain access to "mempools watchdog" and proceed to a timevalue-expensive blame assignment protocol, any participant should be able to fee-bump the joint transaction (assuming multiple pre-signed feerate version of the transactions, or ephemeral, nversion=3 and package-relay to do unilateral CPFP). Ideally, this would be a reduction to a "flood-and-loot" attack, i.e the attacker is constrained to buy the blockspace. A situation with a lot of visibility for the joint funding protocol victims, I think.
Side-note: this alternative resolution process of relying on full-rbf, still assumes solving RBF pinning rule 3, I think a fact I underscored in my original full-rbf proposal of last year [0]. All that said, I think it's good to think more of the end-of-pipeline economic trade-offs of the two main directions to solve this DoS affecting joint funding protocol. Transaction signature withhold DoS should be defended on a different layer, and I think there are far more easy to deal with in a set of participant with at least stable temporary pseudonyms ("all participants should produce a signature before X, laziness due to buggy Internet connection is treated the same as a DoS" ?).
Best,
Antoine
[0] "Of course, even assuming full-rbf, propagation of the multi-party funded
transactions can still be interfered with by an attacker, simply
broadcasting a double-spend with a feerate equivalent to the honest
transaction. However, it tightens the attack scenario to a scorched earth
approach, where the attacker has to commit equivalent fee-bumping reserve
to maintain the pinning and might lose the "competing" fees to miners."
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html