Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion 07-routing-gossip.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could clarify that they're static due to the inability to update the link level commitment constraints atm.

Copy link
Copy Markdown
Contributor Author

@yuntai yuntai Nov 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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: "

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

protocol over the life of the channel: it is *not* designed to be
indicative of real-time channel capacity in each direction, which
would be both a massive data leak and uselessly spam the network (it
Expand Down