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

Add option_zero_reserve (FEATURE 64/65) #1140

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Collaborator

@t-bast t-bast commented Feb 16, 2024

Lightning channels require nodes to lock some of their channel funds into a channel reserve, which cannot be used for payments made on that channel. This guarantees that both nodes always have an output in the commitment transaction, which they will lose if they publish a revoked commitment.

While this requirement is generally useful, it creates inefficiencies since that liquidity can't be used to relay payments, and provides a bad user experience. In some settings, we may want to remove that channel reserve and allow nodes to use all of their channel funds.

The option_zero_reserve feature lets nodes advertise that they allow their peers to disable the channel reserve on their side, and may lift the same requirement in response.

This is an alternative to #1133

Lightning channels require nodes to lock some of their channel funds
into a channel reserve, which cannot be used for payments made on
that channel. This guarantees that both nodes always have an output
in the commitment transaction, which they will lose if they publish
a revoked commitment.

While this requirement is generally useful, it creates inefficiencies
since that liquidity can't be used to relay payments, and provides a
bad user experience. In some settings, we may want to remove that
channel reserve and allow nodes to use all of their channel funds.

The `option_zero_reserve` feature lets nodes advertise that they
allow their peers to disable the channel reserve on their side,
and may lift the same requirement in response.
@Impa10r
Copy link

Impa10r commented Sep 13, 2024

Any traction on this? Will this option work with already opened channels, or only affect the future ones?

@t-bast
Copy link
Collaborator Author

t-bast commented Sep 13, 2024

This is implemented on our side, this proposal is waiting for reviews and implementation by the other teams.
It will only apply to new channels for now, but could be applied to existing channels via #1117 in the future.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Recently, the question came up how zero-reserve channels would interact with maintaining zero Anchor reserve. The particular scenario we wondered about: currently, when a node maintains zero on-chain reserves to spend Anchors, it could at least theoretically use/redirect the to_remote funds to claim pending zero-fee HTLC transactions once the commitment transaction confirms. However, it seems that with option_zero_reserve the to_remote might very well way too little to actually get the claim confirmed.

Do you have any thoughts on this? Wouldn't no-reserve users be at increased risk of losing HTLC funds to the counterparty?

@t-bast
Copy link
Collaborator Author

t-bast commented Feb 10, 2025

I'm not entirely sure I understand your comment correctly, probably because of terminology: are you referring to v3 commitments when saying "zero Anchor reserve"? If I understand you correctly, you're thinking about the following scenario:

  • Alice and Bob use a zero-reserve v3 channel, where Alice is a wallet user and doesn't have an on-chain wallet to use for CPFP
  • Alice sends all of her balance out: at that point, her only output in the commit tx is the corresponding HTLC output
  • If Bob force-closes, then there's no issue: Alice can claim her HTLC output from Bob's commitment (if it times out) by simply lowering the output amount (since we don't need a pre-signed transaction here)
  • Note that if Bob claims the HTLC (reveals the preimage), Alice doesn't have anything to claim: her payment was successful, so she doesn't have anything at stake in the channel
  • So you're worried about the case where Alice force-closes because the HTLC times out but wasn't failed by Bob, is that correct?
    • But if she force-closes and she doesn't have an on-chain wallet, the commit tx is 0-fee and she can't CPFP, so she cannot force-close anyway in that case?
    • We either need the wallet user to have external on-chain funds, or to maintain a reserve in that case to pay fees

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.

3 participants