bolt2: relax channel_reserve_satoshis requirements

[ProofOfKeags]

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]

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]

Withdrawn in favor of bLIP-30

[TheBlueMatt]

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]

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]

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]

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]

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]

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]

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]

ACK, withdrawn (again 😅)

[TheBlueMatt]

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]

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