Ariel Lorenzo-Luaces [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-25 📝 Original message: Good morning list I have ...
📅 Original date posted:2019-03-25
📝 Original message:
Good morning list
I have been thinking about how JIT-Routing can allow the network to be more private and scalable than it currently is today. Rene has mentioned that JIT-Routing allows channel balance information to affect pathing decisions without the source node being aware. I would take this further and suggest that JIT-Routing can allow routing over sub-paths that are only visible to neighbour nodes and are entirely hidden from the source node or plublic view.
An intermediate route node could decide for any reason to re-route a payment through any subset of nodes to arrive at the next hop. This is similar to Rene's local AMP idea where friend-of-a-friend nodes are used. But instead this system could allow arbitraryly long paths to the next hop by finding a new sub-route and re-layering the onion packet with the new sub-route prepended.
The same pre-image would be used and this process would be completely invisible to the next hop (original next hop, not the new next hop in the sub-route, I would instead call those the sub-hops).
It's unfortunate that the intermediate nodes along the sub-route would be aware that a sub-route is being attempted because they could observe extra hop packets prepended to the minimum twenty and I don't see of a way to fix this. But maybe it doesn't need fixing since the original twenty encryption layers are arguably private enough.
The sub-route could also employ base AMP since the same pre-image is used. The next hop node would still never even know that a subroute was attempted if no "wait for more payments" flag is added to the per_hop field and we implement the "wait for timeout if HTLC is less than amt_to_forward" rule.
Public nodes could advertise channels which don't actually exist directly but are instead hidden paths that the source node doesn't need to know or care about. The fees advertised for these aggregate-channels would be the aggregate fees expected from the sub-route.
I think the biggest gain from this system is that the network can be more abstract. This abstraction allows all possible subsets of public nodes to be a clique since all subsets of nodes can be maximally connected with aggregate-channels as long as the entire network is well connected.
This new property of the network could allow a source node to select a random privacy-clique and rely on payments to be routed along aggregate-channels without the source node needing to compute or even know the exact sub-routes. Futhermore, the source node could exclusively download and listen to the privacy-clique and ignore the rest of the network structure thus reducing the burden of keeping up to date network information.
Cheers
Ariel Lorenzo-Luaces
On Mar 22, 2019, 4:44 AM, at 4:44 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190325/51dca3aa/attachment.html>;
📝 Original message:
Good morning list
I have been thinking about how JIT-Routing can allow the network to be more private and scalable than it currently is today. Rene has mentioned that JIT-Routing allows channel balance information to affect pathing decisions without the source node being aware. I would take this further and suggest that JIT-Routing can allow routing over sub-paths that are only visible to neighbour nodes and are entirely hidden from the source node or plublic view.
An intermediate route node could decide for any reason to re-route a payment through any subset of nodes to arrive at the next hop. This is similar to Rene's local AMP idea where friend-of-a-friend nodes are used. But instead this system could allow arbitraryly long paths to the next hop by finding a new sub-route and re-layering the onion packet with the new sub-route prepended.
The same pre-image would be used and this process would be completely invisible to the next hop (original next hop, not the new next hop in the sub-route, I would instead call those the sub-hops).
It's unfortunate that the intermediate nodes along the sub-route would be aware that a sub-route is being attempted because they could observe extra hop packets prepended to the minimum twenty and I don't see of a way to fix this. But maybe it doesn't need fixing since the original twenty encryption layers are arguably private enough.
The sub-route could also employ base AMP since the same pre-image is used. The next hop node would still never even know that a subroute was attempted if no "wait for more payments" flag is added to the per_hop field and we implement the "wait for timeout if HTLC is less than amt_to_forward" rule.
Public nodes could advertise channels which don't actually exist directly but are instead hidden paths that the source node doesn't need to know or care about. The fees advertised for these aggregate-channels would be the aggregate fees expected from the sub-route.
I think the biggest gain from this system is that the network can be more abstract. This abstraction allows all possible subsets of public nodes to be a clique since all subsets of nodes can be maximally connected with aggregate-channels as long as the entire network is well connected.
This new property of the network could allow a source node to select a random privacy-clique and rely on payments to be routed along aggregate-channels without the source node needing to compute or even know the exact sub-routes. Futhermore, the source node could exclusively download and listen to the privacy-clique and ignore the rest of the network structure thus reducing the burden of keeping up to date network information.
Cheers
Ariel Lorenzo-Luaces
On Mar 22, 2019, 4:44 AM, at 4:44 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>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 at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190325/51dca3aa/attachment.html>;