From johanth at gmail.com Fri Nov 9 08:07:51 2018 From: johanth at gmail.com (=?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?=) Date: Fri, 9 Nov 2018 09:07:51 +0100 Subject: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes In-Reply-To: References: Message-ID: Neat! I think this is similar to what has been briefly discussed earlier about hybrid packet-switched/circuit-switched payment routing. 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. C must also make sure the detour route stays within the fee limit of course. Cheers, Johan On Fri, Nov 9, 2018 at 7:02 AM ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> wrote: > Good morning list, > > As was discussed directly in summit, we accept link-lvel payment splitting > (scid is not binding), and provisionally accept rendez-vous routing. > > 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. > > For instance, consider this below graph: > > E<---D--->C<---B > ^ / > | / > |L > A > > In the above, B requests a route from B->C->D->E. > > However, C cannot send to D, since the channel direction is saturated in > favor of D. > > 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. > > This can allow re-routing or payment splitting over multiple hops. > > 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. > > 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: