ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-22 📝 Original message: Good morning list, I have ...
📅 Original date posted:2019-03-22
📝 Original message:
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
📝 Original message:
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