These attacks have two primary methods: preventing the broadcast of joint transactions or delaying their confirmation. An attacker could withhold signatures, use non-existent inputs, or employ low feerate ancestors to delay the broadcast or confirmation of a transaction, effectively trapping the victim's liquidity.

Several strategies have been proposed to mitigate these attacks. One such method is requiring the transaction initiator to sign first, which can help guard against signature withholding and witness inflation. However, this approach limits batched transactions and does not protect the initiator from griefing. Delaying the locking of UTXOs until the transaction has been broadcast can prevent attackers from locking up liquidity by stopping the transaction broadcast but raises the risk of accidental double-spending and is less feasible when multiple concurrent sessions are expected.

Requiring confirmed inputs for the joint transaction blocks vectors relying on unconfirmed inputs but introduces a minimum dealy tied to block confirmation times. Mempool monitoring allows for the inspection of unconfirmed ancestors and watching for conflicting transactions; however, it relies on having access to a full node's mempool and may not reflect the state of other mempools across the network.

Restricting inputs to be pay-to-witness-public-key-hash (p2wpkh) prevents witness inflation but significantly limits the usability of multi-party protocols. Anchor outputs provide a partial fix to witness inflation through CPFP carve-outs, but this remedy is limited to two-party protocols and can become costly if the victim must consistently pay extra fees to confirm transactions.

The notion of using version 3 (v3) transactions was also discussed. While they offer a partial solution to witness inflation, they come with their own drawbacks, including potential RBF penalty fees, and moreover, v3 transactions are not yet available.

In conclusion, while various defenses exist against liquidity griefing vectors, they often involve tradeoffs, and no perfect solutions have been identified, especially in the case of pinned conflicting transactions that are absent from the victim's mempool. The ongoing conversation among developers aims to find more effective ways to tackle these challenges within multi-party transaction protocols.