Skip to content

routing: undirected node pair based mission control [wip] [don't review]#3353

Closed
joostjager wants to merge 11 commits into
lightningnetwork:masterfrom
joostjager:pair-mc
Closed

routing: undirected node pair based mission control [wip] [don't review]#3353
joostjager wants to merge 11 commits into
lightningnetwork:masterfrom
joostjager:pair-mc

Conversation

@joostjager
Copy link
Copy Markdown
Contributor

@joostjager joostjager commented Jul 29, 2019

Builds onto #1734

Previously mission control tracked failures on a directed node pair basis. This PR changes this to tracking on the level of undirected node pairs. The goal of moving to this coarser-grained level is to reduce the number of required payment attempts without compromising payment reliability.

Deeper analysis of channel-level failures and the way they should be attributed to nodes suggests that there always remains an uncertainty about which of the two endpoints is responsible for the failure. It is therefore appropriate to penalize the pair of nodes as a whole. This penalizes the bad node, while the good node only sees its connection to the bad node penalized. This prevents bad node pairs from being tried in both directions.

An exception is insufficient channel balance (FailTemporaryChannelFailure). Undirected penalization may seem too aggressive in this case, but:

  • It is likely that channels are used for sending payments in a single direction only, away from the sender. Theoretically it is possible to connect to the graph in such a way that a channel may get used both ways, but this seems rare. (Note: this is just about sending. Receiving obviously utilizes channels in the other direction, but for that, path finding is the other party's responsibility.)
  • One could argue that a channel that isn't balanced in one direction, should be avoided in the opposite direction too. It could be a sign that one of the nodes is not properly taking care of the channel (and possibly its other channels).
  • If we are more tolerant to temp. chan. failures, nodes may use that to downgrade their penalty. Example: a node advertises an unreliable public channel. The next peer is offline. By sending back a temp. chan. failure instead of an unknown next peer failure, the peer that is offline isn't penalized. This may be good for the failure-sending node because it may generate incoming traffic in the future.

This PR also prepares for #3256 where a correct, gaming-resistent, set of failure attribution rules is implemented.

@joostjager joostjager force-pushed the pair-mc branch 2 times, most recently from 6906945 to 2dcec12 Compare August 1, 2019 11:30
@joostjager joostjager changed the title routing: node pair based mission control [wip] routing: node pair based mission control Aug 1, 2019
@joostjager joostjager changed the title routing: node pair based mission control routing: node pair based mission control [wip] Aug 2, 2019
Previously mission control tracked failures on a per node, per channel basis.
This commit changes this to tracking on the level of directed node pairs. The goal
of moving to this coarser-grained level is to reduce the number of required
payment attempts without compromising payment reliability.
@joostjager joostjager changed the title routing: node pair based mission control [wip] routing: undirected node pair based mission control [wip] Aug 2, 2019
@joostjager joostjager removed the v0.8.0 label Aug 2, 2019
@joostjager joostjager removed this from the 0.8.0 milestone Aug 2, 2019
@joostjager joostjager changed the title routing: undirected node pair based mission control [wip] routing: undirected node pair based mission control [wip] [no review] Aug 2, 2019
@Roasbeef Roasbeef removed their request for review August 14, 2019 03:00
@joostjager joostjager changed the title routing: undirected node pair based mission control [wip] [no review] routing: undirected node pair based mission control [wip] [don't review] Aug 23, 2019
@joostjager
Copy link
Copy Markdown
Contributor Author

Closing this pr for now. I still think we will eventually be forced to move towards undirected pair-based penalization to be fully gaming resistent, but this will probably not be on the short term. Will keep this pr around for when that moment comes.

@joostjager joostjager closed this Aug 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Improvements to existing features / behaviour routing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants