From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
Date: Tue, 06 Oct 2020 04:10:52 +0000 [thread overview]
Message-ID: <Ad0QZxXDn_2zj8-WAYKLKHGDvd3UVmZvt68HdLoMzahzsv9jXAi-WxcFSTq_HUDWUkVDCr72LlzM7fR_fAU2fPjzO0aBSAV2czeBljubt1Q=@protonmail.com> (raw)
In-Reply-To: <-9eIH0M9XOXDIGvFaSHljGrkKfd_N7q9POTV4wzobjSGljNwE3snOP2-jPE4Nh1IPovo8tTuQz_nSqgpLWI2hrD5_UGonfn-sjNo7oIbVXU=@protonmail.com>
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
next prev parent reply other threads:[~2020-10-06 4:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-03 5:21 Mr. Lee Chiffre
2020-10-03 22:24 ` ZmnSCPxj
2020-10-05 2:41 ` ZmnSCPxj
2020-10-06 4:10 ` ZmnSCPxj [this message]
2020-10-04 3:45 ` ZmnSCPxj
2020-10-04 14:07 ` Thomas Hartman
2020-10-04 14:24 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Ad0QZxXDn_2zj8-WAYKLKHGDvd3UVmZvt68HdLoMzahzsv9jXAi-WxcFSTq_HUDWUkVDCr72LlzM7fR_fAU2fPjzO0aBSAV2czeBljubt1Q=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox