CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

Posted by David A. Harding

Oct 28, 2019/17:14 UTC

Johan Torås Halseth raised concerns about the cost of relaying data if all limits were removed. Relaxing current rules to allow a child to be added to each output as long as it has a single unconfirmed parent would still only allow free relay of O(size of parent) extra data. Matt suggested increasing second-child carve-out to nth-child carve-out with an appropriate low value for n. Currently, BOLT2 limits the number of HTLCs to 483 on each side of the channel which means worst case free relay to support the current Lightning Network protocol would be about 39 MB. The existing rules (including second-child carve-out) force attackers to iterate more often to achieve an equivalent waste of bandwidth. This approach is costly in terms of fees and prevents significant increase in bandwidth expenses for people running relaying full nodes. Several developers are working on lowering the default minimum fee in Bitcoin Core.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback