Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
"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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] A thought experiment on bitcoin for payroll privacy
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.chif...@secmail.pro PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
