1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
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 DE7CEC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 03:45:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id D3D5D84CEB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 03:45:29 +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 vq1aap5mY8X7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 03:45:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by fraxinus.osuosl.org (Postfix) with ESMTPS id C829884C1E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 03:45:27 +0000 (UTC)
Date: Sun, 04 Oct 2020 03:45:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1601783124;
bh=8JNYir+7VoJG8yjqKzJyuuGfBim7SOZjLXvrlCmjOHU=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=QV8mje435V3JrC2HMKocze2d3SAsm6KUPDB4pKq/H+Mzp8RuYpidaig5w/YWHrJKR
6ZickzU1BJy9BjnmCzGibgLF3Y6XWgXkfo1HCw9PonD7PzhpPsAKHoMafXggKQru2c
f3tunXHUZWju8E3mJxDwu+TOk2VDL3fuP9jpm8fM=
To: "Mr. Lee Chiffre" <lee.chiffre@secmail.pro>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <p2JoErfteahZxNW_vNGpmBi7TLganHpJLb_JM0vC_EBPC1fQeqnb_XD5TB1HH5nKADYTVxek6JGYgFZcsEoekGDH0I5hSH2KDZ9ZpkSXK0U=@protonmail.com>
In-Reply-To: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion>
References: <976903d1529adef2aff8839290a91f2c.squirrel@giyzk7o6dcunb2ry.onion>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 03:45:30 -0000
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 we=
eks.
On the *first* payday of the new hire, you *have* to have *at least* 0.042B=
TC in your treasury, somehow.
If not, you are unable to pay the new hire, full stop, and you are doomed t=
o 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 empl=
oyee 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 topo=
logy* for Lightning usage, and show that by golly, Lightning will still wor=
k.
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-cutte=
r (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 s=
alary 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 emplo=
yee.
Now, as your business operates, you will receive money in your to-network b=
ig channel.
The rate at which you receive money for services rendered *has to* be large=
r 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 othe=
r operating expenses, such as knife-sharpening, corpse disposal, dealing wi=
th the families of the deceased, etc.).
If you are not earning at a high enough rate to pay your employee by the ne=
xt payday, your employee will not be paid and will solve your problems by c=
utting 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 per=
fectly 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 le=
ss than 0.042/2weeks.
In that case, a wise business manager will reserve some funds for a rainy d=
ay when business is a little slow, meaning you will still have some funds y=
ou can put into your to-network big channel for other expenses, even as you=
r 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 oper=
ational 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 ha=
ve 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 millio=
n.
Regards,
ZmnSCPxj
|
