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



Summary:

In a discussion about relay cost, Johan TorĂ¥s Halseth notes that removing all limits would lead to an increase in the amount of data being relayed. Relaxing the rules by allowing a child to be added to each output as long as it has a single unconfirmed parent would only allow for free relay of extra data of the size of the parent. However, if children were limited to 10,000 vbytes each, then almost 400 MB data size could be relayed, which is larger than the default maximum mempool size in Bitcoin Core. It is possible to increase second-child carve-out to nth-child carve-out but care must be taken to choose an appropriately low value for n. For example, BOLT2 places a limit on the number of HTLCs to 483 on each side of the channel (so a total of 966 + 2 outputs) and the worst case free relay to support the current LN protocol would be around 39 MB. Even if the mempool was empty, it would only cost an attacker about 1.5 BTC to fill it at the default minimum relay feerate, allowing them to execute an attack at minimal cost per iteration of paying for a few hundred or a few thousand vbytes at slightly higher than the current mempool minimum fee.However, with the existing rules, they would have to iterate 100 times more often to achieve an equivalent waste of bandwidth, costing them proportionally more in fees. As a result, raising the limits too high could make it significantly more bandwidth expensive for people to run relaying full nodes, thus there is a need to be careful not to raise them so far that attackers can take advantage of the system. Several developers are working on lowering the default minimum in Bitcoin Core, which would make this attack proportionally cheaper.


Updated on: 2023-06-13T15:50:45.309338+00:00