bLIP-0030: zero-reserve channels

[t-bast]

Nodes can opt-in to remove the channel reserve requirements, which makes better use of their channel liquidity.

If https://github.com/lightning/bolts/pull/1140 is accepted to the BOLTs, I will update this bLIP to only contains details for the fraud proof construction (which I don't think makes sense in the BOLTs).

[JssDWt]

Does this blip need some info on how to handle dust? The reserve is below the dust bounds, which is unusual. Also there's a possibility to end up with a transaction without outputs in certain scenarios, like when routing the entire channel capacity with dust htlcs.

[t-bast]

While it's unusual, it usually doesn't create specific issues, so we generally don't even need to mention it (outputs are simply trimmed with the existing mechanisms). You have a good point though about a commit tx potentially becoming empty: we must not let that happen!

In practice that should never happen, because:

• there is a limit to dust exposure (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#bounding-exposure-to-trimmed-in-flight-htlcs-max_dust_htlc_exposure_msat) that should be bounded by a percentage of the channel size: but it is maintained by failing HTLCs that go over, so it doesn't fully prevent the commit from becoming empty
• there is a limit to pending HTLCs (max_htlc_value_in_flight_msat) and the recommandation is to set this to something strictly smaller than 50% of the channel capacity

But I agree with you that this should still be explicitly mentioned in this spec. I don't think there's a good way of handling it when it happens, we should rather focus on making sure it doesn't and simply say that you must force-close if the commit tx is becoming empty. Does that sound reasonable @JssDWt?

[JssDWt]

But I agree with you that this should still be explicitly mentioned in this spec. I don't think there's a good way of handling it when it happens, we should rather focus on making sure it doesn't and simply say that you must force-close if the commit tx is becoming empty. Does that sound reasonable @JssDWt?

That does sound reasonable. Along with some preventive measure, like you must not add a htlc if that causes the commitment tx to become empty.

[t-bast]

Sounds good, I'll add that shortly. Thanks!

[t-bast]

Done in https://github.com/lightning/blips/pull/30/commits/a912d64c2565623b800bea9201fcaac32f94767c

[niteshbalusu11]

ACK.

[t-bast]

I submitted https://github.com/lightning/bolts/pull/1140 to the BOLTs repository: if it is accepted, I will update this bLIP to only contains details for the fraud proof construction (which I don't think makes sense in the BOLTs).