<div>Good morning list,<br></div><div><br></div><div>Although, packet switching was part of the agenda, we decided, that we would defer this to some later version of BOLT spec.<br></div><div><br></div><div>Interestingly, some sort of packet switching becomes possible, due to the below features we did not defer:<br></div><div><br></div><div>1.&nbsp; Multi-hop onion packets (i.e. s/realm/packettype/)<br></div><div>2.&nbsp; 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).<br></div><div>3.&nbsp; Onion ephemeral key switching (required by rendez-vous routing).<br></div><div><br></div><div>-----------<br></div><div><br></div><div>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):<br></div><div><br></div><div>packettype 0: same as current realm 0<br></div><div>packettype 2: ephemeral key switch (use ephemeral key in succeeding 65-byte packet)<br></div><div>packettype 4: identify next node by node-id on succeeding 65-byte packet<br></div><div><br></div><div>Suppose I were to receive a packettype 0 in an onion.&nbsp; It identifies a short-channel-id.&nbsp; Now suppose this particular channel has no capacity.&nbsp; As I showed in thread " Link-level payment splitting via intermediary rendezvous nodes" <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001547.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001547.html</a>, 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.<br></div><div><br></div><div>However, in this case, in effect, the short-channel-id simply identifies the "next" node along this route.<br></div><div><br></div><div>Suppose we also identify a new packettype (packettype 4)) where he "next" node is identified by its node-id.<br></div><div><br></div><div>Let us make the below scenarios.<br></div><div><br></div><div>1.&nbsp; Suppose the node-id so identified, I have a channel with this node.&nbsp; And suppose this channel has capacity.&nbsp; I can send the payment directly to that node.&nbsp; This is no different from today.<br></div><div>2.&nbsp; Suppose the node-id so identified, I have a channel with this node.&nbsp; But this channel has not capacity.&nbsp; However, I can look for alternate route.&nbsp; 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.&nbsp; This case is same as if the node is identified by short-channel-id.<br></div><div>3.&nbsp; Suppose the node-id so identified, I have not a channel with this node.&nbsp; However, I can again look for alternate route.&nbsp; 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.<br></div><div><br></div><div>Now, the case 3 above, can build up packet switching.&nbsp; 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.&nbsp; 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.<br></div><div><br></div><div>This particular packet switching, also allows some uncertainty about the destination.&nbsp; 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.&nbsp; Then I send the above onion (appropriately layered-encrypted) to my direct peer cdecker, who attempts to make an effort to route to Rene.&nbsp; 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.<br></div><div><br></div><div>Further, this is yet another use of the siwtch-ephemeral-key packettype.<br></div><div><br></div><div>Thus:<br></div><div><br></div><div>1.&nbsp; It allows packet switching<br></div><div>2.&nbsp; 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.<br></div><div>3.&nbsp; Mapless Lightning nodes (<a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001552.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001552.html</a>) 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).<br></div><div>4.&nbsp; 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.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>