offers: require opt_onion_message for incoming invoices too. Changelog-Fixed: offers: require peers for blinded paths to have `option_onion_messages`, due to reports of LND not forwarding our blinded payments correctly.
What the developer wrote
Authored by 21M4TW
offers: require opt_onion_message for incoming invoices too.
Changelog-Fixed: offers: require peers for blinded paths to have `option_onion_messages`, due to reports of LND not forwarding our blinded payments correctly.
What changed, and why it matters
This change tightens which network peers Core Lightning will choose when creating hidden (blinded) payment paths for incoming invoices. Previously it only required support for route blinding; now it also requires support for onion messages. The reason given is that LND nodes were reportedly not forwarding these hidden payments correctly, which could cause payment failures or routing problems. It is a robustness fix rather than a clear-cut security patch, and there is no evidence in the commit of funds being stolen.
Treat as a normal bugfix/interoperability improvement. Review whether the feature-bit check is sufficient or whether additional runtime probing of peer forwarding behavior is needed. Monitor for any follow-up patches or advisories from the Core Lightning team regarding LND blinded-payment forwarding.
Security signals we found
Change in peer-selection logic for blinded payment paths
Interoperability failure with a third-party implementation (LND) cited as motivation
No explicit vulnerability disclosure or CVE referenced in commit
No input validation, memory safety, or cryptographic changes
Small, targeted patch in a single plugin file
Evidence from the diff
In plugins/offers_invreq_hook.c, add_blindedpaths() now calls find_best_peer() with a feature-bit mask of both OPT_ROUTE_BLINDING and OPT_ONION_MESSAGES, instead of only OPT_ROUTE_BLINDING. The goal is to avoid selecting peers that advertise route blinding but do not reliably forward blinded payments because they lack onion-message support. The commit message frames this as a fix for interoperability failures with LND. It is a partial, defensive change: it does not add new validation of the peer’s actual behavior, only its advertised feature bits.
Changed components
plugins/offers_invreq_hook.cBOLT12 offers / invoice request hookBlinded path selection for incoming invoicesInspect captured patch +6 / −1
diff --git a/plugins/offers_invreq_hook.c b/plugins/offers_invreq_hook.c
index d57b7f95..8588ed25 100644
--- a/plugins/offers_invreq_hook.c
+++ b/plugins/offers_invreq_hook.c
@@ -381,7 +381,12 @@ static struct command_result *add_blindedpaths(struct command *cmd,
if (!we_want_blinded_path(cmd->plugin, true))
return create_invoicereq(cmd, ir);
- return find_best_peer(cmd, 1ULL << OPT_ROUTE_BLINDING,
+ /* Technically, this only needs OPT_ROUTE_BLINDING, but we have a report
+ * of this failing with LND nodes, so we require both OPT_ROUTE_BLINDING
+ * *and* OPT_ONION_MESSAGES. This also helps support nodes which provide
+ * us onion messaging. */
+ return find_best_peer(cmd,
+ (1ULL << OPT_ROUTE_BLINDING) | (1ULL << OPT_ONION_MESSAGES),
found_best_peer, ir);
}
Why this scored 35/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.