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
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id C5FA6C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 17:36:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id C240F607CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 17:36:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level:
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id IN4dcbNLb1Ms
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 17:36:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com
[IPv6:2607:f8b0:4864:20::634])
by smtp3.osuosl.org (Postfix) with ESMTPS id 792EA60777
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 17:36:42 +0000 (UTC)
Received: by mail-pl1-x634.google.com with SMTP id d22so5571312plr.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 12 May 2022 10:36:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=TwiaLYdkT5NKzbMV8q3iykdqEYvqbD1++44Su07stQ0=;
b=GNIzZz1rmHRovg3oMbX5qyCpO3z0lnVTab9LjLDg7kHtCiBsCSVr3KpImL+Eu3arib
3w14QV6mcN0jVjBr6f0mCPbz+blcfPk4RbtoZ0tl3rgioEgNEbYx22Pl9EvE9cMbtT5o
F3AljyGy6VpfBR8fozJJ7C5C7CHBd/BvxatYuHMc9A8tzfbF3aJjcjty3/VRYYJm4B+b
GoJMJpAfjlQdzCn+HysxdNokSN2a7uNlbIu+htsmQOG0bjGRqhljf1w5E7sIxJGecFvf
+dw3SlPPwLcSNglLvJJ4UNyQ9f3cWZC0q8QynR22E6Yr38s1BKNchKytow0mC/CChT1l
rT6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=TwiaLYdkT5NKzbMV8q3iykdqEYvqbD1++44Su07stQ0=;
b=HFUnZZilC6ZbuFn46wA2TnT8wiV7/tALG6Kc9r3MYnvUj3zU0v8skhLj+rXzc21Qm4
x5cPaAmwDSZAWsXTiicZGuHpKvBXgxjjEypilx2YnKUZ6cSs24bZyJIFWRcEw5bUVPDH
4WJtkkBJ77E2JUWG0Yd5AeHC1lm/3iDaQETfYHew7i6S0CX1ItULy7zqCblNk7ai4jyl
Q28mm9IBsCqjKEHMYsKltPjtsjb5TypFf9tuhnnEjLGor+wA6TiE6iefwc869POl4hEc
lKwNtBMQ6o7Z2KqJVZa9Q5x2EdXR7gLHmGT16kwObml+0VZb8GSTdwAswleVcS0G6a8l
LBNg==
X-Gm-Message-State: AOAM530JXZvTTQb3tfxdM6w4PyBT5wa03dhPeJm5pXcWQ/7uXoHxR3a2
bbOgqfxpYT0W4b8dMKdKk8OVbz2M2kcHY5m4NNQ=
X-Google-Smtp-Source: ABdhPJyTafH951i31P3CHG4CMEl7IZtbQvEmdQGdVNt6pPsvjZBF2c7AVA3mjUN0FOZrdRWkTOFxgDIx6vKMgaSL5cw=
X-Received: by 2002:a17:902:b7ca:b0:15c:df6a:be86 with SMTP id
v10-20020a170902b7ca00b0015cdf6abe86mr962894plz.70.1652377001692; Thu, 12 May
2022 10:36:41 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GNoRdbtfeBtpnitiAZ4jGwSsRpSRXOyX7mzrhwewmBcw@mail.gmail.com>
<CAGpPWDa2wofye=KSq-vVNS0SOU34st9wm-hMhiYzGLTKMGuP5w@mail.gmail.com>
<mcikQmSFmiZw6Tq1GocybVcjGHNc-u9cP1aoZpJU-HEfgcqXXi1WhZSnEDMtEz3GfqAJGWpfZXjEBmsCXNSyLAgVNNcsSklERd-DJ8KeocE=@protonmail.com>
In-Reply-To: <mcikQmSFmiZw6Tq1GocybVcjGHNc-u9cP1aoZpJU-HEfgcqXXi1WhZSnEDMtEz3GfqAJGWpfZXjEBmsCXNSyLAgVNNcsSklERd-DJ8KeocE=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Thu, 12 May 2022 12:36:25 -0500
Message-ID: <CAGpPWDb-P9ubvx1iMmYR8Gm2AOwg9cbu+fCKuXHMZk2JRwW=iw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000038925e05ded400bc"
X-Mailman-Approved-At: Thu, 12 May 2022 17:54:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Conjectures on solving the high interactivity
issue in payment pools and channel factories
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: Thu, 12 May 2022 17:36:43 -0000
--00000000000038925e05ded400bc
Content-Type: text/plain; charset="UTF-8"
@Antoine
> it's also hard to predict in advance the liquidity needs of the
sub-pools.
Definitely. Better than not being able to use the pool at all when
someone's offline tho.
> this fan-out transaction could interfere with the confirmation of the
simple withdraw transactions
> So there is an open question about the "honest" usage of the sub-pool
states themselves.
I don't follow this one. How would it interfere? How would it call into
question the "honesty" of the sub-pools? Why would honesty matter? I would
assume they can all be structured trustlessly.
> one could envision an accumulator committing directly to balances too
Are you suggesting that there would be some kind of opcode that operates on
this accumulator to shift around balances of some participants without
disturbing others? Sounds reasonable.
> I think the challenge is to find a compact accumulator with those
properties.
The Merkle Sum Trees like are used in Taro sound like they could probably
be useful for that.
> It's more likely a lot of them will delegate this operation to
third-party providers, with the known reductions in terms of
trust-minimizations.
There is of course that limitation. But a third party empowered only to
keep the pool functioning is much better than one given the ability to
spend on your behalf without your confirmation. This would be a big
improvement despite there still being minor privacy downsides.
> Hmmm, how could you prevent the always-online service from using the
receiving-key in "spending" mode if the balance stacked there becomes
relevant ?
You mean if your balance in the pool is 1000 sats and the service
facilitates receiving 100 sats, that service could then steal those 100
sats? And you're asking how you could prevent that? Well first of all, if
you're in a channel, not only does your service need to want to steal your
funds, but your channel partner(s) must also sign for that as well - so
they both must be malicious for these funds to be stolen. I can't see a way
to prevent that, but at least this situation prevents them from stealing
your whole 1100 sats, and can only steal 100 sats.
> see https://gitlab.com/lightning-signer/docs for wip in that direction.
Interesting. I'm glad someone's been working on this kind of thing
> A malicious pool participant could still commit her off-chain balance in
two partitions and send spends to the A&B hosting "receiving-keys" entities
without them being aware of the conflict, in the lack of a reconciliation
such as a publication space ?
Actually, I was envisioning that the always-online services holding a
receive-only key would *all* be online. So all participants of the pool
would have a representative, either one with a spending key or with just a
receiving-key (which could also be used to simply sign pool state changes
that don't negatively affect the balance of the user they represent). So
there still would be agreement among all participants on pool state
changes.
I kind of think if both techniques (sub-pools and limited-trust services)
are used, it might be able to substantially increase the ability for a pool
to operate effectively (ie substantially decrease the average downtime).
@ZmnSCPxj
> Is this not just basically channel factories?
It is.
> To reduce the disruption if any one pool participant is down, have each
sub-pool have only 2 participants each.
Yes. But the benefit of the pool over just having individual 2 person
channels is that you can change around the structure of the channels within
the pool without doing on-chain transactions. As Antoine mentioned, it may
often not be predictable which 2-person channels would be beneficial in the
future. So you want the pool to be as responsive as possible to the
changing needs of the pool.
On Tue, May 10, 2022 at 11:45 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Billy,
>
>
> > Very interesting exploration. I think you're right that there are issues
> with the kind of partitioning you're talking about. Lightning works because
> all participants sign all offchain states (barring data loss). If a
> participant can be excluded from needing to agree to a new state, there
> must be an additional mechanism to ensure the relevant state for that
> participant isn't changed to their detriment.
> >
> > To summarize my below email, the two techniques I can think for solving
> this problem are:
> >
> > A. Create sub-pools when the whole group is live that can be used by the
> sub- pool participants later without the whole group's involvement. The
> whole group is needed to change the whole group's state (eg close or open
> sub-pools), but sub-pool states don't need to involve the whole group.
>
> Is this not just basically channel factories?
>
> To reduce the disruption if any one pool participant is down, have each
> sub-pool have only 2 participants each.
> More participants means that the probability that one of them is offline
> is higher, so you use the minimum number of participants in the sub-pool: 2.
> This makes any arbitrary sub-pool more likely to be usable.
>
> But a 2-participant pool is a channel.
> So a large multiparticipant pool with sub-pools is just a channel factory
> for a bunch of channels.
>
> I like this idea because it has good tradeoffs, so channel factories ho.
>
> Regards,
> ZmnSCPxj
>
--00000000000038925e05ded400bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>@Antoine<br></div>>=C2=A0=C2=A0it's also hard =
to predict in advance the liquidity needs of the sub-pools.<br><div><br></d=
iv><div>Definitely. Better than not being able to use the pool at all when =
someone's offline tho.</div><div><br></div><div>> this fan-out trans=
action could interfere with the confirmation of the simple withdraw transac=
tions</div><div>> So there is an open question about the "honest&qu=
ot; usage of the sub-pool states themselves.</div><div><br></div><div>I don=
't follow this one. How would it interfere? How would it call into ques=
tion the "honesty" of the sub-pools? Why would honesty matter? I =
would assume they can all be structured trustlessly.</div><div><br></div><d=
iv>> one could envision an accumulator committing directly to balances t=
oo</div><div><br></div><div>Are you suggesting that there would be some kin=
d of opcode that operates on this accumulator to shift around balances of s=
ome participants without disturbing others? Sounds reasonable.</div><div><b=
r></div><div>> I think the challenge is to find a compact accumulator wi=
th those properties.</div><div><br></div><div>The=C2=A0<span style=3D"color=
:rgb(0,0,0);white-space:pre-wrap">Merkle Sum Trees like are used in Taro so=
und like they could probably be useful for that.</span></div><div><span sty=
le=3D"color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span st=
yle=3D"color:rgb(0,0,0);white-space:pre-wrap">> </span>It's more lik=
ely a lot of them will delegate this operation to third-party providers, wi=
th the known reductions in terms of trust-minimizations.</div><div><br></di=
v><div>There is of course that limitation. But a third party empowered only=
to keep the pool functioning is much better than one given the ability to =
spend on your behalf without your confirmation. This would be a big improve=
ment despite there still being minor privacy downsides.=C2=A0</div><div><br=
></div><div>> Hmmm, how could you prevent the always-online service from=
using the receiving-key in "spending" mode if the balance stacke=
d there becomes relevant ?</div><div><br></div><div>You mean if your balanc=
e in the pool is 1000 sats and the service facilitates=C2=A0receiving 100 s=
ats, that service could then steal those 100 sats? And you're asking ho=
w you could prevent that? Well first of all, if you're in a channel, no=
t only does your service need to want to steal your funds, but your channel=
partner(s) must also sign for that as well - so they both must be maliciou=
s for these funds to be stolen. I can't see a way to prevent that, but =
at least this situation prevents them from stealing your whole 1100 sats, a=
nd can only steal 100 sats.=C2=A0</div><div><br></div><div>>=C2=A0 see=
=C2=A0<a href=3D"https://gitlab.com/lightning-signer/docs" target=3D"_blank=
">https://gitlab.com/lightning-signer/docs</a>=C2=A0for wip in that directi=
on.</div><div><br></div><div>Interesting. I'm glad someone's been w=
orking on this kind of thing</div><div><br></div><div>> A malicious pool=
participant could still commit her off-chain balance in two partitions and=
send spends to the A&B hosting "receiving-keys" entities wit=
hout them being aware of the conflict, in the lack of a reconciliation such=
as a publication space ?</div><div><br></div><div>Actually, I was envision=
ing that the always-online services holding a receive-only key would *all* =
be online. So all participants of the pool would have a representative, eit=
her one with a spending key or with just a receiving-key (which could also =
be used to simply sign pool state changes that don't negatively affect =
the balance of the user they represent). So there still would be agreement =
among all participants on pool state changes.=C2=A0</div><div><br></div><di=
v>I kind of think if both techniques (sub-pools and limited-trust services)=
are used, it might be able to substantially increase the ability for a poo=
l to operate effectively (ie substantially decrease the average downtime).=
=C2=A0</div><div><br></div><div>@ZmnSCPxj</div><div>> Is this not just b=
asically channel factories?</div><div><br></div><div>It is.</div><div><br><=
/div><div>> To reduce the disruption if any one pool participant is down=
, have each sub-pool have only 2 participants each.</div><div><br></div><di=
v>Yes. But the benefit of the pool over just having individual 2 person cha=
nnels is that you can change around the structure of the channels within th=
e pool without doing on-chain transactions. As Antoine mentioned, it may of=
ten not be predictable which 2-person channels would be beneficial in the f=
uture. So you want the pool to be as responsive as possible to the changing=
needs of the pool.=C2=A0</div><div><br></div><div><br></div></div><br><div=
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 10=
, 2022 at 11:45 AM ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com" =
target=3D"_blank">ZmnSCPxj@protonmail.com</a>> wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Good morning Billy,<br>
<br>
<br>
> Very interesting exploration. I think you're right that there are =
issues with the kind of partitioning you're talking about. Lightning wo=
rks because all participants sign all=C2=A0offchain states (barring data lo=
ss). If a participant can be excluded from needing to agree to a new state,=
there must be an additional mechanism to ensure the relevant state for tha=
t participant isn't changed to their detriment.=C2=A0<br>
><br>
> To summarize my below email, the two techniques I can think for solvin=
g this problem are:<br>
><br>
> A. Create sub-pools when the whole group is live that can be used by t=
he sub- pool=C2=A0participants later without the whole group's involvem=
ent. The whole group is needed to change the whole group's state (eg cl=
ose or open sub-pools), but sub-pool=C2=A0states don't need to involve =
the whole group.<br>
<br>
Is this not just basically channel factories?<br>
<br>
To reduce the disruption if any one pool participant is down, have each sub=
-pool have only 2 participants each.<br>
More participants means that the probability that one of them is offline is=
higher, so you use the minimum number of participants in the sub-pool: 2.<=
br>
This makes any arbitrary sub-pool more likely to be usable.<br>
<br>
But a 2-participant pool is a channel.<br>
So a large multiparticipant pool with sub-pools is just a channel factory f=
or a bunch of channels.<br>
<br>
I like this idea because it has good tradeoffs, so channel factories ho.<br=
>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--00000000000038925e05ded400bc--
|