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@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" > https://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 > (https://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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
