Published on: 2019-10-30T07:22:53+00:00
In an email exchange, Johan Torås Halseth suggests relaxing the current mempool limits to allow for more data being relayed. However, David A. Harding points out that this could lead to a free relay attack. The discussion also touches on the limitations and issues of the current mempool acceptance code in bitcoind. Johan proposes a new rule for mempool transactions, but Dave raises concerns about potential risks. A document is added to the Bitcoin Core developer wiki to describe these risks and mitigation strategies.The conversation continues with discussions on mempool limits for OP_SECURETHEBAG and the two main categories of mempool issues: relay cost and mempool walking. To address the relay cost issue, proper assessment of Replace By Fee update fees is suggested. The walking issue can be solved by caching with a set to avoid re-expanding a node. OP_SECURETHEBAG is proposed as a solution to the Lightning Network issue, where all HTLCs are put into a tree structure. The discussion also explores the possibility of relaxing the carve-out rule in bitcoind 0.19 to support more robust CPFP of on-chain contracts.Further discussions revolve around the addition of the carve-out rule in bitcoind 0.19 and its impact on on-chain contracts like Lightning commitment transactions. Johan suggests relaxing some of the current limits, but Matt Corallo explains that at least one non-CSV output per party is still required. Rusty Russell proposes a simplified RBF approach to address the issue of exceeding the MAX_PACKAGE_VIRTUAL_SIZE limit. The discussion also raises questions about the current mempool acceptance code in bitcoind and its ability to handle certain scenarios.The conversation also includes discussions on the recently released RC for bitcoind 0.19, the use of a carve-out rule for CPFP of on-chain contracts, and the proposal to relax the current mempool limits. The limitations and potential risks of the proposed changes are examined, along with suggestions for mitigation strategies. Rusty Russell proposes a simplified RBF approach that allows for replacement under certain conditions. The discussion highlights the need to carefully consider the impact of these changes on the system and ensure they do not allow for attacks or excessive bandwidth usage.Overall, the email thread explores various aspects of mempool acceptance code, mempool limits, CPFP of on-chain contracts, and the potential impact of proposed changes on the Bitcoin network. The developers discuss different solutions and their implications, aiming to find a balance between efficiency, security, and usability.The email exchanges discussed various issues related to the Lightning Network and its requirements. One of the main concerns raised by Matt Corallo was defining a criteria for "near the top of the mempool" in order to confirm transactions by a specific deadline. Rusty suggested defining it as "in the first 4 MSipa," but acknowledged that this approach may have some drawbacks. Another topic discussed was the RBF-pinning problem, where transactors mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. The proposal suggested rejecting children of such transactions unless they are "near the top of the mempool." However, this proposal faced challenges in defining the criteria for "near the top of the mempool" and meeting Lightning's requirements for transaction confirmation.Matt Corallo proposed an alternative solution to the RBF-pinning problem, involving marking transactions as "likely-to-be-RBF'ed" and adding inputs after-the-fact using SIGHASH_SINGLE. This option, however, led to channel failures in practice. It was also suggested that cross-signing would be necessary for Lightning to discourage parties from picking apart transactions and broadcasting only one SIGHASH_SINGLE.CPFP (Child-Pays-For-Parent) was discussed as a way to increase the fee rate of a transaction by attaching children transactions with higher fees. However, there were concerns about the complexity of implementing CPFP due to anti-DoS rules. A proposal to tweak Lightning's commitment transaction by having two small-value outputs was suggested to address CPFP security model considerations. This would allow each channel participant to immediately spend their output and chain children off without allowing unrelated third parties to do the same.In conclusion, the email exchanges explored different proposals and challenges related to transaction confirmation, RBF-pinning, CPFP, and tweaking Lightning's commitment transaction to address security considerations. The discussions aimed to find simpler and more efficient solutions for the Lightning Network and similar systems.The "PACKAGE_VIRTUAL_SIZE" refers to a Vsize of 1001. This Vsize indicates the size of a package or transaction in a blockchain network. It is important to note that each counterparty involved in the transaction will have the ability to independently CPFP (Child Pays for Parent) the transaction. CPFP is a mechanism in which one party can accelerate the confirmation of a transaction by creating a child transaction that includes a higher fee.
Updated on: 2023-08-02T00:11:07.720143+00:00