BOLT #7: Make channel_update always have htlc_maximum_msat.#996
BOLT #7: Make channel_update always have htlc_maximum_msat.#996rustyrussell wants to merge 2 commits into
Conversation
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
ACK 466317a |
Roasbeef
left a comment
Roasbeef
left a comment
There was a problem hiding this comment.
LGTM 🏂
Would be good to run some basic analysis just to check what % of channels aren't setting it.
vincenzopalazzo
left a comment
vincenzopalazzo
left a comment
There was a problem hiding this comment.
Concept ack for the "metrics"
t-bast
left a comment
t-bast
left a comment
There was a problem hiding this comment.
Concept ACK, I think we can remove even more stuff
Suggested-by: @t-bast Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
As noted in lightningdevkit/rust-lightning#1515 and discussed during the dev summit, it would also make sense to verify that every implementation sets this value to |
|
Retracting my ACK, I made a proposal at #999 that would benefit from message flags (but I did make |
|
I have just downloaded a fresh batch of 134k channel updates from an LND peer; of those channel updates, 364 don't have an HTLC max set, which is 0.27%. I have separately downloaded 161k updates from a different peer, and got 399 instances of an unset HTLC max, or 0.25%. |
The specification is removing support for old channel updates that didn't include an `htlc_maximum_msat` (lightning/bolts#996). Every implementation has been generating updates containing this field for years, so we can safely reject updates that don't contain it.
The specification is removing support for old channel updates that didn't include an `htlc_maximum_msat` (lightning/bolts#996). Every implementation has been generating updates containing this field for years, so we can safely reject updates that don't contain it.
The specification is removing support for old channel updates that didn't include an `htlc_maximum_msat` (lightning/bolts#996). Every implementation has been generating updates containing this field for years, so we can safely reject updates that don't contain it.
The specification is removing support for old channel updates that didn't include an `htlc_maximum_msat` (lightning/bolts#996). Every implementation has been generating updates containing this field for years, so we can safely reject updates that don't contain it.
|
Replaced by #999 |
7 participants
I think everyone sets this. Vastly simplifies parsing.
Indeed, every single of the 149964 channel updates seen by my node has his set.