Set `channel_update` disable bit based on staged even for onions
authorMatt Corallo <git@bluematt.me>
Mon, 17 Apr 2023 22:59:18 +0000 (22:59 +0000)
committerMatt Corallo <git@bluematt.me>
Tue, 18 Apr 2023 04:20:10 +0000 (04:20 +0000)
commit6e7000c5e7d246585d876e65a1aa8106fa948f7a
tree3931642ae04334263752e8a146cbed86e7db1f1d
parent2ebbe6f30467cd7f0688673f7bfbac297e5c3506
Set `channel_update` disable bit based on staged even for onions

When generating a `channel_update` either in response to a fee
configuration change or an HTLC failure, we currently poll the
channel to check if the peer's connected when setting the disabled
bit in the `channel_update`. This could cause cases where we set
the disable bit even though the peer *just* disconnected, and don't
generate a followup broadcast `channel_update` with the disabled
bit unset.

While a node generally shouldn't rebroadcast a `channel_update` it
received in an onion, there's nothing inherently stopping them from
doing so. Obviously in the fee-update case we expect the message to
propagate.

Luckily, since we already "stage" disable-changed updates, we can
check the staged state and use that to set the disabled bit in all
`channel_update` cases.
lightning/src/ln/channelmanager.rs
lightning/src/ln/functional_test_utils.rs
lightning/src/ln/onion_route_tests.rs