Combined summary - Liquidity griefing in multi-party transaction protocols
The recent discussions among programmers have shed light on various technical challenges and potential improvements in blockchain transaction processing, specifically within the context of Bitcoin transactions.
A primary focus is on mitigating pinning attacks and witness inflation. An envisioned post-cluster mempool scheme has been proposed to address these by requiring transactions to be in the top block to enter the mempool. This approach could improve the safety of batch Child Pays for Parent (CPFP) operations and ANYONECANPAY transactions used in Hash Time Locked Contracts (HTLCs). Despite these potential improvements, concerns remain regarding conflicting transactions, which could bypass opt-in rules and lead to issues such as mempool partitioning and liquidity locking.
A significant issue in transaction fee rates involves inflated transactions paying lower fees than expected and being replaced by others offering higher fees. The disparity in package sizes by a factor of 500 magnifies this problem. Anti-DoS rule3 can either alleviate or exacerbate this depending on whether a transaction is evicted from the mempool. Version 3 (v3) of the protocol, while preventing pinning, still leaves vulnerabilities to witness inflation attacks. These attacks could drain a victim's funds by inflating fees without costing the attacker, emphasizing the need for further testing and improved security measures against such exploitation tactics.
Pinning attacks present another challenge where an attacker aims to lower the feerate of a funding transaction through low-feerate ancestors. Such ancestors may be dropped from mempools, allowing honest transactions to proceed. Practical experiments by @TheBlueMatt indicate that even low-feerate transactions might confirm eventually. However, witness inflation can force higher fees on the victim's Unspent Transaction Outputs (UTXOs), and v3 transactions, although not yet available, introduce potential RBF penalty fees.
Liquidity griefing attacks lock up users' UTXOs and demand high ransoms for release. Strategies to mitigate these include signing order requirements, delayed UTXO locking, confirmed inputs for joint transactions, mempool monitoring, p2wpkh input restrictions, and anchor outputs. Each strategy carries trade-offs and limitations, particularly in multi-party transaction protocols.
Concerns were also raised about using Pay to Taproot (p2tr) inputs in Lightning transactions due to the risk of witness size inflation through the annex field. Standardization efforts must prevent such exploitation. Future development paths include wider adoption of v3 transactions with ad-hoc rules for specific situations or more generalized opt-in methods from post-cluster mempool innovations.
The liquidity ads protocol was discussed, highlighting the non-initiator's role in providing funds only when compensated by the initiator. Node operators are advised to use dedicated wallets for leasing funds to limit exposure to griefing. While various mitigations exist, no perfect solution is found at the lightning layer without drawbacks. Improvements at the mempool layer, like package relay, v3 transactions, ephemeral anchors, and cluster mempool, are under research and offer hope for future integration. Selling liquidity currently carries risks, and achieving a balance between protocol-level mitigations and policy implementations is ongoing.