BOLT 7: Add note for 'htlc_minimum_msat' being static #500
Conversation
| @@ -390,7 +390,7 @@ fields in the `channel_update` message: | |||
| | ------------- | ------------------------- | -------------------------------- | | |||
| | 0 | `option_channel_htlc_max` | `htlc_maximum_msat` | | |||
|
|
|||
| Note that the `htlc_maximum_msat` field is static in the current | |||
| Note that the `htlc_maximum_msat` and `htlc_minimum_msat` fields are static in the current | |||
There was a problem hiding this comment.
Could clarify that they're static due to the inability to update the link level commitment constraints atm.
There was a problem hiding this comment.
In the below, it reads "it is not designed.." which gives the impression that not being able to update the link level commitment constraints is designed to be absent - not the inability. But your suggestion for changes are conflicting?
There was a problem hiding this comment.
Yes, full quote is fairly clear: "Note that the htlc_maximum_msat and htlc_minimum_msat fields are static in the current protocol over the life of the channel: "
There was a problem hiding this comment.
Perhaps i'm missing something but why should the htlc_minimum_msat field be static? Can't a client create a new channel_update with a different value X if it wants to avoid relaying payments smaller than X?
|
htlc_max isn't static. Nodes are free to update them to a value that's less than the total capacity of their channel. The advertised network level value must always be less-than-or-equal to the link level value. |
|
Yes, I think this change is fine, but it would be nice to clarify what is meant here as a separate PR. That said, this change is also trivial, so I've removed the 1.0 milestone. |
niftynei
added
the
clarification
No description provided.