Fix sender is the introduction node onion messages #2951
Conversation
DefaultMessageRouter will form an OnionMessagePath from a BlindedPath where the sender is the introduction node but only if the sender is announced. If the sender is unannounced, then DefaultMessageRouter will fail. While DefaultMessageRouter will only create a blinded path with an announced introduction node, it may receive one where the introduction node is unannounced. Don't return an error in this case, as the OnionMessenger can advance the blinded path by one hop. This may occur when two nodes have an unannounced channel and one (the offer creator) wants to use it for payments without an intermediary node and without putting its node id in the offer.
Give pub(crate) visibility to some routing test utilities to facilitate testing DefaultMessageRouter in functional tests.
This helps test cases in DefaultMessageRouter that may not be exercised now or in the future.
Use OnionMessenger's public interface in tests whenever possible (i.e., when not using any intermediate_nodes in an OnionMessagePath. This allows us to exercise DefaultMessageRouter, and, in particular that a path can be found for an unannounced sender when its in the introduction node.
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2951 +/- ##
==========================================
+ Coverage 89.11% 89.62% +0.51%
==========================================
Files 117 117
Lines 95029 97762 +2733
Branches 95029 97762 +2733
==========================================
+ Hits 84685 87621 +2936
+ Misses 7856 7692 -164
+ Partials 2488 2449 -39 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
LGTM, although in this context I'd like to (briefly) raise the question again whether we should relax some of the announcement checks for the introduction node to also support BOLT12 between two directly-connected nodes, i.e., something along the lines of tnull@8138bec
If we're really concerned about the privacy leakage, it would be nice to at least expose a config flag allowing to do this, as otherwise it's pretty confusing for users why they could send payments via an intermediate node, but not directly.
|
Can you open an issue? That seems at least marginally unrelated and I'd like to better understand the failure cases and don't want to derail this PR. |
Yes, sorry, this was definitely not my intention. Now tracking here: #2952 |
DefaultMessageRouterwill form anOnionMessagePathfrom aBlindedPathwhere the sender is the introduction node but only if the sender is announced. If the sender is unannounced, thenDefaultMessageRouterwill fail. WhileDefaultMessageRouterwill only create a blinded path with an announced introduction node, it may receive one where the introduction node is unannounced. Don't return an error in this case, as theOnionMessengercan advance the blinded path by one hop.This may occur when two nodes have an unannounced channel and one (the offer creator) wants to use it for payments without an intermediary node and without putting its node id in the offer.