Date: Sun, 04 Oct 2020 14:24:59 +0000
To: Thomas Hartman <thomashartman1@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <yQfhDGq-Vmm1rL8VxIOH6oEW56zP-kxTxmp_9045twVFffy3VEoGalbOCeakLru26mmtYkAiOi4k4MP5onFEInwPgh1LI_Ci1EMjNsnIreg=@protonmail.com>
In-Reply-To: <CAHAXnDW717KRhW=H1siy75ynDdxKiYP5FgXbQHeGwxN_idJzTA@mail.gmail.com>
References: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion>
 <p2JoErfteahZxNW_vNGpmBi7TLganHpJLb_JM0vC_EBPC1fQeqnb_XD5TB1HH5nKADYTVxek6JGYgFZcsEoekGDH0I5hSH2KDZ9ZpkSXK0U=@protonmail.com>
 <CAHAXnDW717KRhW=H1siy75ynDdxKiYP5FgXbQHeGwxN_idJzTA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A thought experiment on bitcoin for payroll
	privacy
Precedence: list

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 l=
ock
> > > 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 doom=
ed 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 cha=
nnel 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 t=
opology 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-c=
utter (we will show later that without loss of generality this will still w=
ork 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 promis=
ed 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 emp=
loyee.
> > Now, as your business operates, you will receive money in your to-netwo=
rk 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 p=
ay 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 th=
e 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 continuo=
usly, the employee can now spend the funds "locked" in the to-employee chan=
nel, sending out to the rest of the network.
> > This uses up the money you have been earning and moving the funds to th=
e 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 ge=
t less than 0.042/2weeks.
> > In that case, a wise business manager will reserve some funds for a rai=
ny day when business is a little slow, meaning you will still have some fun=
ds 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 yo=
u have accumulated enough money in your treasury to justify hiring yet anot=
her employee.
> > By induction, this will work regardless if you have 1 employee, or 1 mi=
llion.
> > Regards,
> > ZmnSCPxj
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev