<div dir="ltr">Neat! I think this is similar to what has been briefly discussed earlier about hybrid packet-switched/circuit-switched payment routing.<div><br></div><div>B doesn't have to care about how the payment gets from C to D, but she knows it must go through D, keeping privacy intact. This would be exactly equivalent to how TOR works today I would think.</div><div><br></div><div>C must also make sure the detour route stays within the fee limit of course.</div><div><br></div><div>Cheers,</div><div>Johan</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 9, 2018 at 7:02 AM ZmnSCPxj via Lightning-dev <<a href="mailto:lightning-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning list,<br></div><div><br></div><div>As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.<br></div><div><br></div><div>It strikes me, that even if your node has only a single channel to the next node (c-lightning), it is possible, to still perform link-level payment splitting/re-routing.<br></div><div><br></div><div>For instance, consider this below graph:<br></div><div><br></div><div> E<---D--->C<---B<br></div><div> ^ /<br></div><div> | /<br></div><div> |L<br></div><div> A<br></div><div><br></div><div>In the above, B requests a route from B->C->D->E.<br></div><div><br></div><div>However, C cannot send to D, since the channel direction is saturated in favor of D.<br></div><div><br></div><div>Alternately, C can route to D via A instead. It holds the (encrypted) route from D to E. It can take that sub-route and treat it as a partial route-to-payee under rendez-vous routing, as long as node A supports rendez-vous routing.<br></div><div><br></div><div>This can allow re-routing or payment splitting over multiple hops.<br></div><div><br></div><div>Even though C does not know the number of remaining hops between D and the destination, its alternative is to earn nothing anyway as its only alternative is to fail the routing. At least with this, there is a chance it can succeed to send the payment to the final destination.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>