bLIP-0030: zero-reserve channels #30
Conversation
t-bast
changed the title
Nodes can opt-in to remove the channel reserve requirements, which makes better use of their channel liquidity.
| * When the funding transaction confirms: | ||
| * MUST send a `channel_update` using the final `short_channel_id` |
There was a problem hiding this comment.
Note this requirement, which is necessary when using scid_alias. Without that, the channel updates would only be signed with a local alias, which doesn't allow tying the channel_update to a specific on-chain outpoint.
This feels hacky though: we could instead introduce a dedicated proof for the zero-reserve case. This could be as simple as a TLV in channel_ready that contains a signature of the funding output's script using the private key associated with the node_id.
Similar to what is done for `require_confirmed_inputs`. We add a requirement for the receiver of `accept_channel` and `accept_channel2`.
|
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. |
|
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:
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. |
|
Sounds good, I'll add that shortly. Thanks! |
As suggested by @JssDWt
|
Done in a912d64 |
| The use of zero-reserve is symmetrical: it is either offered to both nodes or | ||
| unused. |
There was a problem hiding this comment.
What is the rationale to make the zero-reserve specification symmetrical? Is that because it's already possible to do one-sided zero reserve?
There was a problem hiding this comment.
Why wouldn't we make it symmetrical? In order to get the full benefits for a mobile wallet user, you have to allow the LSP side to also be 0-reserve, otherwise you don't benefit from the maximum amount of inbound liquidity.
There was a problem hiding this comment.
@t-bast You don't get the full benefit of inbound liquidity, but you do make sure the LSP has something to lose if it tries to cheat. There's value to that.
There was a problem hiding this comment.
I don't think it actually adds value in practice. In an LSP-wallet relationship, the LSP has enough incentives not to publish a revoked commitment. I detailed those in this thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-October/004136.html
That was the reasoning behind this symmetrical 0-reserve proposal. That doesn't mean you have to use it! If you prefer an asymmetrical proposal, there's always room for another bLIP for that.
|
ACK. |
|
I submitted lightning/bolts#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). |
Nodes can opt-in to remove the channel reserve requirements, which makes better use of their channel liquidity.
If lightning/bolts#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).