Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-16 📝 Original message: > If I'm not mistaken ...
📅 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"
> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/047bf528/attachment.html>;
📝 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"
> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/047bf528/attachment.html>;