ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-09 📝 Original message: Good morning list, ...
📅 Original date posted:2018-11-09
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/2a8a45a8/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/2a8a45a8/attachment.html>;