Good morning list,

I have been thinking of JIT-Routing in the context of unidirectional channels, 
as for example in Eclair Mobile.
Now of course unidirectional-only nodes as in Eclair Mobile cannot forward and 
cannot be intermediate nodes.
However, as I pointed out in previous email, the same JIT-Routing can be used 
also when the node is the ultimate source of the payment.

The original formulation, which requires a separate, completed rebalance, 
before performing a payment, cannot be used in unidirectional mode.
It requires that the channel to be boosted by the rebalance, must first receive 
the value, which is disallowed in unidirectional mode.

However, the Luaces-Pickhardt JIT-Routing, which has a conditional rebalance, 
does not require that the channel receive.
So it seems to me, that the Luaces-Pickhardt JIT-Routing can work with Eclair.

Let us consider the following history:

1.  An Eclair Mobile client creates a 1mBTC channel.
2.  The client successfully pays an unrelated payment of 0.5 mBTC.
3.  The client has to make another payment of 0.6 mBTC, to be passed by this 
channel.
    The client has another channel which can pay out the needed 0.15mBTC 
(additional 0.05mBTC needed for the channel reserve).
4.  The second payment passes.

In the below sequence of states, A is the Eclair Mobile client node, while B is 
the counterparty.

1.  A = 1.0, B = 0.0 ; starting state.
2.  A = 0.5, B = 0.0, A->HTLC->B = 0.5 ; client offers payment in #2 above.
3.  A = 0.5, B = 0.5 ; payee accepts payment.
4.  A = 0.5, B = 0.35, B->HTLC->A = 0.15 ; the rebalance from another channel 
of A, initiated by #3 above.
5.  A = 0.05, B = 0.5, A->HTLC->B = 0.45 ; HTLC polarity reversed by A offering 
an HTLC of 0.6 BTC (the new mechanism proposed by Rene).
6.  A = 0.05, B = 0.95 ; payee accepts payment.

As can be seen from above, A will never have an increase in its money.

Thus, the new Luaces-Pickhardt formulation of JIT-Routing, which requires the 
new "reverse HTLC polarity" mechanism to reuse the same hash as the actual 
payment, should be safe for unidirectional Eclair Mobile nodes.

Let us consider the following sequence of events:

1.  An Eclair Mobile client creates a 1mBTC channel.
2.  The client successfully pays an unrelated payment of 0.5 mBTC.
3.  The client has to make another payment of 0.6 mBTC, to be passed by this 
channel.
    The client has another channel which can pay out the needed 0.15mBTC 
(additional 0.05mBTC needed for the channel reserve).
4.  The second payment fails.

Then the sequence of states is:

1.  A = 1.0, B = 0.0 ; starting state.
2.  A = 0.5, B = 0.0, A->HTLC->B = 0.5 ; client offers payment in #2 above.
3.  A = 0.5, B = 0.5 ; payee accepts payment.
4.  A = 0.5, B = 0.35, B->HTLC->A = 0.15 ; the rebalance from another channel 
of A, initiated by #3 above.
5.  A = 0.05, B = 0.5, A->HTLC->B = 0.45 ; HTLC polarity reversed by A offering 
an HTLC of 0.6 BTC (the new mechanism proposed by Rene).
6.  A = 0.5, B = 0.5 ; payment fails.

Now in the above, the only state that has A own less money than in a later 
state is state 5.
However, even if we are at state 6, and B replays state 5, B cannot claim the 
A->HTLC->B (if it had the hash, it would have claimed the HTLC instead of 
failing it), so it will revert back to A when it times out.
This is the same as existing cases of payment failure in Eclair Mobile, so 
presumably if it has a problem here, it would have a problem in existing Eclair 
Mobile unidirectional channels.

Thus, it should be safe to use the Luaces-Pickhardt JIT-Routing in 
unidirectional-only nodes, even if the original Pickhardt JIT-Routing is unsafe 
for unidirectional-only nodes.

Thus this is a plausible replacement for all forms of multipart payments.
In effect, instead of a multipart payment being decided by the source to the 
destination, we have each hop, including the source, deciding to split or not 
split the payment according to how much fee it has to devote to rebalance 
attempts.

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

Reply via email to