David A. Harding pointed out that this change could allow for the free relay of large amounts of data, potentially exceeding the default maximum mempool size. Johan Torås Halseth raised concerns about the cost of relaying data if all limits were removed. Matt Corallo suggested increasing the carve-out limit to support the current Lightning Network protocol.The discussion also touched on the feasibility of a simplified Replace-by-Fee (RBF) scheme and the need to lower the default minimum fee in Bitcoin Core. There were discussions about implementing a tree structure for HTLCs, relaxing the carve-out rule, and utilizing a Lightning close algorithm. The proposed changes aimed to improve efficiency and mitigate potential spamming issues. However, there were concerns about the impact on the mempool acceptance code in bitcoind.The email thread also explored the possibility of relaxing the Carve-Out rule for on-chain contracts and implementing a simplified RBF scheme. Johan Torås Halseth suggested changing the rule to allow for more robust CPFP of Lightning commitment transactions. Rusty Russell proposed a simplified RBF scheme with specific conditions for transaction replacement. There were discussions about potential spamming issues, marking unilateral close transactions, and the impact on the mempool acceptance code.The email exchange highlighted the ongoing efforts to optimize the mempool and address the challenges associated with OP_SECURETHEBAG and RBF. Developers proposed various solutions, including changes to the carve-out rule and the implementation of a lightning close algorithm. The discussions emphasized the need for simplicity, feasibility, and compatibility with the Lightning Network protocol.Matt Corallo has proposed a solution to the Replace-by-fee (RBF) problem in the Lightning Network. His proposal involves allowing transactors to mark their transactions as "likely-to-be-RBF'ed" to enable a relay policy where any children of such transactions would be rejected unless the resulting package would be "near the top of the mempool". While this theoretically prevents consistent attacks, there is still a low probability of executing such attacks in case of feerate spikes right after broadcast. Corallo believes that his proposal is incentive-compatible and addresses the issue of adding too many transactions to the UTXO set.The Lightning Network has been facing problems with the security model around Child Pays for Parent (CPFP). This has led to channel failures and difficulties in preventing third parties from delaying the confirmation of commitment transactions. To address this, Corallo suggests tweaking Lightning's commitment transaction to have two small-value outputs that are immediately spendable by each channel participant.Another alternative proposal discussed is to mark transactions as "likely-to-be-RBF'ed" to enable a relay policy where children of such transactions would be rejected unless the resulting package would be "near the top of the mempool". Although this theoretically prevents consistent attacks, there is still a low probability of executing such attacks in case of feerate spikes right after broadcast.Overall, these proposals aim to improve the security and efficiency of the Lightning Network by addressing the issues related to RBF and CPFP.