path: root/fc/d7456bb5940455d67bb2615d1b32c16afacca2

Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6655FC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Jun 2020 17:21:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 4F9618773F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Jun 2020 17:21:24 +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 aD_fj6CbRPYg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Jun 2020 17:21:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 96A57877A8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Jun 2020 17:21:22 +0000 (UTC)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com
 [209.85.166.44]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05BHLKhs026293
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 11 Jun 2020 13:21:20 -0400
Received: by mail-io1-f44.google.com with SMTP id q8so7193505iow.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Jun 2020 10:21:20 -0700 (PDT)
X-Gm-Message-State: AOAM532xBYJhZ1rzT1cATgJldqNkHWGhlsT8iwKUemt4Gva2cVUVjolW
 R2eHBe0gMs/LKz076NwK8dM6tlVk2QFAmAngsWM=
X-Google-Smtp-Source: ABdhPJy2DF9bEHeRY2mLqxYbcAN2hm2iJ6bq2QMp7Sw2+R2T2cMVbuBUd3l71W5XVXfwvYFNs6PJ3ahwFoCCb30t6Po=
X-Received: by 2002:a02:298b:: with SMTP id p133mr4288090jap.73.1591896079676; 
 Thu, 11 Jun 2020 10:21:19 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com>
In-Reply-To: <CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 11 Jun 2020 10:21:08 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjkstCcF49s8r8ZqVH77VmWXaZSm=_sx=FKZuCj6Ci_UA@mail.gmail.com>
Message-ID: <CAD5xwhjkstCcF49s8r8ZqVH77VmWXaZSm=_sx=FKZuCj6Ci_UA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000059391305a7d23082"
Subject: Re: [bitcoin-dev] CoinPool,
 exploring generic payment pools for Fun and 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: Thu, 11 Jun 2020 17:21:24 -0000

--00000000000059391305a7d23082
Content-Type: text/plain; charset="UTF-8"

Stellar work Antoine and Gleb! Really excited to see designs come out on
payment pools.

I've also been designing some payment pools (I have some not ready code I
can share with you guys off list), and I wanted to share what I learned
here in case it's useful.

In my design of payment pools, I don't think the following requirement: "A
CoinPool must satisfy the following *non-interactive any-order withdrawal*
property: at any point in time and any possible sequence of previous
CoinPool events, a participant should be able to move their funds from the
CoinPool to any address the participant wants without cooperation with
other CoinPool members." is desirable in O(1) space. I think it's much
better to set the requirement to O(log(n)), and this isn't just because of
wanting to use CTV, although it does help.

Let me describe a quick CTV based payment pool:

Build a payment pool for N users as N/2 channels between participants
created in a payment tree with a radix of R, where every node has a
multisig path for being used as a multi-party channel and the CTV branch
has a preset timeout. E.g., with radix 2:

                                      Channel(a,b,c,d,e,f,g,h)
                                     /                                   \
               Channel(a,b,c,d)
Channel(e,f,g,h)
                    /
\                                                    /                 \
Channel(a,b)    Channel(c,d)                          Channel(e,f)
Channel(g,h)


All of these channels can be constructed and set up non-interatively using
CTV, and updated interactively. By default payments can happen with minimal
coordination of parties by standard lightning channel updates at the leaf
nodes, and channels can be rebalanced at higher layers with more
participation.


Now let's compare the first-person exit non cooperative scenario across
pools:

CTV-Pool:
Wait time: Log(N). At each branch, you must wait for a timeout, and you
have to go through log N to make sure there are no updated states. You can
trade off wait time/fees by picking different radixes.
TXN Size: Log(N) 1000 people with radix 4 --> 5 wait periods. 5*4 txn size.
Radix 20 --> 2 wait periods. 2*20 txn size.

Accumulator-Pool:
Wait Time: O(1)
TXN Size: Depending on accumulator: O(1), O(log N), O(N) bits. Let's be
favorable to Accumulators and assumer O(1), but keep in mind constant may
be somewhat large/operations might be expensive in validation for updates.


This *seems* like a clear win for Accumulators. But not so fast. Let's look
at the case where *everyone* exits non cooperatively from a payment pool.
What is the total work and time?

CTV Pool:
Wait time: Log(N)
Txn Size: O(N) (no worse than 2x factor overhead with radix 2, higher
radixes dramatically less overhead)

Accumulator Pool:
Wait time: O(N)
Txn Size: O(N) (bear in mind *maybe* O(N^2) or O(N log N) if we use an
sub-optimal accumulator, or validation work may be expensive depending on
the new primitive)


So in this context, CTV Pool has a clear benefit. The last recipient can
always clear in Log(N) time whereas in the accumulator pool, the last
recipient has to wait much much longer. There's no asymptotic difference in
Tx Size, but I suspect that CTV is at least as good or cheaper since it's
just one tx hash and doesn't depend on implementation.

