ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-06 📝 Original message:Good morning Mr. Lee, and ...
📅 Original date posted:2020-10-06
📝 Original message:Good morning Mr. Lee, and list,
> I can then look at the gossiped channels and see the size of the channel between the cut-throat company and the other employee, and from there, guess that this is the bi-weekly salary of that employee.
This can be made an argument against always publishing all channels, so let me propose something.
The key identifying information in an invoice is the routehint and the node ID itself.
There are already many competing proposals by which short-channel-ids in routehints can be obscured.
They are primarily proposed for unpublished channels, but nothing in those proposals prevents them from being used for published channels.
The destination node ID is never explicitly put in the onion, only implied by the short-channel-id in order to save space.
However, the destination node ID *is* used to encrypt the final hop in the onion.
So the receiver node can keep around a small number of throwaway keypairs (or get those by HD) and use a throwaway to sign the invoice, and when it is unable to decode by its normal node ID, try using one of the throwaway keypairs.
With both of the above, what remains is the feerate settings in the invoice.
If the company node gives different feerates per channel, it is still possible to identify which channel is *actually* referred to in the invoice.
What the receiver node can do would be to give a small random increase in feerate, which basically overpays the company node, but obscures as well *which* channel is actually in the invoice.
Regards,
ZmnSCPxj
📝 Original message:Good morning Mr. Lee, and list,
> I can then look at the gossiped channels and see the size of the channel between the cut-throat company and the other employee, and from there, guess that this is the bi-weekly salary of that employee.
This can be made an argument against always publishing all channels, so let me propose something.
The key identifying information in an invoice is the routehint and the node ID itself.
There are already many competing proposals by which short-channel-ids in routehints can be obscured.
They are primarily proposed for unpublished channels, but nothing in those proposals prevents them from being used for published channels.
The destination node ID is never explicitly put in the onion, only implied by the short-channel-id in order to save space.
However, the destination node ID *is* used to encrypt the final hop in the onion.
So the receiver node can keep around a small number of throwaway keypairs (or get those by HD) and use a throwaway to sign the invoice, and when it is unable to decode by its normal node ID, try using one of the throwaway keypairs.
With both of the above, what remains is the feerate settings in the invoice.
If the company node gives different feerates per channel, it is still possible to identify which channel is *actually* referred to in the invoice.
What the receiver node can do would be to give a small random increase in feerate, which basically overpays the company node, but obscures as well *which* channel is actually in the invoice.
Regards,
ZmnSCPxj