Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bLIP-0030: zero-reserve channels #30

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Contributor

@t-bast t-bast commented Oct 24, 2023

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).

@t-bast t-bast changed the title bLIP-0029: zero-reserve channels bLIP-0030: zero-reserve channels Oct 24, 2023
Nodes can opt-in to remove the channel reserve requirements, which makes
better use of their channel liquidity.
Comment on lines +85 to +86
* When the funding transaction confirms:
* MUST send a `channel_update` using the final `short_channel_id`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

blip-0030.md Outdated Show resolved Hide resolved
blip-0030.md Show resolved Hide resolved
Similar to what is done for `require_confirmed_inputs`.
We add a requirement for the receiver of `accept_channel` and
`accept_channel2`.
Copy link

@morehouse morehouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 95f7ad1.

@JssDWt
Copy link

JssDWt commented Nov 21, 2023

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
Copy link
Contributor Author

t-bast commented Nov 22, 2023

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?

@JssDWt
Copy link

JssDWt commented Nov 22, 2023

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
Copy link
Contributor Author

t-bast commented Nov 22, 2023

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

@t-bast
Copy link
Contributor Author

t-bast commented Nov 22, 2023

Done in a912d64

Comment on lines +107 to +108
The use of zero-reserve is symmetrical: it is either offered to both nodes or
unused.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the rationale to make the zero-reserve specification symmetrical? Is that because it's already possible to do one-sided zero reserve?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@niteshbalusu11
Copy link

ACK.

@t-bast
Copy link
Contributor Author

t-bast commented Feb 16, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants