MIME-Version: 1.0
References: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion>
 <p2JoErfteahZxNW_vNGpmBi7TLganHpJLb_JM0vC_EBPC1fQeqnb_XD5TB1HH5nKADYTVxek6JGYgFZcsEoekGDH0I5hSH2KDZ9ZpkSXK0U=@protonmail.com>
In-Reply-To: <p2JoErfteahZxNW_vNGpmBi7TLganHpJLb_JM0vC_EBPC1fQeqnb_XD5TB1HH5nKADYTVxek6JGYgFZcsEoekGDH0I5hSH2KDZ9ZpkSXK0U=@protonmail.com>
From: Thomas Hartman <thomashartman1@gmail.com>
Date: Sun, 4 Oct 2020 10:07:05 -0400
Message-ID: <CAHAXnDW717KRhW=H1siy75ynDdxKiYP5FgXbQHeGwxN_idJzTA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] A thought experiment on bitcoin for payroll
	privacy
Precedence: list

"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 loc=
k
> > 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.04=
2BTC 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 n=
ew 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 c=
hannel 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 em=
ployee base available, otherwise you would be unable to pay at least some o=
f 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 to=
pology* for Lightning usage, and show that by golly, Lightning will still w=
ork.
>
> 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-cut=
ter (we will show later that without loss of generality this will still wor=
k 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 t=
he 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 a=
nd 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 bi=
g channel, and the to-employee channel.
> So you are not locking up any of *your* funds, only the funds of your emp=
loyee.
>
> 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 lar=
ger 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 ot=
her 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 continuous=
ly, the employee can now spend the funds "locked" in the to-employee channe=
l, 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 p=
erfectly fine, since you should, by the next payday, have earned enough, an=
d 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 y=
our 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 op=
erational 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 anothe=
r employee.
>
> By induction, this will work regardless if you have 1 employee, or 1 mill=
ion.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev