RBF Pinning with Counterparties and Competing Interest

Summary:

In a discussion between Olaoluwa Osuntokun and Matt Corallo, they talk about proposed changes to the state machine that would restrict HTLC spends. Osuntokun suggests pre-signing all HTLC output spends with an off-chain 2-of-2 multi-sig covenant, but Corallo points out that even with restrictions, such as 1-in-1 out, sighashall, and pre-agreed upon fees, HTLC spends can still be spent with a CPFP and create another heavy tree, leading to the same bidding war scenario. The use of anchors, as defined in a spec PR, is also discussed, which forces parties to spend with an RBF-replaceable transaction, allowing a party to enter into a bidding war and hold something at the bottom of the mempool.However, Osuntokun mentions that there are other ways of doing pinning besides opting into RBF, but the "absolute fee/feerate" thing still screws the honest party. Both parties need to confirm within CLTV-delta for everyone to be made whole. Corallo disagrees with Osuntokun's comment about package limits being arbitrary and suggests starting with a concrete suggestion. The discussion also touches on monitoring the global mempool, which Osuntokun believes is not complex. However, watching the mempool is not guaranteed to work because an attacker could exploit your upgraded/non-upgraded status during upgrade cycles that include changes to policy rules. The assumption of having an active full node with an in-sync mempool is deemed obnoxious and impractical for many lightning users. A base version of anchors can resolve many issues, including eliminating the commitment fee guessing game, allowing users to pay less on force close, being able to coalesce 2nd level HTLC transactions with the same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC resolution. There is also a proposal to make all HTLC output spends pre-signed, but this may not be immediately workable.Instead, the proposal suggests CPFPing a maybe-broadcasted transaction by sending a transaction that spends it and seeing if it is accepted. In an attempt to counteract the issue, the revoke message now includes HTLC signatures for their new commitment allowing us to spend our HTLCs, but this resolves things in a weaker security model. Following this path would require an overhaul in the channel state machine to make presenting a new commitment take at least two phases.The first phase would tender the commitment but render them unable to broadcast it. The second phase would then enter a new sub-protocol, which upon conclusion, gives the commitment proposer valid HTLC signatures, and gives the responder what they need to be able to broadcast their commitment and claim their HTCLs in an atomic manner. Early versions of lnd used the mempool for commitment broadcast detection, but it turned out to be a bad idea, so it was removed. However, watching the mempool can mitigate the class of attack assuming the anchor output format as described in the open lightning-rfc PR. This issue can be mitigated today by adding mempool awareness into the system.

Updated on: 2023-05-23T03:17:13.452502+00:00