* [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
@ 2020-10-03 5:21 Mr. Lee Chiffre
2020-10-03 22:24 ` ZmnSCPxj
2020-10-04 3:45 ` ZmnSCPxj
0 siblings, 2 replies; 7+ messages in thread
From: Mr. Lee Chiffre @ 2020-10-03 5:21 UTC (permalink / raw)
To: bitcoin-dev
Lets pretend that I have a company. I'll call it cut throat industries. We
are a box cutter testing firm. HR pays the employees biweekly Fridays. In
the current way. Cut throat industries pays a single transaction with the
company's treasury as the input and each employee payroll as an output.
There is no address reuse because HR has a xpub provided by each employee
for their payroll wallet. I have 120 employees.
The problem
The concern is the competition of my precious company and employees seeing
our worth and amount in our treasury account. This also exposes how many
employees we have and an idea of what the average payroll is. One of my
employees is Frank. Frank gets paid then a couple days later he buys some
random thing that should not be talked about from a coworker. The coworker
can observe Franks input and know what Frank makes. There is another time
where cut throat industries is in a temporary financial clamp down. To
save money my company is not giving bonuses for the rest of the fiscal
year. But one employee of mine has done a very good job at cutting and I
was afraid he was going to leave my agency if I did not make an exception
for him. So I gave him a raise but not others. Employees notice that one
of the 120 biweekly outputs is higher than usual. So they know someone got
a raise.
Problem summary
I am paranoid because I run a company with my finances transparent to my
competition and my employees. And my employees are starting to get
concerned because their income is transparent to everyone also. These
employees are dangerous and professional cutters. I don't want to upset
them. What can I do to use bitcoin with privacy to eliminate these
concerns? Lightning network is not much an option because they do not have
inbound balance to get paid. I cannot front up funds of my own to give
them inbound balance because it would consume all of my treasury to lock
up funds. So it seems that I have to do payroll on chain. What do I do?
--
lee.chiffre@secmail•pro
PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
2020-10-03 5:21 [bitcoin-dev] A thought experiment on bitcoin for payroll privacy Mr. Lee Chiffre
@ 2020-10-03 22:24 ` ZmnSCPxj
2020-10-05 2:41 ` ZmnSCPxj
2020-10-04 3:45 ` ZmnSCPxj
1 sibling, 1 reply; 7+ messages in thread
From: ZmnSCPxj @ 2020-10-03 22:24 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion
Good morning Mr. Lee,
> Lightning network is not much an option because they do not have
> inbound balance to get paid.
Why not?
Your company can open a channel with each employee that has insufficient inbound liquidity.
The employee is incentivized to reveal their node to your company so you can open a channel to them, since otherwise they would be unable to receive their salary.
Your alternative is as you say: openly-visible salaries and throat-cutters who might decide to cut your throat.
Let us say your company receives its income stream over Lightning.
Let us say you hire a new throat-cutter, with a bi-weekly salary of 0.042 BTC.
You ask the new hire if his or her Lightning node has that capacity.
If not, you take some of your onchain Lightning funds, swap out say 0.043 BTC on Lightning Loop or Boltz Exchange or some other offchain-to-onchain swap.
You use those swapped onchain funds to create a fresh channel to the new hire.
If you are onboarding by batches (which your HR is likely to want to do, so they can give the onboarding employee seminars in groups) then you can save onchain fees by using C-Lightning `multifundchannel` as well.
The occasional bonus can be a bit tricky, but similarly the employee can use Lightning Loop or Boltz Exchange or some other alternative to free up capacity for the bonus (and they have an incentive to do so, as they want to get the bonus).
Permanent raises can justify permanently increasing the size of the channel with the employee.
Even if the employee leaves your employ, that is no justification to close the channel with her or his node.
You can earn forwarding fees from his or her new employer or income source.
Because of the onion routing, it is hard for you to learn what the employee spends on, and in the future when they leave your employ, it is hard for you to figure out her or his new employer.
If the employee is a saver, they can accumulate their funds, thus reducing their incoming capacity below their biweekly salary.
If so, he or she can use an offchain-to-onchain swap, again, to move their accumulated savings to onchain cold storage.
This is not perfect of course, if you run multiple nodes you can try correlating payments by timing and amount (and prior to payment points i.e. today, you can correlate by payment hashes).
But this is still much better than the onchain situation, as you describe.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
2020-10-03 5:21 [bitcoin-dev] A thought experiment on bitcoin for payroll privacy Mr. Lee Chiffre
2020-10-03 22:24 ` ZmnSCPxj
@ 2020-10-04 3:45 ` ZmnSCPxj
2020-10-04 14:07 ` Thomas Hartman
1 sibling, 1 reply; 7+ messages in thread
From: ZmnSCPxj @ 2020-10-04 3:45 UTC (permalink / raw)
To: Mr. Lee Chiffre, Bitcoin Protocol Discussion
Good Morning Mr. Lee,
> I cannot front up funds of my own to give
> them inbound balance because it would consume all of my treasury to lock
> up funds.
This is not a reasonable assumption!
Suppose you have a new hire that you have agreed to pay 0.042BTC every 2 weeks.
On the *first* payday of the new hire, you *have* to have *at least* 0.042BTC in your treasury, somehow.
If not, you are unable to pay the new hire, full stop, and you are doomed to bankruptcy and your problems will disappear soon once your cut-throat new hire cuts your throat for not paying her or him.
If you *do* have at least 0.042BTC in your treasury, you *can* make the channel with the new hire and pay the salary via the new channel.
At *every* payday, you need to have at least the salary of your entire employee base available, otherwise you would be unable to pay at least some of your employees and you will quickly find yourself with your throat cut.
Now, let us talk about *topology*.
Let us reduce this to a pointless topology that is the *worst possible topology* for Lightning usage, and show that by golly, Lightning will still work.
Suppose your company only has this one big channel with the network.
Let us reduce your company to only having this single new hire throat-cutter (we will show later that without loss of generality this will still work even if you have thousands of throat-cutters internationally).
Now, as mentioned, on the first payday of your throat-cutter, you *have* to have at least the 0.042 salary you promised.
If you have been receiving payments for your throat-cutting business on the big channel, that means the 0.042 BTC is in that single big channel.
You can then use an offchain-to-onchain swap service like Boltz or Loop and put the money onchain.
Then you can create the new channel to your new hire and pay the promised salary to the throat-cutter.
Now, you have no more funds in either of your channels, the to-network big channel, and the to-employee channel.
So you are not locking up any of *your* funds, only the funds of your employee.
Now, as your business operates, you will receive money in your to-network big channel.
The rate at which you receive money for services rendered *has to* be larger than 0.042/2weeks on average, *otherwise* you are not earning enough to pay your throat-cutter by the time of the *next* payday (much less your other operating expenses, such as knife-sharpening, corpse disposal, dealing with the families of the deceased, etc.).
If you are not earning at a high enough rate to pay your employee by the next payday, your employee will not be paid and will solve your problems by cutting your throat.
But what that means is that the employee salary of the *previous* payday is not locked, either!
Because you are receiving funds on your big to-network channel continuously, the employee can now spend the funds "locked" in the to-employee channel, sending out to the rest of the network.
This uses up the money you have been earning and moving the funds to the to-employee channel, but if you are running a lucrative business, that is perfectly fine, since you should, by the next payday, have earned enough, and then some, to pay the employee on the next payday.
Of course there will be times when business is a little slow and you get less than 0.042/2weeks.
In that case, a wise business manager will reserve some funds for a rainy day when business is a little slow, meaning you will still have some funds you can put into your to-network big channel for other expenses, even as your employee uses capacity there to actually spend their salary.
It all balances out.
You only need to keep enough in your channels to cover your continuous operational expenses, and employee salaries *are* operational expenses.
Suppose you now want to hire *another* throat-cutter.
You would only do that if business is booming, or in other words, if you have accumulated enough money in your treasury to justify hiring yet another employee.
By induction, this will work regardless if you have 1 employee, or 1 million.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
2020-10-04 3:45 ` ZmnSCPxj
@ 2020-10-04 14:07 ` Thomas Hartman
2020-10-04 14:24 ` ZmnSCPxj
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Hartman @ 2020-10-04 14:07 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
"big to-network channel"
nit: should this be "big from-network channel" ?
thanks for this explanation.
On Sat, Oct 3, 2020 at 11:45 PM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Good Morning Mr. Lee,
>
> > I cannot front up funds of my own to give
> > them inbound balance because it would consume all of my treasury to lock
> > up funds.
>
> This is not a reasonable assumption!
>
> Suppose you have a new hire that you have agreed to pay 0.042BTC every 2 weeks.
>
> On the *first* payday of the new hire, you *have* to have *at least* 0.042BTC in your treasury, somehow.
>
> If not, you are unable to pay the new hire, full stop, and you are doomed to bankruptcy and your problems will disappear soon once your cut-throat new hire cuts your throat for not paying her or him.
>
> If you *do* have at least 0.042BTC in your treasury, you *can* make the channel with the new hire and pay the salary via the new channel.
>
> At *every* payday, you need to have at least the salary of your entire employee base available, otherwise you would be unable to pay at least some of your employees and you will quickly find yourself with your throat cut.
>
>
>
>
> Now, let us talk about *topology*.
>
> Let us reduce this to a pointless topology that is the *worst possible topology* for Lightning usage, and show that by golly, Lightning will still work.
>
> Suppose your company only has this one big channel with the network.
> Let us reduce your company to only having this single new hire throat-cutter (we will show later that without loss of generality this will still work even if you have thousands of throat-cutters internationally).
>
> Now, as mentioned, on the first payday of your throat-cutter, you *have* to have at least the 0.042 salary you promised.
> If you have been receiving payments for your throat-cutting business on the big channel, that means the 0.042 BTC is in that single big channel.
>
> You can then use an offchain-to-onchain swap service like Boltz or Loop and put the money onchain.
> Then you can create the new channel to your new hire and pay the promised salary to the throat-cutter.
>
> Now, you have no more funds in either of your channels, the to-network big channel, and the to-employee channel.
> So you are not locking up any of *your* funds, only the funds of your employee.
>
> Now, as your business operates, you will receive money in your to-network big channel.
> The rate at which you receive money for services rendered *has to* be larger than 0.042/2weeks on average, *otherwise* you are not earning enough to pay your throat-cutter by the time of the *next* payday (much less your other operating expenses, such as knife-sharpening, corpse disposal, dealing with the families of the deceased, etc.).
> If you are not earning at a high enough rate to pay your employee by the next payday, your employee will not be paid and will solve your problems by cutting your throat.
>
> But what that means is that the employee salary of the *previous* payday is not locked, either!
> Because you are receiving funds on your big to-network channel continuously, the employee can now spend the funds "locked" in the to-employee channel, sending out to the rest of the network.
> This uses up the money you have been earning and moving the funds to the to-employee channel, but if you are running a lucrative business, that is perfectly fine, since you should, by the next payday, have earned enough, and then some, to pay the employee on the next payday.
>
> Of course there will be times when business is a little slow and you get less than 0.042/2weeks.
> In that case, a wise business manager will reserve some funds for a rainy day when business is a little slow, meaning you will still have some funds you can put into your to-network big channel for other expenses, even as your employee uses capacity there to actually spend their salary.
>
> It all balances out.
> You only need to keep enough in your channels to cover your continuous operational expenses, and employee salaries *are* operational expenses.
>
>
> Suppose you now want to hire *another* throat-cutter.
> You would only do that if business is booming, or in other words, if you have accumulated enough money in your treasury to justify hiring yet another employee.
>
> By induction, this will work regardless if you have 1 employee, or 1 million.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
2020-10-04 14:07 ` Thomas Hartman
@ 2020-10-04 14:24 ` ZmnSCPxj
0 siblings, 0 replies; 7+ messages in thread
From: ZmnSCPxj @ 2020-10-04 14:24 UTC (permalink / raw)
To: Thomas Hartman; +Cc: Bitcoin Protocol Discussion
Good morning Thomas,
> "big to-network channel"
>
> nit: should this be "big from-network channel" ?
As Lightning Network channels are bidirectional, it would be more properly "to/from-network", but that is cumbersome.
"to-network" is shorter by two characters than "from-network", and would be true as well (since the channel is bidirectional, it is both a "to-network" and "from-network" channel), thus preferred.
>
> thanks for this explanation.
You are welcome.
Regards,
ZmnSCPxj
> On Sat, Oct 3, 2020 at 11:45 PM ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists•linuxfoundation.org wrote:
>
> > Good Morning Mr. Lee,
> >
> > > I cannot front up funds of my own to give
> > > them inbound balance because it would consume all of my treasury to lock
> > > up funds.
> >
> > This is not a reasonable assumption!
> > Suppose you have a new hire that you have agreed to pay 0.042BTC every 2 weeks.
> > On the first payday of the new hire, you have to have at least 0.042BTC in your treasury, somehow.
> > If not, you are unable to pay the new hire, full stop, and you are doomed to bankruptcy and your problems will disappear soon once your cut-throat new hire cuts your throat for not paying her or him.
> > If you do have at least 0.042BTC in your treasury, you can make the channel with the new hire and pay the salary via the new channel.
> > At every payday, you need to have at least the salary of your entire employee base available, otherwise you would be unable to pay at least some of your employees and you will quickly find yourself with your throat cut.
> > Now, let us talk about topology.
> > Let us reduce this to a pointless topology that is the worst possible topology for Lightning usage, and show that by golly, Lightning will still work.
> > Suppose your company only has this one big channel with the network.
> > Let us reduce your company to only having this single new hire throat-cutter (we will show later that without loss of generality this will still work even if you have thousands of throat-cutters internationally).
> > Now, as mentioned, on the first payday of your throat-cutter, you have to have at least the 0.042 salary you promised.
> > If you have been receiving payments for your throat-cutting business on the big channel, that means the 0.042 BTC is in that single big channel.
> > You can then use an offchain-to-onchain swap service like Boltz or Loop and put the money onchain.
> > Then you can create the new channel to your new hire and pay the promised salary to the throat-cutter.
> > Now, you have no more funds in either of your channels, the to-network big channel, and the to-employee channel.
> > So you are not locking up any of your funds, only the funds of your employee.
> > Now, as your business operates, you will receive money in your to-network big channel.
> > The rate at which you receive money for services rendered has to be larger than 0.042/2weeks on average, otherwise you are not earning enough to pay your throat-cutter by the time of the next payday (much less your other operating expenses, such as knife-sharpening, corpse disposal, dealing with the families of the deceased, etc.).
> > If you are not earning at a high enough rate to pay your employee by the next payday, your employee will not be paid and will solve your problems by cutting your throat.
> > But what that means is that the employee salary of the previous payday is not locked, either!
> > Because you are receiving funds on your big to-network channel continuously, the employee can now spend the funds "locked" in the to-employee channel, sending out to the rest of the network.
> > This uses up the money you have been earning and moving the funds to the to-employee channel, but if you are running a lucrative business, that is perfectly fine, since you should, by the next payday, have earned enough, and then some, to pay the employee on the next payday.
> > Of course there will be times when business is a little slow and you get less than 0.042/2weeks.
> > In that case, a wise business manager will reserve some funds for a rainy day when business is a little slow, meaning you will still have some funds you can put into your to-network big channel for other expenses, even as your employee uses capacity there to actually spend their salary.
> > It all balances out.
> > You only need to keep enough in your channels to cover your continuous operational expenses, and employee salaries are operational expenses.
> > Suppose you now want to hire another throat-cutter.
> > You would only do that if business is booming, or in other words, if you have accumulated enough money in your treasury to justify hiring yet another employee.
> > By induction, this will work regardless if you have 1 employee, or 1 million.
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
2020-10-03 22:24 ` ZmnSCPxj
@ 2020-10-05 2:41 ` ZmnSCPxj
2020-10-06 4:10 ` ZmnSCPxj
0 siblings, 1 reply; 7+ messages in thread
From: ZmnSCPxj @ 2020-10-05 2:41 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
Good morning Mr. Lee,
> Permanent raises can justify permanently increasing the size of the channel with the employee.
On reflection, this is a bad idea.
Suppose I am a cut-throat employee and I want to have an idea of the bi-weekly salary of another employee.
I make some stupid bet, and lose, with the other employee.
I offer to pay the loss of my bet via Lightning, and the other employee, in all innocence, issues a Lightning invoice to me.
The Lightning invoice contains the actual node ID of the other employee.
And since I also have a channel with the cut-throat company, I know as well the node ID of the cut-throat company.
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.
On the other hand --- once the employee has *any* funds at all, they can similarly take an offchain-to-onchain swap, and then use the funds to create another channel to another part of the network.
The other employee as well can arrange incoming funds on that other channel by using offchain-to-onchain swaps to their cold storage.
Thus, as an employee gets promoted and pulls a larger bi-weekly salary, the channel with the cut-throat company becomes less and less an indicator of their *actual* bi-weekly salary, and there is still some deniability on the exact size of the salary.
At the same time, even if I know the node of the other employee, the size of all its channels is also still not a very accurate indicator of their salary at the throat-cutting company.
For example, it could be a family node, and the other employee and all her or his spouses arrange to have their salaries paid to that node.
Or the other employee can also run a neck-reconstruction business on the side, and also use the same node.
(Nodelets for the win?)
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
2020-10-05 2:41 ` ZmnSCPxj
@ 2020-10-06 4:10 ` ZmnSCPxj
0 siblings, 0 replies; 7+ messages in thread
From: ZmnSCPxj @ 2020-10-06 4:10 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-10-06 4:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-03 5:21 [bitcoin-dev] A thought experiment on bitcoin for payroll privacy Mr. Lee Chiffre
2020-10-03 22:24 ` ZmnSCPxj
2020-10-05 2:41 ` ZmnSCPxj
2020-10-06 4:10 ` ZmnSCPxj
2020-10-04 3:45 ` ZmnSCPxj
2020-10-04 14:07 ` Thomas Hartman
2020-10-04 14:24 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox