RBF Pinning with Counterparties and Competing Interest



Summary:

The email thread discusses the limitations of Bitcoin contracts that rely on nested trees of transaction to confirm, and the root issue of package limits for computational complexity. The simplest heuristic, which is to accept the higher fee rate package, side-steps all these issues and is economically rational. The discussion also considers monitoring the global mempool as a mitigation for lightning implementations, but this is complex and resource-intensive for public routing nodes. Watching the mempool, however, can mitigate a class of attacks and is less involved than modifying the state machine. An anchor output format resolves several issues, including eliminating the commitment fee guessing game, allowing users to pay less on force close, and being able to coalesce 2nd level HTLC transactions with the same CLTV expiry. However, the suggestion to make all HTLC output spends pre-signed may not be workable due to the need for additional signatures to allow parties to spend HTLCs on each other's versions of the commitment. This would require an overhaul in the channel state machine to make presenting a new commitment take at least two phases, with the second phase entering a new sub-protocol.


Updated on: 2023-05-23T03:28:58.653486+00:00