path: root/44/51423b87668fe14b6894fe5c3fb7d7b948e13a

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 100DEC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 14:25:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id E9E6E84C44
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 14:25:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vByCp26TpUY5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 14:25:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 5E6BE844C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 14:25:11 +0000 (UTC)
Date: Sun, 04 Oct 2020 14:24:59 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1601821508;
 bh=vK/pFzpy1/bjlqkyooWJu7mR5Hsde6RsyC0tFUYs8V8=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=Z+I0dKNXG4B798XRVkeflDRagFgznqtjhrV0Mk0l9axynv7Ymwnqk7ZDZKHvcLE6X
 6K+VwMsJk50GKir0ey2jDju0M62BHeiDAYHd1/4df8GxA5V1F/FbJfUPhmYqs7InuX
 KUMC9hVTfS14ROVXwC7CtODGmZ2PvbX+EOYu4Ukw=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2020 14:25:14 -0000

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