release: bump version to v0.18.3 rc2 #9036

Initially in lnd, we didn't store the extra TLV data that could be dangling off of gossip messages. This was fixed initially in lnd v0.5 with this PR: lightningnetwork#1825. Within the PR, we incorrect set the `ExtraOpaqueData` (extra TLV blob) of the `ChannelAnnouncement` to the value stored in `edge`, which is actually our channel update. As 6-ish years ago we didn't yet have anything that used the TLV gossip fields, this went unnoticed. Fast forward to 2024, we shipped an experimental version of inbounbd fees. This starts to store additional data in the `ExtraOpaqueData` field, the TLV for the inbound fee. Initially, everything is valid when the first `ChannelAnnouncement` is sent, but as soon as a user attempts to set an inbound fee policy, we'd incorrectly swap in that new serialized TLV for the _channel announcement_: lightningnetwork@841e243#diff-1eda595bbebe495bd74a6a0431c46b66cb4e8b53beb311067c010feac2665dcbR2560. Since we're just trying to generate a new `channel_update`, we don't also regenerate the signature for the `channel_announcement` message. As a result, we end up storing a `channel_announcement` with an invalid sig on disk, continuing to broadcast that to peers.

if we use %x here we would get the hex representation of the String() method of the vertex, which is wrong.

ChanUpdate timestamps are now restircted so that they cannot be more than two weeks into the future. Moreover channels with both timestamps in the ReplyChannelRange msg either too far in the past or too far in the future are not queried. Moreover fix unitests.

Describe why it is ok to resurrect zombie channels based on the timestamp of the `ReplyChannelRange` msg although its not verifiable data.

Removes a check where we would NOT allow to create a blinded invoice with an expiry (invoice expiry in seconds considered as block time) lower than the min_final_ctlv_delta.

We will not add a buffer to the chan policy for blinded paths in case the sender amount violates the minHTLC restriction in the first place. Moreover we disgard a route fast if the payment amount is smaller than the minHTLC along the route.

This commit adds the ability to store closed channels by scid in the database. This will allow the gossiper to ignore channel announcements for closed channels without having to do any expensive validation.

This commit introduces a ban manager that marks peers as banned if they send too many invalid channel announcements to us. Expired entries are purged after a certain period of time (currently 48 hours).

This will be used in the gossiper to disconnect from peers if their ban score passes the ban threshold.

This commit hooks up the banman to the gossiper: - peers that are banned and don't have a channel with us will get disconnected until they are unbanned. - peers that are banned and have a channel with us won't get disconnected, but we will ignore their channel announcements until they are no longer banned. Note that this only disables gossip of announcements to us and still allows us to open channels to them.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

release: bump version to v0.18.3 rc2 #9036

release: bump version to v0.18.3 rc2 #9036

Commits on Aug 27, 2024