lightning-dev

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

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

Original Postby David A. Harding

Posted on: October 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.