Another property that is nice about the CTV pool style is the bisecting
property. Every time you have to do an uncooperative withdrawal, you split
the group into R groups. If your group is not cooperating because one
person is permanently offline, then Accumulator pools *guarantee* you need
to go through a full on-chain redemption. Not so with a CTV-style pool, as
if you have a single failure among [1,2,3,4,5,6,7,8,9,10] channels (let's
say channel 8 fails), then with a radix 4 setup your next steps are:
[1,2,3,4,5,6,7,8,9,10]
[1,2,3,4,5,6,7,X,9,10]
[1,2,3,4] [5,6,7,X] [9,10]
[1,2,3,4] 5 6 7 X [9,10]

So you only need to do Log(N) chain work to exit the bad actor, but then it
amortizes! A future failure (let's say of 5) only causes 5 to have to close
their channel, and does not affect anyone else.

With an accumulator based pool, if you re-pool after one failure, a second
failure causes another O(N) work. So then total work in that case is
O(N^2). You can improve the design by making the evict in any order option
such that you can *kick out* a member in any order, that helps solve some
of this nastiness (rather than them opting to leave). But I'm unclear how
to make this safe w.r.t. updated states. You could also allow, perhaps, any
number of operators to simultaneously leave in a tx. Also not sure how to
do that.



Availability:
With CTV Pools, you can make a payment if just your immediate conterparty
is online in your channel. Opportunistically, if people above you are
online, you can make channel updates higher up in the tree which have
better timeout properties. You can also create new channels, binding
yourself to different parties if there is a planned exit.

With Accumulator pools, you need all parties online to make payments.


Cooperation Case:
CTV Pools and Accumulator pools, in a cooperative case, both just act like
a N of N multisig.

Privacy:
Because Accumulator pools always require N signers, it's possible to build
a better privacy model where N parties are essentially managing a chaumian
ecash like server for updates, giving good privacy of who initiated
payments. You *could* do this with CTV pools as well, but I expect users to
prefer making updates at the 2 party channel layer for low latency, and to
get privacy benefits out of the routability of the channels and ability to
connect to the broader lightning network.


Technical Complexity:
Both protocols require new features in Bitcoin. CTV is relatively simple, I
would posit that accumulators + sighashnoinput are relatively not simple.

The actual protocol design for CTV pools is pretty simple and can be
compatible with LN, I already have a rudimentary implementation of the
required transactions (but not servers).


Interactivity:

In both designs, the payment pool can be created non-interactively. This is
*super* important as it means third parties (e.g., an exchange) can
withdraw users funds *into* a payment pool.


Thanks for reading!

Jeremy



--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--00000000000059391305a7d23082
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Stellar =
work Antoine and Gleb! Really excited to see designs come out on payment po=
ols.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">I&#39;ve also been designing some payment pools (I have some not=
 ready code I can share with you guys off list), and I wanted to share what=
 I learned here in case it&#39;s useful.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">In my design of payment pool=
s, I don&#39;t think the following requirement: &quot;A CoinPool must satis=
fy the following *non-interactive any-order=20
withdrawal* property: at any point in time and any possible sequence of=20
previous CoinPool events, a participant should be able to move their=20
funds from the CoinPool to any address the participant wants without=20
cooperation with other CoinPool members.&quot; is desirable in O(1) space. =
I think it&#39;s much better to set the requirement to O(log(n)), and this =
isn&#39;t just because of wanting to use CTV, although it does help.</div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
Let me describe a quick CTV based payment pool:</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">Build a payment pool =
for N users as N/2 channels between participants created in a payment tree =
with a radix of R, where every node has a multisig path for being used as a=
 multi-party channel and the CTV branch has a preset timeout. E.g., with ra=
dix 2:</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Channel(a,b,c,d,e,f,g,h)</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \<br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Channel(a,b,c,d)=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Channel(e,f,g,h)</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 \<br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">Channel(a,b)=C2=A0=
=C2=A0=C2=A0 Channel(c,d)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Channel(e,f)=C2=A0=C2=A0=C2=A0 Channel(g,h)</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">All of these channels can be =
constructed and set up non-interatively using CTV, and updated interactivel=
y. By default payments can happen with minimal coordination of parties by s=
tandard lightning channel updates at the leaf nodes, and channels can be re=
balanced at higher layers with more participation.</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Now let&#39;s compare the first-person exit non co=
operative scenario across pools:</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">CTV-Pool:<br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:#000000">Wait time: Log(N). At each branch, you must wait for a time=
out, and you have to go through log N to make sure there are no updated sta=
tes. You can trade off wait time/fees by picking different radixes.</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">TXN Size: Log(N) 1000 people with radix 4 --=
&gt; 5 wait periods. 5*4 txn size. Radix 20 --&gt; 2 wait periods. 2*20 txn=
 size.</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">Accumulator-Pool:</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Wait T=
