The Pinning & Replacement Problem Set

Antoine mentions that this issue has been described in a paper under the "forced expiration spam" problems arising within a high block space demand environment. He also acknowledges that there are variants of these issues with scenarios like "flood & loot." The new problem that arises is that the counterparty channel might defer the confirmation of an honest on-chain spend, which aligns with miners' incentives.

Antoine suggests several options to address this issue. The first option is to revert to a static world with no replacement-by-fee mechanism as a widely deployed network policy. Antoine believes that in a competitive mining environment, parties can always reach out to miners with higher fee packages than available in the local mempool.

The second option proposed by Antoine is to design, implement, and deploy policies that better capture transaction-issuer intent regarding the replacement of current in-mempool transactions. However, Antoine points out that with lightning and other time-sensitive layers, there isn't a single transaction-issuer intent due to the competing interests of counterparties within off-chain states.

The third option suggested by Antoine is to remove all policies and let the network of nodes and the economic ecosystem evolve on its own. Antoine notes that some mempool policies are anti-Denial-of-Service measures protecting low-performance full-nodes, and these measures contribute to pinning issues. He believes that "pure" replacement-by-fee (RBF) only worsens adversarial replacement issues.

The fourth option proposed by Antoine is to do nothing and allow a fragmented mempool environment, where large lightning and Bitcoin businesses have out-of-band relationships with miners and pools to support their packages, along with some service-level safety agreements. This option was previously considered by the lightning community to solve pinning issues but was dismissed due to concerns about centralization.

The final option suggested by Antoine is to design and implement some consensus change or alter the processing requirements of full-nodes to align incentives between miners and time-sensitive second-layers. He mentions the "reverse locktime" new Bitcoin script opcode idea or a replacement cache at the mempool level as examples.

In response, John disagrees with Antoine's statement linking replacement cycling to full-RBF (replace-by-fee). He argues that in the case of anchor channels, it is not even possible to turn off RBF due to the 1 block CSV delay. John also mentions that the largest pool, AntPool, currently has full-RBF enabled. He suggests designing protocols that are made secure by clear incentives instead of relying on specific mempool behaviors.

John further expresses his concern that all layers and technologies built on Bitcoin will fail when miners misbehave or when blocks and the mempool remain consistently full. He criticizes the decision to mess with mempool policies like RBF and mempoolfullrbf, stating that they have disrupted the fragile harmony and utility of Bitcoin. He emphasizes that both pinning and replacement problems now exist in Lightning due to these changes.

John presents several options for Core to address the issue. The first option is to try to revert mempoolfullrbf and reinstate the first-seen policy, although it is uncertain if this would be effective. The second option is to create additional policies that allow users to flag how they want their transactions handled, such as distinguishing between "pin this" and "replace this." John considers this the best option as it provides utility and aligns with incentives.

The third option is to remove all policy and let the market evolve to deal with the chaos, similar to doing nothing. The fourth option is to allow a fractured mempool environment to develop where large businesses form private contracts with miners and pools to support their own policies, providing better experiences to customers and users. The fifth option is to invent a new cryptographic solution that John cannot currently imagine.

In conclusion, the email exchange highlights the safety issues related to lightning and time-sensitive layers in the context of full blocks and explores various options for addressing these problems. Both Antoine and John present different perspectives on how to navigate these challenges and find solutions that align with incentives and preserve the utility of Bitcoin.