Good morning all,

I have been thinking further about JIT-Routing.

Particularly, the extension of Rene of the idea from Ariel, to use the same 
payment hash (payment point in the future).

I observe that this effectively creates a sort of "local bass amplifier" 
multipath payment.

>From this idea, also:

> > If a node N offers an htlc to a partner with an amount x from whom the node 
> > already received an htlc y (where y is smaller than x) the nodes must 
> > create a new channel state discarding the old htlc but having a new offer 
> > from N with the amount x-y.

I think we should consider also the possibility of multiple HTLCs "y" above.
For instance, the node may not have enough liquidity in any single channel to 
fulfill the forward, or even augment its channel(s) to that node from a single 
other channel.
However the node may have multiple channels, which in aggregate may have enough 
liquidity to fulfill the forward on the channel(s) to the next node in the 
onion hop.

Implementation-wise, it means:

1.  An outgoing HTLC may need to be associated with multiple incoming HTLCs.
2.  An incoming payment may need to be associated with multiple incoming HTLCs 
(this is a prerequisite of all forms of multipath payment, whether bass 
amplifier or AMP).
3.  An outgoing HTLC may need to be deleted, and all its associated incoming 
HTLCs re-associated to either a new outgoing HTLC or an incoming payment.
3.1.  Multiple such outgoing HTLCs may be deleted in a single step, and all 
their incoming HTLCs will be re-assocaited.

In future, when moving to points/scalars, we need to reveal for each HTLC we 
want to reverse, the total decorrelation secret that makes them each claimable 
by knowledge of the point, of the new HTLC we want to reverse.

---

But first, let us consider, is there a need for JIT-Routing?

I have always held that failure of a single routing attempt is not very 
important, as multiple routing attempts can be performed in sequence, and as 
long as any *single* attempt completes, then the payment succeeds.

However, in a world where some kind of multipart payment (whether bass 
amplifier or AMP) is in frequent use, this changes.
A failure of a single routing attempt may delay the completion of a multipart 
payment, as it means that the source has to retry that branch of the multipart 
payment.
In short, *all* attempts must succeed for a multipart payment to succeed.

It would be nice if we can perform re-routing in order to help multipart 
payments succeed without so much coordination at the source.
This is why Rendezvous Routing is of interest to me, since (naively) it seems 
to me that re-routing is possible with Rendezvous.

However, it seems that JIT-Routing, as modified by Rene based on idea of Ariel, 
does much of what Rendezvous Routing would do for re-routing.
(Rendezvous Routing is still independently of value for privacy of receivers as 
well as moving fee payment from senders to receivers in the "withdrawal from 
custodial wallet" case.)

So I think this JIT-Routing would synergize quite well with bass amplifier and 
AMP.
It effectively allows forwarding nodes to independently split a forwarding 
attempt across multiple paths, without participation of source.

--

Now, we can also consider how to better support JIT-Routing.

I observe that in C-Lightning, the high-level `pay` command provides a 
`maxfeepercent` argument.
C-Lightning considers "fee" here as "anything we send out beyond the face value 
of the invoice".
Currently, in addition to capping fees, it is also used to do small 
overpayments at the receiver.

Now of course an intermediate node will only do JIT-Routing if the cost of 
rebalancing is less than the fee it receives for that forward.
So one thing the source node can do, to help JIT-routing, is to overpay fees at 
each intermediate node a little.
Obviously this overpayment should be capped by the overall `maxfeepercent`.
This improves the probability that it is practical for an intermediate node to 
do JIT-routing.

--

I now put forward the most radical idea of all.

*Multipart payment support is **not necessary** if we have widespread 
JIT-Routing support.*

The motivating problem for proposing AMP, and its improvement bass amplifier, 
is to simplify user experience by not having the user consider the balance of 
each channel.
Instead, ideally the user only cares about the total spendable balance they 
have, without a care about how it is distributed in its channels.
I observe that this is an extremely local condition.

I also observe that a core insight in JIT-Routing is that an intermediate node 
knows more about its local conditions than the source node.

So from the start, the source node can start its thinking as if it is an 
intermediate node.

Thus, if the source node wants to make a payment of 1mBTC, but has 1.5mBTC 
scattered in various channels, it can act as if it is forwarding 1mBTC.
Then it can perform the conditional rebalances in the modified JIT-Routing to 
consolidate the needed liquidity in a single channel.
Then it can initiate the payment, using the modified JIT-Routing "reverse the 
HTLC polarity" feature.

Thus, this fixes the motivating problem for AMP.
But in addition, it provides benefits since it implies that intermediate nodes 
themselves can effectively split payments without coordination with either the 
source or destination.
Thus it provides a mechanism for "local payment splitting", that very well 
removes the need for a higher-level payment-splitting mechanism.

Thank you very much Rene for this idea and Ariel for pushing this idea in this 
direction!

Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to