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
