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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
Return-Path: <thomashartman1@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4AB02C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 14:07:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 22BF120115
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 14:07:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2cmDT6jnzbaQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 14:07:19 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com
[209.85.208.43])
by silver.osuosl.org (Postfix) with ESMTPS id D83E620110
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2020 14:07:18 +0000 (UTC)
Received: by mail-ed1-f43.google.com with SMTP id k14so6663871edo.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 04 Oct 2020 07:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-transfer-encoding;
bh=tHek+Z7nGWJtCrGS/lEW+KrTXtKj1LVZOSG4l1vRfXo=;
b=m0Qv1+7jixOBULwl659cmAwC78Pc7w8Z8MVwf68vZrLAd57xW1vQqIXLzmkZHTm+Cq
L4lc0arUy0mDsTwXMP2tXL6E0GqL9BqX/VPaJKjMTUnlWlwzSK0q8e8U+nlQ+/bmVjOf
dKuwiodKZcTSJ5bJZw/JN7J8vP2Spyhc4fc55qVVdhYmqIlcKrOG/o/jukOQwF4UKT8J
tMigO/9KjQ4sDsvv0OdNHgmEcTwTQnDAVA26Aj+q28b44dxN0f6Ale1k2mXIY3UPbgnq
FsNQnV2lsSrbXhlOez5JTDuB6XAYGg/OXrYg+M8lYvbst59LolHsOqci+vGMqoVYMBjO
GXng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=tHek+Z7nGWJtCrGS/lEW+KrTXtKj1LVZOSG4l1vRfXo=;
b=AVxY3QSwyDR1Rt1FBiEInCGcYK+jKUhqwcMXpd3rpiRLRhRQk+cXJRGSZBaU9ccCNi
jhiUek7nCL7WmwBewGZHDDeEMg5eZvGAhxKaL9RgSgJmZDNyO7kxPh0GqbNK+k6kw04V
5bi61lFIj/7FSbV4MhcfBFuH3Zz++OzwfuMUGN+JA/WZ7+44XQKftl16LaKZSMmnB3Wc
uBVIl86Cn/bC34hdNHO6dGexykjafa4uYJ1Po+Wdr8Tr+p/McJI3Tv1wl3+kBFsrqirm
tJKffPXvRNPn9mEvojHqP+BwQZ7fWIUp5s+9asqbRESkeV7raN1NUCkce27GssrhDpZ0
PS/A==
X-Gm-Message-State: AOAM531ppmziLeq36YeFphkyzJmDT75RiYMMSov9OcNrlAHn5C3apglc
47uzGe/aulfFQYxfxVQi3mV7ELYKDKTsqn3tE9zG0seU4/7eAQ==
X-Google-Smtp-Source: ABdhPJzQuyj3OwoPsZmHjmYOwUuY02bZQloZxERLEkNhhUa53nTjFlZ4fTwIJTJ/1QFTD7MLSlIK0+CfqgmcaTMsJX8=
X-Received: by 2002:a05:6402:d3:: with SMTP id
i19mr12833897edu.320.1601820436898;
Sun, 04 Oct 2020 07:07:16 -0700 (PDT)
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
X-Mailman-Approved-At: Sun, 04 Oct 2020 17:49:27 +0000
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:07:20 -0000
"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
|
