BOLT 2: open_channel parameter negotiation

[donaloconnor]

trafficstars

The requirements of the open_channel message describe how the receiver may/should fail the channel in certain cases. For example, if the funding-satoshis field is too low.

Should there be another optional message reject_channel (Similar to TCP's NAK). This message would contain a failure reason(s) so the sender side can readjust the parameters (If it is possible to).

I am trying to picture this from a UI/UX perspective. A user wishes to open a channel with a party and presumably enters a funding amount but the party's LN client rejects it. It's difficult to imagine how this information would be propagated back to the user without some sort of error reason.

Thanks, Donal

[cdecker]

I think we have this partially covered with the error messages in BOLT 01, which allows us to close a channel and report a human readable error description. What is not covered is the automatic renegotiation, which I'm fully convinced whether it is desirable.

[donaloconnor]

My understanding was that the error description (data field) was designed for internal protocol use and humans would not see this description. I expected that this may be logged out.

Also we have the following which is a bit unclear to me:

It may be wise not to distinguish errors in production settings, lest it leak information, thus the optional data field.

Does this mean we don't use the data field in production environments or does it mean we only use the data field for non protocol type errors (IE. None exceptional/expected error cases)

I think it would be a good idea to expand the error msg so that it includes a uint16 error code value. The error codes could be grouped using the msb similar to the msg type.

I feel the current error msg gives very little information to the other peer. And is inflexible.

I would imagine wallet/LN implementations would prefer to be able to check an error code rather than do a string comparison.

Also there's the question of is it strictly an error if the user specified unsatisfactory values when opening a channel.

Thanks again, Donal

[rustyrussell]

I think we're going to have to see in practice whether this is a problem, before we overdesign. I expect that any client offering "reasonable" terms will be accepted, and rejection due to this will be the exception. If that proves wrong, we'll have to figure out how we handle it...

It may be that we add a "rates card" message, where nodes can specify their tolerances. Let's mark this for consideration for v1.1 for now.

[ysangkok]

Any updates on this?