diff options
| author | Jeremy <jlrubin@mit.edu> | 2020-06-11 10:21:08 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-06-11 17:21:24 +0000 |
| commit | 711144962e96ec23026892afb074ea40e3d842f9 (patch) | |
| tree | c61fc0c34b4f6cd624bd87e16903047ef47734b7 /fc | |
| parent | 150bf032d2728bf0c83ca013a7c15b01285a9e26 (diff) | |
| download | pi-bitcoindev-711144962e96ec23026892afb074ea40e3d842f9.tar.gz pi-bitcoindev-711144962e96ec23026892afb074ea40e3d842f9.zip | |
Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
Diffstat (limited to 'fc')
| -rw-r--r-- | fc/d7456bb5940455d67bb2615d1b32c16afacca2 | 466 |
1 files changed, 466 insertions, 0 deletions
diff --git a/fc/d7456bb5940455d67bb2615d1b32c16afacca2 b/fc/d7456bb5940455d67bb2615d1b32c16afacca2 new file mode 100644 index 000000000..957075f50 --- /dev/null +++ b/fc/d7456bb5940455d67bb2615d1b32c16afacca2 @@ -0,0 +1,466 @@ +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'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.</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't think the following requirement: "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." 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.</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'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 --= +> 5 wait periods. 5*4 txn size. Radix 20 --> 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'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'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's no asymptotic di= +fference 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.<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= +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'= +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= +'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'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-- + |