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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
