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

bolt2: relax channel_reserve_satoshis requirements #1133

Closed

Conversation

ProofOfKeags
Copy link
Contributor

In some cases it can make sense to extend more trust to your channel counterparty and therefore not require them to always have something to lose in a breach scenario. This change relaxes the requirement to a recommendation to accommodate these scenarios.

The main situation where we see demand for this is in the LSP<->Mobile use case where the LSP does not desire to impose a channel reserve requirement on the Mobile side. To accomplish this today, those use cases would explicitly choose to violate the spec.

This change would make this (very legitimate but risky) choice one that is ultimately still spec-compliant.

In some cases it can make sense to extend more trust to your
channel counterparty and therefore not require them to always have
something to lose in a breach scenario. This change relaxes the
requirement to a recommendation to accommodate these scenarios.

The main situation where we see demand for this is in the
LSP<->Mobile use case where the LSP does not desire to impose a
channel reserve requirement on the Mobile side. To accomplish this
today, those use cases would explicitly choose to violate the spec.

This change would make this (very legitimate but risky) choice
one that is ultimately still spec-compliant.
@t-bast
Copy link
Collaborator

t-bast commented Feb 1, 2024

I'm not sure we should change anything in the BOLTs, since the BOLTs explicitly disallow zero-reserve. If both peers set the 0-reserve feature bit proposed here, then as any new feature, it allows changing spec requirements, so that feature bit indicates that we ignore the BOLTs reserve requirements, and that's ok on its own?

@ProofOfKeags
Copy link
Contributor Author

Withdrawn in favor of bLIP-30

@TheBlueMatt
Copy link
Collaborator

While I dont disagree that we can leave the sending side here, afaiu several (all?) nodes actually already don't enforce the reserve requirements on the receiving end (why would you, if your peer wants to disable their ability to punish you so what), and the BOLTs should reflect that.

@ProofOfKeags
Copy link
Contributor Author

The way the spec is written, the channel_reserve_satoshis value presented during open/accept is always an imposition on the other side, not a volunteering of how much collateral is being put up. Therefore it can be set arbitrarily low. Only if it is burdensome in how high it is does the receiver need to reject anything.

I think the spec, in general, needs to be more judicious in how it applies the word "MUST".

If many implementations already do not enforce reserve requirements then keeping this as a "MUST" in the spec only confuses everyone involved.

I changed my mind and am reopening for discussion.

@t-bast
Copy link
Collaborator

t-bast commented Feb 13, 2024

Some feedback from yesterday's spec meeting: the issue with relaxing those requirements is that you don't know if your peer uses the relaxed version or not, so you don't know whether you actually can send them a channel_reserve_satoshis that is lower than dust_limit_satoshis. The usual way of addressing that is through a feature bit. Since most implementations are signaling intent to support some way of allowing 0-reserve channels, it would make more sense to move my bLIP PR to the BOLT repository, so that we can wrap those requirements in an if zero_reserve then SHOULD else MUST.

I'll try to get that done before the next spec meeting.

@ProofOfKeags
Copy link
Contributor Author

so you don't know whether you actually can send them a channel_reserve_satoshis that is lower than dust_limit_satoshis

This is why you still SHOULD send a higher channel reserve than the dust limit.

@t-bast
Copy link
Collaborator

t-bast commented Feb 15, 2024

This is why you still SHOULD send a higher channel reserve than the dust limit.

Sure, but that PR is really a half-measure, because then there's no case where we would actually not follow that SHOULD. Since all implementations said they would like a 0-reserve feature, it makes more sense to go all the way and add the entire feature to the BOLTs instead of going just half-way.

@ProofOfKeags
Copy link
Contributor Author

Why is it different than any other situation when we reject a channel because of unfavorable parameters? (to_self_delay, channel size)

We reject a channel open or accept for all sorts of reasons. The way we cope with that is we check out the error and decide how to deal with it accordingly. Is this fundamentally different?

I am not opposed to going the 0-reserve feature bit route, but I just would like to understand the role of the spec and why these lines of reasoning seem to not be applied uniformly. Inconsistency in how we handle these things creates a steep learning curve for new developers and in order for us to have a robust system it has to be resilient to developer turnover.

@t-bast
Copy link
Collaborator

t-bast commented Feb 16, 2024

Why is it different than any other situation when we reject a channel because of unfavorable parameters? (to_self_delay, channel size)

The reason this specific requirement is a MUST is to avoid the theoretical case where you end up with a commitment transaction that has no output, and thus becomes invalid (as mentioned in the rationale). This would be a real issue because if you get into that state, one side could blackmail the other if they want their funds back.

In practice though, you could force-close before getting into that state where the commit tx has no outputs. So we could do without this requirement, but it does make things slightly simpler because then we don't need to think about this edge case at all.

Inconsistency in how we handle these things creates a steep learning curve for new developers and in order for us to have a robust system it has to be resilient to developer turnover.

Unfortunately those inconsistencies are there for good reasons, because there are a lot of edge cases that need to be protected against. That's one of the reasons I'm eager to have v3 transactions and 0-fee commitment transactions, because it removes a lot of subtle edge cases around the commitment transaction and simplifies the spec.

@ProofOfKeags
Copy link
Contributor Author

ACK, withdrawn (again 😅)

@TheBlueMatt
Copy link
Collaborator

I'm still kinda confused why this was closed. Indeed, we probably want to not touch the sending/value-setting side at all, senders MUST set it to something that will prevent the output from being removed, but there is no need to mandate recipient behavior, and ISTM we shouldn't, in part because it represents what nodes actually do.

@t-bast
Copy link
Collaborator

t-bast commented Feb 21, 2024

That should be done in #1140, that's why this PR was closed, because it's a subset of #1140

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