BOLT 7: Add note for 'htlc_minimum_msat' being static#500
Conversation
| | 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. |
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
Change is obviously (tm) correct, if we want to change the meaning of the fields we can do that separately.
|
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
6 participants
No description provided.