ime: O(1)</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000">TXN Size: Depending on accu=
mulator: O(1), O(log N), O(N) bits. Let&#39;s be favorable to Accumulators =
and assumer O(1), but keep in mind constant may be somewhat large/operation=
s might be expensive in validation for updates.</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">This *seems* like a clear win for Accumulators. But =
not so fast. Let&#39;s look at the case where *everyone* exits non cooperat=
ively from a payment pool. What is the total work and time?<br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">CTV P=
ool:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000">Wait time: Log(N)</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000">Txn Size: O(N) (no worse than 2x factor overhead wi=
th radix 2, higher radixes dramatically less overhead)<br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Accumulat=
or Pool:</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">Wait time: O(N)</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">Txn Size: O(N) (bear in mind *maybe* O(N^2) or O(=
N log N) if we use an sub-optimal accumulator, or validation work may be ex=
pensive depending on the new primitive)</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">So in this context, CTV Pool has a clear benefit. The last re=
cipient can always clear in Log(N) time whereas in the accumulator pool, th=
e last recipient has to wait much much longer. There&#39;s no asymptotic di=
fference in Tx Size, but I suspect that CTV is at least as good or cheaper =
since it&#39;s just one tx hash and doesn&#39;t depend on implementation.<b=
r></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">Another property that is nice about the CTV pool style is the bise=
cting property. Every time you have to do an uncooperative withdrawal, you =
split the group into R groups. If your group is not cooperating because one=
 person is permanently offline, then Accumulator pools *guarantee* you need=
 to go through a full on-chain redemption. Not so with a CTV-style pool, as=
 if you have a single failure among [1,2,3,4,5,6,7,8,9,10] channels (let&#3=
9;s say channel 8 fails), then with a radix 4 setup your next steps are:</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">[1,2,3,4,5,6,7,8,9,10] <br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000">[1,2,3,4,5,6,7,X,9,10] </div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">[1,2,3,4] [5,6,7,X] [9,10] </div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000">[1,2,3,4] 5 6 7 X [9,10] </div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">So you only need to do Log(N) chain wo=
rk to exit the bad actor, but then it amortizes! A future failure (let&#39;=
s say of 5) only causes 5 to have to close their channel, and does not affe=
ct anyone else.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">With an accumulator based pool, if you re-pool after=
 one failure, a second failure causes another O(N) work. So then total work=
 in that case is O(N^2). You can improve the design by making the evict in =
any order option such that you can *kick out* a member in any order, that h=
elps solve some of this nastiness (rather than them opting to leave). But I=
&#39;m unclear how to make this safe w.r.t. updated states. You could also =
allow, perhaps, any number of operators to simultaneously leave in a tx. Al=
so not sure how to do that.<br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">Availability:</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">With CTV Pools, you can make a payment if just yo=
ur immediate conterparty is online in your channel. Opportunistically, if p=
eople above you are online, you can make channel updates higher up in the t=
ree which have better timeout properties. You can also create new channels,=
 binding yourself to different parties if there is a planned exit. <br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0">With Accumulator pools, you need all parties online to make payments.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">Cooperation Case:</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">CTV Pools and Accumulator pools, in a cooperati=
ve case, both just act like a N of N multisig.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000">Privacy:</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Because Accumulator pools always require N signers=
, it&#39;s possible to build a better privacy model where N parties are ess=
entially managing a chaumian ecash like server for updates, giving good pri=
vacy of who initiated payments. You *could* do this with CTV pools as well,=
 but I expect users to prefer making updates at the 2 party channel layer f=
or low latency, and to get privacy benefits out of the routability of the c=
hannels and ability to connect to the broader lightning network.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">Technical Complexity:</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000">Both protocols require new features in Bitcoin. CTV=
 is relatively simple, I would posit that accumulators=C2=A0+ sighashnoinpu=
t are relatively not simple.</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000">The actual protocol design for CTV pools=
 is pretty simple and can be compatible with LN, I already have a rudimenta=
ry implementation of the required transactions (but not servers).<br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">Interactivity:</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">In both d=
esigns, the payment pool can be created non-interactively. This is *super* =
important as it means third parties (e.g., an exchange) can withdraw users =
funds *into* a payment pool.<br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000">Thanks for reading!</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">Jeremy<br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000"><br clear=3D"all"></div><div><div dir=3D"ltr" data-smartm=
ail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.c=
om/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitte=
r.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div></div>

--00000000000059391305a7d23082--