routing: use correct fees by searching backwards #1321

joostjager · 2018-06-04T21:09:27Z

The original findPath implementation can come up with a path that is rejected in newRoute because of "channel graph has insufficient capacity". The reason is that findPath calculates with the same amt all the way, while newRoute takes into account that amt needs to increase with every hop (looking from target back to source).

This change makes findPath use the correct fees and eliminates the possibility that newRoute returns the insufficient capacity error.

In this PR:

Refactor of the path finding unit test to be able add more cases without code duplication (table driven).
Unit test for invalid "channel graph has insufficient capacity" result
Reworked search algorithm to already take into account increasing amounts that need to be send to next hops

joostjager · 2018-06-04T21:12:16Z

@Roasbeef This is work in progress. Can you do an early check and tell me what you think of the general idea?

Roasbeef · 2018-06-04T21:23:26Z

What's this meant to fix? As they say, if it ain't broken, don't fix it...

…

On Mon, Jun 4, 2018, 2:12 PM Joost Jager ***@***.***> wrote: @Roasbeef <https://github.com/Roasbeef> This is work in progress. Can you do a early check and tell me what you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1321 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA87LsfwLbUu6WF5rdkmkOul6iBJ4Dp5ks5t5aKzgaJpZM4UZybJ> .

joostjager · 2018-06-04T21:30:17Z

The original findPath implementation can come up with a path that is rejected in newRoute because of "channel graph has insufficient capacity". The reason is that findPath calculates with the same amt all the way, while newRoute takes into account that amt needs to increase with every hop (looking from target back to source).

This change make findPath use the correct fees and eliminates the possibility that newRoute returns the insufficient capacity error.

Roasbeef · 2018-06-04T23:06:31Z

Gotcha, can you update the PR description, and also the commit messages with this information? Thanks!

In the past this wasn't an issue as each instance kicked off a k-shortest paths routine, so the failing paths would be excluded with a continue. We'll want to first get in the PR which adds fee limits to the path finding routine (say you don't want to pay more than 2% or w/e), as that will affect this implementation.

joostjager · 2018-06-05T22:30:26Z

The fee limit PR as it is now will fail finding a route if the lowest weight route exceeds the max fee. There may be a possible route, but it isn't found because the time/fee weight balance doesn't favor that route.

When the fee limits are merged, I can update this PR to also take the fee limits into account already during findPath. This will lead to less failed route calculations, because the algorithm will continue exploring the graph for higher weight paths that do satisfy the fee limit (which means a higher total time lock).

halseth · 2018-06-06T13:10:33Z

@joostjager can you add a test case that exercise the failure scenario you are trying to fix? Will help understanding the fix :)

joostjager · 2018-06-06T20:07:30Z

Yes, I am working on that.

joostjager · 2018-06-07T12:06:43Z

Quite some changes were needed to add this unit test in a maintainable way. I think trying to work towards a single test graph where many scenarios can be tested is better than setting up different graphs for different test cases.

Also, better visualization of the test graph would be useful. Maybe replace the ascii art with a graphviz generation script.

I see more potential work in the routing area, but will leave the scope of this PR as it is now to keep it manageable. Waiting for #1113

Roasbeef · 2018-06-08T01:08:01Z

Also, better visualization of the test graph would be useful. Maybe replace the ascii art with a graphviz generation script.

The first graph there is just the most basic one, the other graphs themselves are a bit more complex, and agreed that having a rendering of them would make it easier to set up tests, however, it's also pretty straight forward to add additional vertexes/edges to the basic graph at runtime.

joostjager · 2018-06-08T09:49:27Z

Yes indeed, runtime modifications is another option. Only makes it slightly more difficult to reason about what is happening.

The graph jsons contain info that could also be generated runtime. Another idea would be to describe the graph with only the essential values. For example, only aliases and generate the pubkeys (deterministically) in memory when the test runs. It makes the graph description short and can probably be described in go code instead of a separate json. Then, for a special test case like the one described in this issue, it is not much effort to bring up a custom graph.

This contradicts my comment above about working towards a single graph. It depends on the amount of effort required.

joostjager · 2018-06-10T18:29:31Z

Implemented alternative way to describe graph in #1358

halseth

This is an excellent observation! We might not see this routing failures that often, as long as fees are small compared to payment amounts, but totally agree that this is the way we should find paths correctly.

My main concern atm is that the path finding procedure does read a bit convoluted after these changes. Since we are shoehorning the target->source search into the existing block of code, variable names, map indexes, method names, comments and the steps taken now looks a bit off and is hard to follow. Instead we should try to do a bigger rewrite, where it is turned into a proper target->source search, where running amounts are kept as "distances". I don't think the changes should be that large.

You also mentioned that edge weights are a bit off since we are rounding to sat some places instead of using msat. I think it would be worthwhile to fix this, and make sure we are using msat everywhere. How big of a change would this be?

halseth · 2018-06-12T08:28:42Z

routing/pathfind_test.go

+	// the route search was executed backwards.
+	{ target: "elst", paymentAmt: 100000, totalTimeLock: 103, 
+ 	  expectedHops: []expectedHop{
+	       {alias: "phamnuwen", fwdAmount: 100000200, fee: 100010000, timeLock: 102},


I don't get this to add up, maybe I'm missing something.

For a payment of 100,000,000 msat, the expected fees should be:
sophon->elst: 200 msat + 100,000,000 msat * 0/1,000,000 msat = 200 msat
pham->sophon: 10,000 msat + 100,000,200 msat * 1,000,000/1,000,000 msat = 100,010,200 msat

We must send paymentAmt+fees = 100,000,000 msat + 200 msat + 100,010,200 msat = 200,010,400 msat. This should not be able to go through the 120,000,000 msat channel?

Great catch! This is indeed not correct. I hope that conversion to table-driven made this easier to spot. And I think it actually uncovers two existing bugs in newRoute on master:

Fee calculation for a hop does not include the fee that needs to be paid to the next hop

The incoming channel capacity "sanity" check does not include the fee to be paid to the current hop

I also made the expected total amount for a route explicit in the test table. Need to be careful with calculating expected values in unit tests, to prevent duplication of the same (incorrect logic). In this case, the calculation of the expected value was ok, but still.

See c21c980 for fixes.

joostjager · 2018-06-12T11:34:13Z

With regards to you other comments:

Naming and structure: Now that we are on the same page about the general idea of this PR, I will start that kind of finishing work.

One problem that I encountered in making this as simple as possible, is that ChannelEdgePolicy does not contain the "from" node. Therefore I needed to create a reverse lookup table and pass an extra argument to processNode. Do you think it would be good to add this property to ChannelEdgePolicy? Or, because it is currently specific to the backwards search (I think), deal with it in findPath and accept the extra complexity?
I will look at msat vs sat. But channel capacities are an on-chain thing expressed in whole satoshis and I think it is good to keep that explicit by using btcutil.amount. Where did I say that edge weights are a bit off because of rounding? I know that the channel capacity check was not correct because of rounding, but don't think it affects the weights. Edge weights (on master) are indeed a bit off, but for another reason. And that is again that there is no running amount and fees (and therefore weights) are only based on payment amount.

joostjager · 2018-06-12T21:50:57Z

routing/pathfind_test.go

+		name: "three hop with fee carry over", 
+		paymentAmount: 100000,
+		feeRates: []lnwire.MilliSatoshi{10000, 10000, 10000},
+		expectedTotalAmount: 102010,


@halseth This test on master fails. newRoute on master returns 102000 for total amount.

Good catch! Does it make sense to add this test + fix to a separate PR?

Good idea. The fee limit changes are dependent on the previous (backward search) work, but this one is independent.

halseth

I'm really starting to like these changes! 😀

Table driven tests removes a lot of code duplication, and makes it easier to spot errors in the tests. 👏

Most of my comments are about code cleanup and style to make the routing algorithm easier to follow.

halseth · 2018-06-13T09:19:24Z

routing/pathfind_test.go

+
+	for _, testCase := range basicGraphPathFindingTests {
+		t.Run(testCase.target, func(subT *testing.T) {
+			testBasicGraphPathFindingCase(subT, graph, aliases, &testCase)


Awesome refactor! 💯

halseth · 2018-06-13T09:22:03Z

routing/pathfind_test.go

+}
+
+var basicGraphPathFindingTests = []basicGraphPathFindingTestCase{
+	// Basic route with one intermediate hop


nit: period at end of sentences.

halseth · 2018-06-13T09:22:19Z

routing/pathfind_test.go

+			{alias: "songoku", fwdAmount: 100000, fee: 110, timeLock: 101},
+			{alias: "sophon", fwdAmount: 100000, fee: 0, timeLock: 101},
+		}},
+	// Basic direct (one hop) route


nit: add a newline between test cases.

halseth · 2018-06-13T09:26:09Z

routing/testdata/basic_graph.json

+"                         │                              │      └──────┘                 ", 
+"                         │                              │         ▲                     ",  
+"                         │                              │         | 100k sat            ",  
+"                         │                              │         |                     ",   


nit: you forgot to add "▼" to the new channels 😛

halseth · 2018-06-13T09:27:28Z

rpcserver.go

@@ -3188,7 +3188,8 @@ func unmarshallRoute(rpcroute *lnrpc.Route,

 		routingHop := &routing.ChannelHop{
 			ChannelEdgePolicy: channelEdgePolicy,
-			Capacity:          btcutil.Amount(hop.ChanCapacity),
+			Bandwidth:         lnwire.NewMSatFromSatoshis(
+				btcutil.Amount(hop.ChanCapacity)),


hm, something weird about the formatting here?

halseth · 2018-06-13T11:25:59Z

routing/pathfind.go

+		if tempDist < distance[fromVertex].dist && bandwidth >= amountToSend &&
+			amountToSend >= edge.MinHTLC && edge.TimeLockDelta != 0 {
+
+			amountToReceive := amountToSend + fee


Add a comment explaining this calculation :)

Comment added.

halseth · 2018-06-13T11:30:51Z

routing/pathfind.go

-	// distance map with a distance of 0. This indicates our starting
-	// point in the graph traversal.
-	sourceVertex := Vertex(sourceNode.PubKeyBytes)
-	distance[sourceVertex] = nodeWithDist{


we must still make sure the source is added to the map with dist infinity

The source node is already added in the graph.ForEachNode loop further up. The reason it was explictly added here previously, was to set (overwrite) the distance to 0. But because of backwards searching, this is no longer necessary.

Hmm, we are then assuming that the source node will always be returned from graph.ForEachNode. That's a reasonable assumption to make, but I think it won't hurt to also handle the case where it's not.

Maybe that's fine anyway, because we will just finish our path finding, and then discover no path was found to the source node? Or do we depend on it being in the map?

It is always returned. If you look at

lnd/channeldb/graph.go

Line 276 in b5a2288

node, err := fetchLightningNode(nodes, selfPub)

it can be seen that even channeldb itself relies on the source pubkey being present in the node bucket.

If these semantics would change at some point, path finding would never find a path anymore. So the bug that would be created, will quickly surface.

I'd prefer not to add a check anyway, because it can only elicit questions from developer about the reason there might be for this to happen.

Comment added.

Reasonable, agreed!

halseth · 2018-06-13T11:35:08Z

routing/pathfind.go

 		// further our graph traversal.
 		pivot := Vertex(bestNode.PubKeyBytes)
 		err := bestNode.ForEachChannel(tx, func(tx *bolt.Tx,
 			edgeInfo *channeldb.ChannelEdgeInfo,
-			outEdge, _ *channeldb.ChannelEdgePolicy) error {
+			outEdge *channeldb.ChannelEdgePolicy, inEdge *channeldb.ChannelEdgePolicy) error {


can be written outEdge, inEdge *channeldb.ChannelEdgePolicy

halseth · 2018-06-13T11:42:30Z

routing/pathfind.go

-		pathEdges = append(pathEdges, prev[prevNode].edge)
-
-		prevNode = Vertex(prev[prevNode].prevNode)
+	// If the potential route is below the max hop limit, then we'll use


nit: This comment should not mention the hop limit, as that is first checked below.

Fixed. Probably something that was moved earlier.

halseth · 2018-06-13T11:46:03Z

routing/pathfind_test.go

@@ -616,6 +638,163 @@ func TestKShortestPathFinding(t *testing.T) {
 	assertExpectedPath(t, paths[1], "roasbeef", "satoshi", "luoji")
 }

+func TestNewRoute(t *testing.T) {


the newRoute changes should be removed, since they were separated into a new PR.

This PR is based upon the other PR, because I need the TestNewRoute function. Those changes are shown here to because the base of this PR is master. But really, all commits in this PR are stacked on top of the newRoute bugfix. Please let me know how to do this better.

halseth

This is getting reallly close now, most comments about style, and removal of the (now) unnecessary DB migration.

Very excited to get this in!

halseth · 2018-07-30T07:10:51Z

autopilot/graph.go

@@ -85,6 +85,11 @@ func (d dbNode) ForEachChannel(cb func(ChannelEdge) error) error {
 	return d.node.ForEachChannel(d.tx, func(tx *bolt.Tx,
 		ei *channeldb.ChannelEdgeInfo, ep, _ *channeldb.ChannelEdgePolicy) error {

+		// Skip channels for which no outgoing edge policy is available.
+		if ep == nil {


Looking at where it is used, I think it should only need to know whether there's a channel or not between the nodes, not if the policy is known or not.

So in this case, we could extract both pubkeys from the ei, and compare them to the current dbNode to figure out the key of the peer.

halseth · 2018-07-30T07:12:35Z

channeldb/graph.go

+
+			if err := putChanEdgePolicyUnknown(edges, edge.ChannelID, 
+				key[:]); err != nil {
+


To separate long lines like this, the first thing would be

err := putCha... if err != nil { return err }

halseth · 2018-07-30T07:13:10Z

channeldb/graph.go

+// connecting node. If the callback returns an error, then the iteration is
+// halted with the error propagated back up to the caller.
+//
+// Unknown policies are passed into the callback as nil values.


halseth · 2018-07-30T07:15:41Z

channeldb/graph.go

-			incomingNode := toEdgePolicy.Node.PubKeyBytes[:]
-			fromEdgePolicy, err := fetchChanEdgePolicy(
-				edges, chanID, incomingNode, nodes,
+			// Using the incoming node, the incoming edge policy


Excellent! 😀

halseth · 2018-07-30T07:16:24Z

channeldb/graph.go

@@ -2014,6 +2041,16 @@ func (c *ChannelEdgeInfo) BitcoinKey2() (*btcec.PublicKey, error) {
 	return key, nil
 }

+// OtherNodeKeyBytes returns the node key bytes of the other end of
+// the channel.
+func (c *ChannelEdgeInfo) OtherNodeKeyBytes(thisNodeKey []byte) [33]byte {


halseth · 2018-07-30T07:44:46Z

routing/pathfind.go


-	return pureFee + timeLockPenalty
+	return int64(fee) + timeLockPenalty
 }

 // findPath attempts to find a path from the source node within the


Could add to the method description here that we search backwards now, and why 😄

halseth · 2018-07-30T07:49:19Z

routing/pathfind.go

-	// that are not known to us yet in the distance map.
-	for vertex := range additionalEdges {
+	additionalEdgesWithSrc := make(map[Vertex][]*edgePolicyWithSource)
+	for vertex, outgoingEdgePolicies := range additionalEdges {


Yeah, we probably shouldn't change ChannelEdgePolicy, as it directly maps to the wire messages being sent on the network. I'm fine with keeping this as is now, as I agree that this could be considered an implementation detail the caller shouldn't need to worry about.

halseth · 2018-07-30T07:54:21Z

routing/pathfind.go

+
+		// If the estimated band width of the channel edge is not able
+		// to carry the amount that needs to be send, return.
+		if bandwidth < amountToSend {


This could be checked earlier in processEdge?

halseth · 2018-07-30T07:55:07Z

routing/pathfind.go

+
+		// If the amountToSend is less than the minimum required amount,
+		// return.
+		if amountToSend < edge.MinHTLC {


same, could check earlier for an early return.

halseth · 2018-07-30T07:59:49Z

routing/pathfind_test.go

-	  expectedHops: []expectedHop{
-		{alias: "luoji", fwdAmount: 100000, fee: 0, timeLock: 101},
-	}},
+	// Basic route with one intermediate hop.


Looks good now!

joostjager · 2018-07-30T10:14:37Z

autopilot/graph.go

+		if err != nil {
+			return err
+		}
+


Ok, semantics change compared to master, but I think it is better like this. As you say, policies are not required for the auto pilot.

But the change become bigger than I liked, because of the lookup of LightningNode which was previously done inside LightningNode.ForEachChannel. Needed to gain access to db somehow.

I kept the changes apart in commit d258efe. Maybe there is a cleaner way?

Hm, yeah this might not even work, since calling FetchLightningNode inside an already open DB transaction might cause problems.

I don't see an immediate way of achieving what we want without doing more changes to the database to make it possible to fetch the node without the edge policy. I'm okay with keeping your original implementation (skipping a nil-policy) with an added TODO saying that we ideally should support the case where the policy is nil.

Ok, pulling out that commit.

joostjager · 2018-07-30T12:26:37Z

@halseth I think we have resolved all points now.

halseth · 2018-07-30T12:09:36Z

channeldb/graph.go

+	// with the node's public key and sends with the compact edge ID. 
+	// For each chanID, there will be two entries within the bucket, as the
+	// graph is directed: nodes may have different policies w.r.t to fees 
+	// for their respective directions. An unknown policy is represented as


halseth · 2018-07-30T12:17:09Z

channeldb/graph.go

 	//
-	// maps: pubKey || edgeID -> edge policy for node
+	// maps: pubKey || chanID -> channel edge policy for node


For some reason I thought edgePolicies were stored in a bucket in addition to this. So I can understand why we were talking about different things now.. 😛 The final solution you came up with looks good to me though 😄

Ah, that explains it 😄

halseth · 2018-07-30T12:20:06Z

channeldb/graph.go

-	if edgeBytes := edges.Get(edgeKey[:]); edgeBytes != nil {
+	// An unknown policy value does not have a update time recorded, so
+	// it also does not need to be removed.
+	if edgeBytes := edges.Get(edgeKey[:]); 


Would be even safer to check !bytes.Equals(edgeBytes, unknownPolicy) (unknown policy wouldn't be required to be empty slice), where unknownPolicy is a constant defined as the empty slice.

halseth · 2018-07-30T12:22:11Z

channeldb/graph.go

@@ -2836,6 +2890,11 @@ func fetchChanEdgePolicy(edges *bolt.Bucket, chanID []byte,
 		return nil, ErrEdgeNotFound
 	}

+	// No need to deserialize unknown policy.
+	if len(edgeBytes) == 0 {


again, compare agains unknownPolicy constant.

When this is addressed this PR can be squashed and rebased, and I think it should be good 👍

halseth · 2018-07-30T12:24:47Z

channeldb/migrations.go

+		_, err := fetchChanEdgePolicy(edges, 
+			channelID[:], keyBytes[:], nodes)
+
+		if err == ErrEdgeNotFound {


In case of other error we must return it such that the migration can be aborted.

Good one, fixed.

halseth · 2018-07-31T10:35:43Z

channeldb/migrations.go

+func migrateEdgePolicies(tx *bolt.Tx) error {
+	nodes := tx.Bucket(nodeBucket)
+	if nodes == nil {
+		return ErrGraphNotFound


I think we can safely return nil if the buckets are not found? We are probably then trying to migrate an empty DB.

Yes, indeed.

halseth · 2018-07-31T10:36:01Z

channeldb/migrations.go

+			log.Tracef("Adding unknown edge policy present for node %x, channel %v", 
+				keyBytes, channelId)
+
+			putChanEdgePolicyUnknown(edges, channelId, keyBytes)


error must be handled here also.

Good point, added.

joostjager · 2018-08-01T10:11:40Z

unknownPolicy constant restored as empty slice and rebased.

joostjager · 2018-08-04T13:40:00Z

Rebased after gofmt commits on master

The commit ensures that for every channel, there will always be two entries in the edges bucket. If the policy from one or both ends of the channel is unknown, it is marked as such. This allows efficient lookup of incoming edges. This is required for backwards payment path finding.

joostjager · 2018-08-05T09:32:12Z

Amended all commits with gofmt

halseth

This change looks mostly LGTM now, awesome work! Should get review from someone else before merge, however.

halseth · 2018-08-06T10:44:38Z

channeldb/graph.go

-	if edgeBytes := edges.Get(edgeKey[:]); edgeBytes != nil {
+	// An unknown policy value does not have a update time recorded, so
+	// it also does not need to be removed.
+	if edgeBytes := edges.Get(edgeKey[:]); edgeBytes != nil && !bytes.Equal(edgeBytes[:], unknownPolicy) {


split over two lines

halseth · 2018-08-06T10:53:00Z

channeldb/graph.go

+
+			var incomingPolicy, outgoingPolicy *ChannelEdgePolicy
+
+			if policy1 != nil {


I know I suggested earlier to do it this way, but I didn't anticipate we would need these switch statements 😛

Could we instead do:

chanID := nodeEdge[33:] edgeInfo, err := fetchChanEdgeInfo(edgeIndex, chanID) if err != nil { return err } toEdgePolicy, err := fetchChanEdgePolicy( edges, chanID, nodeNub, nodes, ) ... otherNode, err := edgeInfo.OtherNodeKeyBytes(nodePub) if err != nil { return err } toEdgePolicy, err := fetchChanEdgePolicy( edges, chanID, otherNode, nodes, )

(or just deserialize the toEdgePolicy directly if first checked if not unknownPolicy, as you suggested initially)

Yes, this is better indeed than the ugly switches. Glad to hear to my initial creation was not so bad 😉 but I agree with you that readability and not duplicating code is important too.

halseth · 2018-08-06T10:53:55Z

channeldb/graph.go

@@ -2899,6 +2943,20 @@ func putChanEdgePolicy(edges *bolt.Bucket, edge *ChannelEdgePolicy, from, to []b
 	return edges.Put(edgeKey[:], b.Bytes()[:])
 }

+// putChanEdgePolicyUnknown marks the edge policy as unknown in the edges bucket.


nit: both lines a bit long

joostjager · 2018-08-07T18:53:17Z

Review comments addressed

Roasbeef

Excellent work! This PR includes quite a few nice clean ups w.r. to the testing code, and fixes a few legacy bugs related to incorrectly applying the fee limit during path finding.

The PR looks mostly good to me, however I noticed that in one area, it'll create a DB transaction inside of an existing one. Instead, it should carry over the same transaction as in the past, this has lead to deadlocks, and also creating a new transaction is an expensive activity. This is my only major comment in this PR.

I'll also move to start running this on a few nodes doing path finding, just to see if anything weird pops up.

Roasbeef · 2018-08-09T03:52:24Z

channeldb/graph.go

-			if err != nil && err != ErrEdgeNotFound &&
-				err != ErrGraphNodeNotFound {
-				return err
+			policy1, policy2, err := fetchChanEdgePolicies(edgeIndex,


Forgetting to check the error here.

We already have the edge info here, it's the value of the cursor seek, why fetch it again? Not blocking, more of a nit that code seems to have been unnecessarily changed.

Initially it was unchanged. I modified it after discussion with @halseth for readability (over performance), see comments above.

Roasbeef · 2018-08-09T04:01:02Z

channeldb/graph.go

@@ -2824,6 +2864,20 @@ func putChanEdgePolicy(edges *bolt.Bucket, edge *ChannelEdgePolicy, from, to []b
 	return edges.Put(edgeKey[:], b.Bytes()[:])
 }

+// putChanEdgePolicyUnknown marks the edge policy as unknown in the edges bucket.
+func putChanEdgePolicyUnknown(edges *bolt.Bucket, channelID uint64, from []byte) error {


Roasbeef · 2018-08-09T05:02:51Z

routing/pathfind_test.go

+
+	for _, testCase := range basicGraphPathFindingTests {
+		t.Run(testCase.target, func(subT *testing.T) {
+			testBasicGraphPathFindingCase(subT, graph, aliases, &testCase)


Roasbeef · 2018-08-10T00:33:03Z

channeldb/graph.go

-					return fmt.Errorf("Unexpected node in policy")
-				}
-			}
+			incomingPolicy, err := fetchChanEdgePolicy(


Ignoring the error here and above.

Roasbeef · 2018-08-10T01:01:11Z

routing/pathfind.go

+		// If the edge has no time lock delta, the payment will always
+		// fail, so return.
+
+		// TODO(joostjager): Is this really true? Can't it be that


Well, it's just a dumb value to set, as it more or less guarantees that the node won't be able to properly handle a timed out HTLC, and will likely lose money.

Roasbeef · 2018-08-10T01:09:10Z

routing/pathfind.go

@@ -684,13 +798,6 @@ func findPath(tx *bolt.Tx, graph *channeldb.ChannelGraph,
 			"too many hops")
 	}

-	// As our traversal of the prev map above walked backwards from the


Yay, no more reversal!

Roasbeef · 2018-08-10T01:13:08Z

routing/pathfind.go

+				return err
+			}
+
+			// Lookup the full node details in order to be able to


This looks a bit dangerous and could possibly lead to a deadlock: we're creating a new DB transaction inside of an existing db transaction.

bolt allow concurrent readers, but I'm weary of making additional transactions inside of callbacks like this. We started to expose the transaction object in these methods to safely allow nested calls without creating new database transactions. We could possibly add methods onto the EdgeInfo struct, which accepts the existing transaction (or if nil creates a new one), in order to allow the caller to fetch the full LightningNode struct without creating a new database transaction.

Roasbeef · 2018-08-10T03:11:50Z

Actually, I'll merge this as is, and then add a follow up commit to avoid the double DB transaction issue. Thanks for bearing with us through this review process! The final PR really turned out well!

Roasbeef · 2018-08-10T03:50:30Z

Committed as 29b6bae!

joostjager · 2018-08-10T05:59:19Z

I am happy that this one has been merged now. Will work on the follow-up.

joostjager · 2018-08-10T06:26:17Z

Ah, I see you fixed the open issues yourselves. I was thinking of adding a tx parameter to FetchLightningNode, but this works too of course.

joostjager force-pushed the routing branch from dec110e to 9fd1b88 Compare June 4, 2018 21:21

joostjager force-pushed the routing branch 2 times, most recently from ecbbfd0 to 77f11f5 Compare June 7, 2018 11:59

joostjager force-pushed the routing branch 2 times, most recently from 77f11f5 to 8b8a7eb Compare June 7, 2018 13:19

joostjager mentioned this pull request Jun 10, 2018

routing: routing may come up with suboptimal routes (weight function) #1358

Merged

halseth suggested changes Jun 12, 2018

View reviewed changes

joostjager force-pushed the routing branch 3 times, most recently from 39f1d23 to eee132a Compare June 12, 2018 12:29

joostjager commented Jun 12, 2018

View reviewed changes

joostjager force-pushed the routing branch 5 times, most recently from 285f3f9 to 76098dd Compare June 13, 2018 10:09

halseth suggested changes Jun 13, 2018

View reviewed changes

joostjager force-pushed the routing branch from 76098dd to fde56a7 Compare June 14, 2018 07:51

joostjager force-pushed the routing branch 3 times, most recently from d60dff0 to 7e384c6 Compare July 28, 2018 12:41

halseth suggested changes Jul 30, 2018

View reviewed changes

joostjager commented Jul 30, 2018

View reviewed changes

joostjager force-pushed the routing branch from dd4f26f to 763a424 Compare July 30, 2018 12:14

halseth suggested changes Jul 30, 2018

View reviewed changes

halseth suggested changes Jul 31, 2018

View reviewed changes

joostjager mentioned this pull request Jul 31, 2018

Update pathfind.go to allow sending to self #1652

Closed

joostjager force-pushed the routing branch from c4eba2c to 5588c18 Compare August 1, 2018 10:08

joostjager force-pushed the routing branch from 5588c18 to 253b11a Compare August 4, 2018 13:35

joostjager added 4 commits August 5, 2018 11:21

routing: path finding test refactored

650270b

routing: backward searching

6499381

routing: convert fee limit test to table-driven

508401a

joostjager force-pushed the routing branch from 253b11a to 508401a Compare August 5, 2018 09:30

halseth reviewed Aug 6, 2018

View reviewed changes

fixup! channeldb: store unknown policies in database

863d2bb

halseth mentioned this pull request Aug 9, 2018

Added feature route to self #1685

Closed

Roasbeef requested changes Aug 10, 2018

View reviewed changes

Roasbeef closed this Aug 10, 2018


		if err := putChanEdgePolicyUnknown(edges, edge.ChannelID,
		key[:]); err != nil {


		var incomingPolicy, outgoingPolicy *ChannelEdgePolicy

		if policy1 != nil {

routing: use correct fees by searching backwards #1321

routing: use correct fees by searching backwards #1321

Conversation

joostjager commented Jun 4, 2018 • edited

joostjager commented Jun 4, 2018 • edited

Roasbeef commented Jun 4, 2018 via email

joostjager commented Jun 4, 2018

Roasbeef commented Jun 4, 2018

joostjager commented Jun 5, 2018

halseth commented Jun 6, 2018

joostjager commented Jun 6, 2018

joostjager commented Jun 7, 2018

Roasbeef commented Jun 8, 2018

joostjager commented Jun 8, 2018

joostjager commented Jun 10, 2018

halseth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager commented Jun 12, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

halseth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

halseth Jun 13, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

halseth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager commented Jul 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager commented Jun 4, 2018 •

edited

joostjager commented Jun 4, 2018 •

edited

joostjager commented Jun 12, 2018 •

edited

halseth Jun 13, 2018 •

edited