Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-04 📝 Original message: Hi Thomas, This is a very ...
📅 Original date posted:2022-11-04
📝 Original message:
Hi Thomas,
This is a very interesting proposal that elegantly solves the problem, with
> however a very significant size increase. I can see two ways to keep the
> size small:
> - Each node just adds its hmac in a naive way, without deleting any part
> of the message to relay. You seem to have disqualified this option because
> it increases the size of the relayed message but I think it merits more
> consideration. It is much simpler and the size only grows linearly with the
> length of the route. An intermediate node could try to infer its position
> relative to the failing node (which should not be the recipient) but
> without knowing the original message size (which can easily be randomized
> by the final node), is that really such a problem? It may be but I would
> argue it's a good trade-off.
>
That would definitely make the solution a lot simpler. I think that
increasing the message length still does leak some information, even with
randomization by the final node. For example if you know the minimum
message length including random bytes produced by the final node, and a
routing node sees this length, they must be the second-last hop. I tried to
come up with something that stays within the current privacy guarantees,
but it's fair to question the trade-off.
An advantage of the naive hmac append is also that each node can add a
variable (tlv?) payload. In the fixed size proposal that isn't possible
because nodes need to know exactly how many bytes to sign to cover a number
of downstream hop payloads, and some form of signaling would be required to
add flexibility to that. A variable payload makes it easier to add
extensions later on. It also helps with the randomization of the length.
And intermediate nodes could choose to add some random bytes too in a
otherwise unused tlv record.
> - If we really want to keep the constant size property, as you've
> suggested we could use a low limit on the number of nodes. I would put the
> limit even lower, at 8 or less. We could still use longer routes but we
> would only get hmacs for the first 8 hops and revert to the legacy system
> if the failure happens after the first 8 hops. That way we keep the size
> low and 8 hops should be good enough for 99% of the payments, and even when
> there are more hops we would know that the first 7 hops are clean.
>
Sounds like a useful middle road. Each hop will just shift hmacs and the
ones further than 8 hops away will be shifted out completely. Yes, not bad.
The question that is still unanswered for me is how problematic a full size
fat error of 12 kb would really be. Of course small is better than big, but
wondering if there would be an actual degradation of the ux or other
significant negative effects in practice.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221104/da7bb3e1/attachment.html>;
📝 Original message:
Hi Thomas,
This is a very interesting proposal that elegantly solves the problem, with
> however a very significant size increase. I can see two ways to keep the
> size small:
> - Each node just adds its hmac in a naive way, without deleting any part
> of the message to relay. You seem to have disqualified this option because
> it increases the size of the relayed message but I think it merits more
> consideration. It is much simpler and the size only grows linearly with the
> length of the route. An intermediate node could try to infer its position
> relative to the failing node (which should not be the recipient) but
> without knowing the original message size (which can easily be randomized
> by the final node), is that really such a problem? It may be but I would
> argue it's a good trade-off.
>
That would definitely make the solution a lot simpler. I think that
increasing the message length still does leak some information, even with
randomization by the final node. For example if you know the minimum
message length including random bytes produced by the final node, and a
routing node sees this length, they must be the second-last hop. I tried to
come up with something that stays within the current privacy guarantees,
but it's fair to question the trade-off.
An advantage of the naive hmac append is also that each node can add a
variable (tlv?) payload. In the fixed size proposal that isn't possible
because nodes need to know exactly how many bytes to sign to cover a number
of downstream hop payloads, and some form of signaling would be required to
add flexibility to that. A variable payload makes it easier to add
extensions later on. It also helps with the randomization of the length.
And intermediate nodes could choose to add some random bytes too in a
otherwise unused tlv record.
> - If we really want to keep the constant size property, as you've
> suggested we could use a low limit on the number of nodes. I would put the
> limit even lower, at 8 or less. We could still use longer routes but we
> would only get hmacs for the first 8 hops and revert to the legacy system
> if the failure happens after the first 8 hops. That way we keep the size
> low and 8 hops should be good enough for 99% of the payments, and even when
> there are more hops we would know that the first 7 hops are clean.
>
Sounds like a useful middle road. Each hop will just shift hmacs and the
ones further than 8 hops away will be shifted out completely. Yes, not bad.
The question that is still unanswered for me is how problematic a full size
fat error of 12 kb would really be. Of course small is better than big, but
wondering if there would be an actual degradation of the ux or other
significant negative effects in practice.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221104/da7bb3e1/attachment.html>;