lightningd: stop including channel_update in onion failures - #9569
Draft
daywalker90 wants to merge 1 commit into
Draft
daywalker90 wants to merge 1 commit into
daywalker90 wants to merge 1 commit into
Conversation
daywalker90
marked this pull request as draft
September 24, 2026 19:33
daywalker90
force-pushed
the
fix-lightningd-omit-onion-channel-update
branch
3 times, most recently
from
September 28, 2026 15:16
da2d0aa to
105bfe5
Compare
BOLT ElementsProject#1173 made channel_update optional in UPDATE-flagged failure messages; nodes are expected to transition away from including it because applying onion-embedded updates to the gossip graph is a fingerprinting vulnerability. We already sent len=0 for private channels since 2022-02. For channeld-originated failures, rcvd_htlc_reply has been appending the channel_update *after* a message that already ended with the zero length field (since 222da7f, Oct 2023): receivers parsed len=0 and silently dropped the trailing update, so those failures were already effectively len=0 on the wire. Formalize that: always send len=0 and stop building the update for failures. Remove channel_update_for_error and channel_gossip_update_for_error. That helper also lazily disabled a channel in our own gossip when a forward failed on a disconnected peer. Preserve that behaviour explicitly (BOLT #7 allows disabling on loss of connectivity): disable in channel_gossip_channel_disconnect(), re-enable in channel_gossip_channel_reestablished(), and treat a disconnected peer as disabled in the generic channel_should_enable() callers. Tests that relied on CLN sending the update (test_pay_error_update_fees, test_xpay_error_update_fees, test_xpay_get_error_with_update and renepay's test_fees) now inject a real channel_update through an inline plugin, simulating a peer that still sends one (lnd/eclair); helpers live in tests/utils.py. test_gossip_disable_channels now actually checks the disabled/enabled bit. Regenerate the doc schema examples, since the listsendpays erroronion changes. Receive-side compatibility with len=0 UPDATE failures (oldest safe versions): lnd: temporary_channel_failure only, since ~2017 (lightningnetwork/lnd#216, 98956bc2); other UPDATE codes still fail wire decode LDK: v0.0.115 (Apr 2023, lightningdevkit/rust-lightning#2220, 67ad6c4) for temporary_channel_failure; v0.0.124 (Sep 2024, lightningdevkit/rust-lightning#3083, 24c2468) for all UPDATE codes eclair: v0.11.0 (Dec 2024, ACINQ/eclair#2854, 414f728) CLN: 2020-06-23 (ElementsProject#3781, c100de6) application-logic safety Changelog-Changed: Protocol: onion failure messages no longer include channel_update (BOLT ElementsProject#1173).
daywalker90
force-pushed
the
fix-lightningd-omit-onion-channel-update
branch
from
September 28, 2026 16:30
105bfe5 to
98999f5
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BOLT #1173 made channel_update optional in UPDATE-flagged failure
messages; nodes are expected to transition away from including it
because applying onion-embedded updates to the gossip graph is a
fingerprinting vulnerability.
We already sent len=0 for private channels since 2022-02. For
channeld-originated failures, rcvd_htlc_reply has been appending the
channel_update after a message that already ended with the zero
length field (since 222da7f, Oct 2023): receivers parsed len=0 and
silently dropped the trailing update, so those failures were already
effectively len=0 on the wire. Formalize that: always send len=0
and stop building the update for failures. Remove
channel_update_for_error and channel_gossip_update_for_error.
test_pay_error_update_fees now injects a fee_insufficient failure
with a real channel_update via plugin, since CLN-to-CLN no longer
carries one on the wire.
Receive-side compatibility with len=0 UPDATE failures (oldest safe
versions):
lnd: temporary_channel_failure only, since ~2017
(lightningnetwork/lnd#216, 98956bc2); other UPDATE codes
still fail wire decode
LDK: v0.0.115 (Apr 2023, lightningdevkit/rust-lightning#2220,
67ad6c4) for temporary_channel_failure; v0.0.124 (Sep 2024,
lightningdevkit/rust-lightning#3083, 24c2468) for all
UPDATE codes
eclair: v0.11.0 (Dec 2024, ACINQ/eclair#2854, 414f728)
CLN: 2020-06-23 (#3781, c100de6)
application-logic safety
Changelog-Changed: Protocol: onion failure messages no longer include
channel_update (BOLT #1173).