📅 Original date posted:2018-11-16 📝 Original message: > If I'm not mistaken it'll not be possible for us to have spontaneous > ephemeral key switches while forwarding a payment If this _was_ possible, then it seems that it would allow nodes to create unbounded path lengths (looks to other nodes as a normal packet), possibly by controlling multiple nodes in a route, thereby sidestepping the 20 hop limit all together. This would be undesirable many reasons, the most dire of which being the ability to further amplify null-routing attacks. -- Laolu On Mon, Nov 12, 2018 at 8:06 PM Christian Decker <decker.christian at gmail.com> wrote: > Hi ZmnSCPxj, > > like I mentioned in the other mailing thread we have a minor > complication in order get rendez-vous working. > > If I'm not mistaken it'll not be possible for us to have spontaneous > ephemeral key switches while forwarding a payment. Specifically either > the sender or the recipient have to know the switchover points in their > respective parts of the onion. Otherwise it'll not be possible to cover > the padding in the HMAC, for the same reason that we couldn't meet up > with the same ephemeral key at the rendez-vous point. > > Sorry about not noticing this before. > > Cheers, > Christian > > ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> > writes: > > Good morning list, > > > > Although, packet switching was part of the agenda, we decided, that we > would defer this to some later version of BOLT spec. > > > > Interestingly, some sort of packet switching becomes possible, due to > the below features we did not defer: > > > > 1. Multi-hop onion packets (i.e. s/realm/packettype/) > > 2. Identify "next" by node-id instead of short-channel-id (actually, we > solved this by "short-channel-id is not binding" and next hop is identified > by short-channel-id still). > > 3. Onion ephemeral key switching (required by rendez-vous routing). > > > > ----------- > > > > Suppose we define the below packettype (notice below type number is > even, but I am uncertain how "is OK to be odd", is appropriate for this): > > > > packettype 0: same as current realm 0 > > packettype 2: ephemeral key switch (use ephemeral key in succeeding > 65-byte packet) > > packettype 4: identify next node by node-id on succeeding 65-byte packet > > > > Suppose I were to receive a packettype 0 in an onion. It identifies a > short-channel-id. Now suppose this particular channel has no capacity. As > I showed in thread " Link-level payment splitting via intermediary > rendezvous nodes" > lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001547.html, > it is possible, that I can route it via some other route *composed of > multiple channels*, by using packettype 4 at the end of this route to > connect it to the rest of the onion I receive. > > > > However, in this case, in effect, the short-channel-id simply identifies > the "next" node along this route. > > > > Suppose we also identify a new packettype (packettype 4)) where he > "next" node is identified by its node-id. > > > > Let us make the below scenarios. > > > > 1. Suppose the node-id so identified, I have a channel with this node. > And suppose this channel has capacity. I can send the payment directly to > that node. This is no different from today. > > 2. Suppose the node-id so identified, I have a channel with this node. > But this channel has not capacity. However, I can look for alternate > route. And by using rendez-vous feature "switch ephemeral key" I can > generate a route that is multiple hops, in order to reach the identified > node-id, and connect the rest of the onion to this. This case is same as > if the node is identified by short-channel-id. > > 3. Suppose the node-id so identified, I have not a channel with this > node. However, I can again look for alternate route. Again, by using > "switch ephemeral key" feature, I can generate a route that is multiple > hops, in order to reach the identified node-id, and again connect the rest > of the onion to this. > > > > Now, the case 3 above, can build up packet switching. I might have a > routemap that contains the destination node-id and have an accurate route > through the network, and identify the path directly to the next node. If > not, I could guess/use statistics that one of my peers is likely to know > how to route to that node, and also forward a packettype 4 to the same > node-id to my peer. > > > > This particular packet switching, also allows some uncertainty about the > destination. For instance, even if I wish to pay CJP, actually I make an > onion with packettype 4 Rene, packettype 4 CJP. packettype 0 HMAC=0. Then > I send the above onion (appropriately layered-encrypted) to my direct peer > cdecker, who attempts to make an effort to route to Rene. When Rene > receives it, it sees packettype 4 CJP, and then makes an effort to route to > CJP, who sees packettype 0 HMAC=0 meaning CJP is the recipient. > > > > Further, this is yet another use of the siwtch-ephemeral-key packettype. > > > > Thus: > > > > 1. It allows packet switching > > 2. It increases anonymity set of rendez-vous routing. Node that sees > packettype 2 (switch ephemeral key) does not know, if it is sending to a > packet-switched or link-level payment rerouting, or if it is the > rendes-vous for a deniable payment. > > 3. Mapless Lightning nodes ( > lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001552.html) > could ask a peer to be their pathfinding provider, with some amount of > uncertinaty (it is possible that somebody else sent a packettype 4 to me, > and I selected you as peer who might know the destination; also, the > destination specified may not be the final destination, and I might also be > someone who received a packettype 2 and switched keys before forwarding the > packettype 4 to you). > > 4. It justifies multiple features (support for packettype 2 and > packettype 4) having a single feature bit, again making it difficult to > justify discriminating nodes with this feature bit enabled. > > > > Regards, > > ZmnSCPxj > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > lists.linuxfoundation.org/mailman/listinfo/lightning-dev > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/047bf528/attachment.html>