Prefer direct routes when paying.

[ZmnSCPxj]

Closes: #2168

[rustyrussell]

I'm in the process of moving pay out to a plugin, but I think that we should be addressing this by fixing routing. Perhaps our fuzz is too large or default risk is too low and it's overriding the natural bias towards direct channels?

[renepickhardt]

While I like this improvement and while I think the feature should be part of clightning I thought the entire pay and route handling was supposed to be externalized to a pay plugin? Would still ACK this. Could not find any suspecious looking code

[renepickhardt]

Oh sorry had this tab open in my browser and oversaw the comment by @rustyrussell

[ZmnSCPxj]

Perhaps our fuzz is too large or default risk is too low and it's overriding the natural bias towards direct channels?

The intent is to try direct channels first because:

1. They do not leak our payment information to anyone other than the payee (who has to know our payment information anyway).
2. The direct route is more likely to not stall, especially as we already have stall mitigation, but non-recent-c-lightning intermediate nodes may or may not.
3. Users are weirded out that we do not use direct channel.

Fuzz parameter is used to give widely divergent random routes to prevent the same third parties (those trying to bias us towards them by greatly reducing their fees and connecting to as many nodes as they can) from being used over and over.

Thus I think we should have a separate preference for a direct channel if possible, but retain high fuzz.

An alternative is: Provide local channel balance information and etc to gossipd, and have getroute return the direct route if it is viable. This ties in to other intended future changes to routefinding I describe here for bass amplifier payments: https://lists.ozlabs.org/pipermail/c-lightning/2018-December/000095.html ; routing will have to keep track of assumed channel balance (for non-local channels) and actual channel balance (for local channels) in order to be able to give a decision about how to much a route can transport, to support bass amplifier splitting. Then we would also have to implement "usedness" tracking (i.e. avoid using a channel we used recently in a path), which is needed to get multiple different routes for bass amplifier splitting.

[ZmnSCPxj]

Perhaps our fuzz is too large or default risk is too low and it's overriding the natural bias towards direct channels?

The bias seems to be very tiny:

lightning/gossipd/routing.c

Lines 359 to 364 in d7e233e

	/* Risk of passing through this channel. We insert a tiny constant here
	* in order to prefer shorter routes, all things equal. */
	static u64 risk_fee(u64 amount, u32 delay, double riskfactor)
	{
	return 1 + amount * delay * riskfactor;
	}

I note also that connection_fee is the below:

lightning/gossipd/routing.c

Lines 347 to 357 in d7e233e

	static u64 connection_fee(const struct half_chan *c, u64 msatoshi)
	{
	u64 fee;
	assert(msatoshi < MAX_MSATOSHI);
	assert(c->proportional_fee < MAX_PROPORTIONAL_FEE);
	fee = (c->proportional_fee * msatoshi) / 1000000;
	/* This can't overflow: c->base_fee is a u32 */
	return c->base_fee + fee;
	}

The key point here is that connection_fee still applies the fee even if this half-channel is directly from the source.

But the first hop from the source is always 0-fee.

So I propose to modify it so that if the half-chan is from the source of the route, connecftion_fee returns 0.

Thus, the direct route will have a very strong total cost compared to other routes, and fuzz will not affect direct routes (since it is a multiplier on the fee, and anything times 0 is 0).

I shall try to find time to make this alternate solution.

[cdecker]

Since @rustyrussell is planning to write the pay plugin, and this is essentially that logic I'll let him decide whether to apply or not 😉

[ZmnSCPxj]

If the modification to getroute I described is taken instead, that should simplify the future pay plugin --- it would be a simple getroute-sendpay loop.

Regarding plugins, can plugins receive multiple command requests even while an existing command response has not been returned yet?
I worry, the case where multiple pay command is performed at same time.
In current payalgo.c, multiple pay command is perfectly fine and can be performed at same time (payalgo.c allocates multiple objects to handle multiple payments).
I worry if pay plugin is written in Python or similar, that only a single pay command can occur at one time.
It may make the pay plugin inappropriate for some applications, such as evil trust-requiring centralized custodial Lightning wallets.

It would be trivial to DoS such a service if multiple pay command cannot execute at same time.
I would simply create my own LN node that always fails to accept payments, then have it generate an invoice with long final CLTV delta.
Then I would use such a service to pay that invoice, and have it prevent other users from paying also.

---

P.S. The plugin system can indeed pass multiple commands to the same plugin simultaneously. However, it seems the guilt/pay-plugin branch has no pay plugin I can find easily, so I hope to review the future pay plugin to check that it will support multiple parallel payments.

[ZmnSCPxj]

Closes #2168

[cdecker]

Closes #2168

Github seems to only auto-close if these statements are in the first message in the thread.