diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2020-06-12 19:45:35 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-06-12 23:45:50 +0000 |
| commit | c01ff78c22eb4f121f2b399e4df6c9e141f7e5f0 (patch) | |
| tree | caad89b5000baec6f3e3f50ca812fa786a5432d0 | |
| parent | 251e883ffe69954cedef027f43fdb39f91c93f38 (diff) | |
| download | pi-bitcoindev-c01ff78c22eb4f121f2b399e4df6c9e141f7e5f0.tar.gz pi-bitcoindev-c01ff78c22eb4f121f2b399e4df6c9e141f7e5f0.zip | |
Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
| -rw-r--r-- | ea/75d0f925d67d1e0c5b92a04fcf053153d50d1f | 796 |
1 files changed, 796 insertions, 0 deletions
diff --git a/ea/75d0f925d67d1e0c5b92a04fcf053153d50d1f b/ea/75d0f925d67d1e0c5b92a04fcf053153d50d1f new file mode 100644 index 000000000..e4bcfa396 --- /dev/null +++ b/ea/75d0f925d67d1e0c5b92a04fcf053153d50d1f @@ -0,0 +1,796 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 57FE9C016F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Jun 2020 23:45:50 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id 419BF204ED + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Jun 2020 23:45:50 +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 UrlASySVYy5T + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Jun 2020 23:45:47 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com + [209.85.216.46]) + by silver.osuosl.org (Postfix) with ESMTPS id 8F92020387 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Jun 2020 23:45:47 +0000 (UTC) +Received: by mail-pj1-f46.google.com with SMTP id i4so4521186pjd.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Jun 2020 16:45:47 -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 + :cc; bh=weAoqVOAmm7tCizrWXpmcNIXiqhT2aH60RhP4OUGKxo=; + b=AiQ4P64tXpN6YdnHn9yGZEpxYKaEsEWFdhPnERFUMHEvhiLW98GC5TTM76Vw3Kb04f + k80LGHR8FIgBV1SjnUem4rsYLsTI2NXRmF7dOlZbhc+A7IlpEV1847dc9NBTbJeDkkqq + 8jwP2gg3oLmf8QFKfPj8vImVm9085gHn2gR3we7eS33jhL/9fNjarsBKxINcSzFLF1Ge + HiJ5oEX58Uy0jYCNYa/+P+2mIMlAurtn5gkH46xGdpvu102XFmmM415i94wQOBR7q3xd + rQRRPfMdi8CkQPT76WhttcJWkH+wS6oSg1CaEmerM6iHdkdl/aS2Mj4ES3E66mdRPMPq + yeGA== +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:cc; + bh=weAoqVOAmm7tCizrWXpmcNIXiqhT2aH60RhP4OUGKxo=; + b=mSY40rrzUV5CiYuuTQb1hEEVNc7tnrTVxnFbpKbq+3TmItaWhS0Sz1xT46v7W0m9PU + VkG1BhWBUtqSrMkeXW245s0m9Kogdcg2o74o/sofNDRYpHIAq8OE0tvS+Au9l+1TQazI + xJUQrLWe3SpY0DBlHjqiPnFxW/4KkMHcbWoSLcyIVksHBmLlRbhmYYiiXcb2SiLVccDc + YzqxXg2qWQ8WqioML7liExICDmxMqGGKkg+YpphRRt04f5Ro6iG0aXSQ3zqMXJWFRljD + svDi2uzzHt7bPbIzsQcl1UfwP4zrh7BMFsAuvuy+tgtEEgOjbqDJB9XnPZK0Qu3AJz7M + wyfQ== +X-Gm-Message-State: AOAM531bJs54NgAX/bcw49uc8XGchBXzL1Z/T0RFMmpJEKJMIvEFnUXS + u/QnttCnT4scq/PzMoUTt6PvUalMI2q3/Y2HvJs= +X-Google-Smtp-Source: ABdhPJyBqZ+/QgZIEGmgwJobKsYLraqfwoLgKAcUTu4lSEXEK0p6T/G6Dk6/79oS/y4Fp5t8P4xA4mN8DfYJckU5Qtg= +X-Received: by 2002:a17:902:b286:: with SMTP id + u6mr13160765plr.264.1592005546981; + Fri, 12 Jun 2020 16:45:46 -0700 (PDT) +MIME-Version: 1.0 +References: <CALZpt+FqAWCAqCLF2HsajL84sOvst_X9_34bb_tvUxLFw=HTAA@mail.gmail.com> + <CAD5xwhjkstCcF49s8r8ZqVH77VmWXaZSm=_sx=FKZuCj6Ci_UA@mail.gmail.com> +In-Reply-To: <CAD5xwhjkstCcF49s8r8ZqVH77VmWXaZSm=_sx=FKZuCj6Ci_UA@mail.gmail.com> +From: Antoine Riard <antoine.riard@gmail.com> +Date: Fri, 12 Jun 2020 19:45:35 -0400 +Message-ID: <CALZpt+Ec+K4oGXVexLikGKbGgcZ=AF+Spskx5SK-Om-HzuAAmg@mail.gmail.com> +To: Jeremy <jlrubin@mit.edu> +Content-Type: multipart/alternative; boundary="0000000000001bbd7805a7ebada4" +X-Mailman-Approved-At: Fri, 12 Jun 2020 23:46:36 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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: Fri, 12 Jun 2020 23:45:50 -0000 + +--0000000000001bbd7805a7ebada4 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Jeremy, + +For the records, I didn't know between Greg and you was at the origin of +payment pools. Thanks for your pioneer work here, obviously this draws +inspiration from OP_CTV use cases and Channel Factories works, even if we +picked up different assumptions and tried to address another set of issues. + +With regards to scalability, I hit it on my own while inquiring +covenanted-Bitcoin contracts for international trade. I mentioned the +any-order issue on such multi-party complex contracts in a talk last summer +(https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf). + +> All of these channels can be constructed and set up non-interatively usin= +g +> 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. + +Side review note on OP_CTV: I think it would be great to define +non-interactivity better, namely at least between 3 phases: establishment, +operation, closing. + +Even OP_CTV protocols assume interactivity at establishment, at least 1) to +learn payees pubkeys endpoint (and internal leaves pubkeys if you want +update at operation) 2) validate transaction tree correctness between +participants. + +At operation, it depends if participants want to dynamically rebalance +value across channels or not. If you desire dynamically rebalancing, assume +internal leaves scriptpubkeys are (multisig-all OR OP_CTV'ed merkle_tree). +Using OP_CTV is a saving in message rounds for every constant expression +across tree updates. + +At closing, depends again if participants have committed update keys or +not. If dynamic update, you can prune the whole tree and just commit final +balances onchain, either with a O(N) fan-out transaction (N outputs) or a +O(log(N)) congestion tree (N transactions). + +So I would say the originality of a hashchain covenant like OP_CTV is to +provide onchain *immutability* (unforgeability?) of the offchain +transaction tree and thus provides instant finality to payees. You can get +the same semantic with off-chain covenant, pre-signed set of transactions, +assuming more communications rounds and performance hit. + +That said, IMO, immutability comes with a security trade-off, namely if any +payout key committed in your OP_CTV tree gets compromised your funds are at +stake. And you can't update the tree anymore at the root to rotate keys. I +think this should be weighted by anyone designing covenant protocols, +especially vaults. + +> 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 th= +e +> CoinPool to any address the participant wants without cooperation with +> other CoinPool members." is desirable in O(1) space. + +With current design (Pool_tx+Split_tx) it's O(2) space. Pool_tx is similar +to a commitment tx and thus enables off-chain novation of pool distribution= +. + +> Let's be favorable to Accumulators and assume O(1), but keep in mind +constant may +> be somewhat large/operations might be expensive in validation for updates= +. + +Using a Merkle Tree as an accumulator should be constant-size in space, but +likely it has to be O(log(N) in computation (N set elements). This overhead +in computation should be accounted for in accumulator sigops to avoid +network validation resources free-riding, but I think it's a better +trade-off minimizing chain footprint. + +> 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. + +Yes I agree CTV pool performs better in the worst-case scenario. In my +opinon what we should really look on is the probability of withdrawal +scenarios. I see 2 failure cases: +* a pool participant being offline, thus halting the pool +* a pool participant with external protocol requirement to fulfill, like a +HTLC to timeout onchain + +With regards to 1) we assume that watchtower infra are likely to become +ubiquitous in the future (if you want a secure LN experience), so user +uptime should be near to 100%. Of course, it's a new architecture which +comes with trade-offs, but interesting to explore. + +With regards to 2) as of today channel-failure-rate (like unilateral close) +it's still quite important (30% IIRC) so it plays in favor of OP_CTV pool +but in the future I expect single-digit +therefore making CoinPool far more competitive. Do we envision protocol +more time-sensitive than LN in the future (atomic swaps...) ? Hard to gauge= +. + +Do you see other ways to refine model, like integrating out-of-pool +liquidity needs rate ? + +Note, I think for OP_CTV tree, increasing radix increases cooperation +requirement and failure, so there should be optimum somewhere. + +> If your group is not cooperating because one +> person is permanently offline, then Accumulator pools *guarantee* you nee= +d +> to go through a full on-chain redemption. + +That's right, that's a current shortcoming of this strawman design, I think +you can avoided by adding some timelocks, "if Alice doesn't anwser after X +days, initiate a kick-out", thus avoiding full onchain unrolling. + +> 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. + +I'm still thinking on this too, especially in LN-context, ideally you do +want the same thing to kick-out a HTLC of your HTLC-tree while preserving +the rest of them. Technically it works, if you assume CSV delay on the +commitment/pool_tx and locktime on the HTLC, which is Eltoo tradeoff. + +> With Accumulator pools, you need all parties online to make payments. + +I think that our shortcoming here, but technically with protocol rebinding +on any withdrawal output of Split_tx, you can have M-of-N channels between +pool participants. Also we should aim to support any kind of protocol at +the leaves. + +> Because Accumulator pools always require N signers, it's possible to buil= +d +> a better privacy model where N parties are essentially managing a chaumia= +n +> ecash like server for updates, giving good privacy of who initiated +> payments. + +Yes that what I've in mind is something with blind signatures or any +obfuscation of pool tree construction as privacy optimization. Still you +will leak value weight of leaves to an in-pool observer. + +> Both protocols require new features in Bitcoin. CTV is relatively simple, +I +> would posit that accumulators + sighashnoinput are relatively not simple. + +I agree design, review, deployment costs are an order of magnitude higher. +That said they are more powerful primitives which would cover use cases +beyond pools. A concern with OP_CTV is if we want semantic extensions we +may realize they don't rank that well compared to more generic "base" +primitives. + +> 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. + +See my point above, I think we need a better definition of +non-interactivity. + +Thanks for the high-quality review of CoinPool ! + +Antoine + +Le jeu. 11 juin 2020 =C3=A0 13:21, Jeremy <jlrubin@mit.edu> a =C3=A9crit : + +> 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 th= +e +> 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 o= +f +> 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 usin= +g +> CTV, and updated interactively. By default payments can happen with minim= +al +> 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 ca= +n +> 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 spli= +t +> the group into R groups. If your group is not cooperating because one +> person is permanently offline, then Accumulator pools *guarantee* you nee= +d +> to go through a full on-chain redemption. Not so with a CTV-style pool, a= +s +> 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 secon= +d +> 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 optio= +n +> 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, a= +ny +> 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 lik= +e +> a N of N multisig. +> +> Privacy: +> Because Accumulator pools always require N signers, it's possible to buil= +d +> a better privacy model where N parties are essentially managing a chaumia= +n +> 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 t= +o +> get privacy benefits out of the routability of the channels and ability t= +o +> 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 simpl= +e. +> +> 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> +> +> + +--0000000000001bbd7805a7ebada4 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Hi Jeremy,<br><br>For the records, I didn't know = +between Greg and you was at the origin of payment pools. Thanks for your pi= +oneer work here, obviously this draws inspiration from OP_CTV use cases and= + Channel Factories works, even if we picked up different assumptions and tr= +ied to address another set of issues.<br><br>With regards to scalability, I= + hit it on my own while inquiring covenanted-Bitcoin contracts for internat= +ional trade. I mentioned the any-order issue on such multi-party complex co= +ntracts in a talk last summer (<a href=3D"https://github.com/ariard/talk-sl= +ides/blob/master/advanced-contracts.pdf">https://github.com/ariard/talk-sli= +des/blob/master/advanced-contracts.pdf</a>).<br><br>> All of these chann= +els can be constructed and set up non-interatively using<br>> CTV, and u= +pdated interactively. By default payments can happen with minimal<br>> c= +oordination of parties by standard lightning channel updates at the leaf<br= +>> nodes, and channels can be rebalanced at higher layers with more<br>&= +gt; participation.<br><br>Side review note on OP_CTV: I think it would be g= +reat to define non-interactivity better, namely at least between 3 phases: = +establishment, operation, closing.<br><br>Even OP_CTV protocols assume inte= +ractivity at establishment, at least 1) to learn payees pubkeys endpoint (a= +nd internal leaves pubkeys if you want update at operation) 2) validate tra= +nsaction tree correctness between participants.<br><br>At operation, it dep= +ends if participants want to dynamically rebalance value across channels or= + not. If you desire dynamically rebalancing, assume internal leaves scriptp= +ubkeys are (multisig-all OR OP_CTV'ed merkle_tree). Using OP_CTV is a s= +aving in message rounds for every constant expression across tree updates.<= +br><br>At closing, depends again if participants have committed update keys= + or not. If dynamic update, you can prune the whole tree and just commit fi= +nal balances onchain, either with a O(N) fan-out transaction (N outputs) or= + a O(log(N)) congestion tree (N transactions). <br><br>So I would say the o= +riginality of a hashchain covenant like OP_CTV is to provide onchain *immut= +ability* (unforgeability?) of the offchain transaction tree and thus provid= +es instant finality to payees. You can get the same semantic with off-chain= + covenant, pre-signed set of transactions, assuming more communications rou= +nds and performance hit.<br><br>That said, IMO, immutability comes with a s= +ecurity trade-off, namely if any payout key committed in your OP_CTV tree g= +ets compromised your funds are at stake. And you can't update the tree = +anymore at the root to rotate keys. I think this should be weighted by anyo= +ne designing covenant protocols, especially vaults.<br><br>> I don't= + think the following requirement: "A<br>> CoinPool must satisfy the= + following *non-interactive any-order withdrawal*<br>> property: at any = +point in time and any possible sequence of previous<br>> CoinPool events= +, a participant should be able to move their funds from the<br>> CoinPoo= +l to any address the participant wants without cooperation with<br>> oth= +er CoinPool members." is desirable in O(1) space.<br><br>With current = +design (Pool_tx+Split_tx) it's O(2) space. Pool_tx is similar to a comm= +itment tx and thus enables off-chain novation of pool distribution.<br><br>= +> Let's be favorable to Accumulators and assume O(1), but keep in mi= +nd constant may<br>> be somewhat large/operations might be expensive in = +validation for updates.<br><br>Using a Merkle Tree as an accumulator should= + be constant-size in space, but likely it has to be O(log(N) in computation= + (N set elements). This overhead in computation should be accounted for in = +accumulator sigops to avoid network validation resources free-riding, but I= + think it's a better trade-off minimizing chain footprint.<br><br>> = +So in this context, CTV Pool has a clear benefit. The last recipient can<br= +>> always clear in Log(N) time whereas in the accumulator pool, the last= +<br>> recipient has to wait much much longer. There's no asymptotic = +difference in<br>> Tx Size, but I suspect that CTV is at least as good o= +r cheaper since it's<br>> just one tx hash and doesn't depend on= + implementation.<br><br>Yes I agree CTV pool performs better in the worst-c= +ase scenario. In my opinon what we should really look on is the probability= + of withdrawal scenarios. I see 2 failure cases:<br>* a pool participant be= +ing offline, thus halting the pool<br>* a pool participant with external pr= +otocol requirement to fulfill, like a HTLC to timeout onchain<br><br>With r= +egards to 1) we assume that watchtower infra are likely to become ubiquitou= +s in the future (if you want a secure LN experience), so user uptime should= + be near to 100%. Of course,=C2=A0 it's a new architecture which comes = +with trade-offs, but interesting to explore.<br><br>With regards to 2) as o= +f today channel-failure-rate (like unilateral close) it's still quite i= +mportant (30% IIRC) so it plays in favor of OP_CTV pool but in the future I= + expect single-digit<br>therefore making CoinPool far more competitive. Do = +we envision protocol more time-sensitive than LN in the future (atomic swap= +s...) ? Hard to gauge.<br><br>Do you see other ways to refine model, like i= +ntegrating out-of-pool liquidity needs rate ?<br><br>Note, I think for OP_C= +TV tree, increasing radix increases cooperation requirement and failure, so= + there should be optimum somewhere.<br><br>> If your group is not cooper= +ating because one<br>> person is permanently offline, then Accumulator p= +ools *guarantee* you need<br>> to go through a full on-chain redemption.= +<br><br>That's right, that's a current shortcoming of this strawman= + design, I think you can avoided by adding some timelocks, "if Alice d= +oesn't anwser after X days, initiate a kick-out", thus avoiding fu= +ll onchain unrolling.<br><br>> But I'm unclear how<br>> to make t= +his safe w.r.t. updated states. You could also allow, perhaps, any<br>> = +number of operators to simultaneously leave in a tx. Also not sure how to<b= +r>> do that. <br><br>I'm still thinking on this too, especially in L= +N-context, ideally you do want the same thing to kick-out a HTLC of your HT= +LC-tree while preserving the rest of them. Technically it works, if you ass= +ume CSV delay on the commitment/pool_tx and locktime on the HTLC, which is = +Eltoo tradeoff.<br><br>> With Accumulator pools, you need all parties on= +line to make payments.<br><br>I think that our shortcoming here, but techni= +cally with protocol rebinding on any withdrawal output of Split_tx, you can= + have M-of-N channels between pool participants. Also we should aim to supp= +ort any kind of protocol at the leaves.<br><br>> Because Accumulator poo= +ls always require N signers, it's possible to build<br>> a better pr= +ivacy model where N parties are essentially managing a chaumian<br>> eca= +sh like server for updates, giving good privacy of who initiated<br>> pa= +yments.<br><br>Yes that what I've in mind is something with blind signa= +tures or any obfuscation of pool tree construction as privacy optimization.= + Still you will leak value weight of leaves to an in-pool observer.<br><br>= +> Both protocols require new features in Bitcoin. CTV is relatively simp= +le, I<br>> would posit that accumulators + sighashnoinput are relatively= + not simple.<br><br>I agree design, review, deployment costs are an order o= +f magnitude higher. That said they are more powerful primitives which would= + cover use cases beyond pools. A concern with OP_CTV is if we want semantic= + extensions we may realize they don't rank that well compared to more g= +eneric "base" primitives.<br><br>> In both designs, the paymen= +t pool can be created non-interactively. This is<br>> *super* important = +as it means third parties (e.g., an exchange) can<br>> withdraw users fu= +nds *into* a payment pool.<br><br>See my point above, I think we need a bet= +ter definition of non-interactivity.<br><br>Thanks for the high-quality rev= +iew of CoinPool !<br><br>Antoine<br></div></div><br><div class=3D"gmail_quo= +te"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 11 juin 2020 =C3=A0= +=C2=A013:21, Jeremy <<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu<= +/a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= +g-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" = +style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0= +,0,0)">Stellar work Antoine and Gleb! Really excited to see designs come ou= +t on payment pools.</div><div class=3D"gmail_default" style=3D"font-family:= +arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)">I've also been designing some payment p= +ools (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 cla= +ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D= +"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I= +n my design of payment pools, I don't think the following requirement: = +"A CoinPool must satisfy 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:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s= +tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,= +0,0)">Let me describe a quick CTV based payment pool:</div><div class=3D"gm= +ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal= +l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa= +mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Build a p= +ayment pool for N users as N/2 channels between participants created in a p= +ayment tree with a radix of R, where every node has a multisig path for bei= +ng used as a multi-party channel and the CTV branch has a preset timeout. E= +.g., with radix 2:</div><div class=3D"gmail_default" style=3D"font-family:a= +rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div = +class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon= +t-size:small;color:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= +all;color:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +=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-size:small;color:rgb(0,0,0)">=C2=A0=C2=A0=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"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0=C2= +=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= +=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +=C2=A0=C2=A0 /=C2=A0=C2=A0=C2=A0=C2=A0=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-size:small;color:rgb= +(0,0,0)">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)</div><div class=3D"gmail_default" style=3D"font-f= +amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di= +v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se= +rif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default= +" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb= +(0,0,0)">All of these channels can be constructed and set up non-interative= +ly using CTV, and updated interactively. By default payments can happen wit= +h minimal coordination of parties by standard lightning channel updates at = +the leaf nodes, and channels can be rebalanced at higher layers with more p= +articipation.</div><div class=3D"gmail_default" style=3D"font-family:arial,= +helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Now= + let's compare the first-person exit non cooperative scenario across po= +ols:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica= +,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail= +_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:rgb(0,0,0)">CTV-Pool:<br></div><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Wai= +t time: Log(N). At each branch, you must wait for a timeout, and you have t= +o go through log N to make sure there are no updated states. You can trade = +off wait time/fees by picking different radixes.</div><div class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)">TXN Size: Log(N) 1000 people with radix 4 --> 5 wait peri= +ods. 5*4 txn size. Radix 20 --> 2 wait periods. 2*20 txn size.</div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl= +e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0= +)">Accumulator-Pool:</div><div class=3D"gmail_default" style=3D"font-family= +:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Wait Time: O(= +1)</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s= +ans-serif;font-size:small;color:rgb(0,0,0)">TXN Size: Depending on accumula= +tor: 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 mi= +ght be expensive in validation for updates.</div><div class=3D"gmail_defaul= +t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg= +b(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial= +,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div clas= +s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si= +ze:small;color:rgb(0,0,0)">This *seems* like a clear win for Accumulators. = +But not so fast. Let's look at the case where *everyone* exits non coop= +eratively from a payment pool. What is the total work and time?<br></div><d= +iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;= +font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" st= +yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0= +,0)">CTV Pool:</div><div class=3D"gmail_default" style=3D"font-family:arial= +,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Wait time: Log(N)</= +div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-= +serif;font-size:small;color:rgb(0,0,0)">Txn Size: O(N) (no worse than 2x fa= +ctor overhead with radix 2, higher radixes dramatically less overhead)<br><= +/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans= +-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defa= +ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= +rgb(0,0,0)">Accumulator Pool:</div><div class=3D"gmail_default" style=3D"fo= +nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Wait= + time: O(N)</div><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Txn Size: O(N) (bear i= +n mind *maybe* O(N^2) or O(N log N) if we use an sub-optimal accumulator, o= +r validation work may be expensive depending on the new primitive)</div><di= +v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f= +ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty= +le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,= +0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve= +tica,sans-serif;font-size:small;color:rgb(0,0,0)">So in this context, CTV P= +ool 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 doe= +sn't depend on implementation.<br></div><div class=3D"gmail_default" st= +yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0= +,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv= +etica,sans-serif;font-size:small;color:rgb(0,0,0)">Another property that is= + nice about the CTV pool style is the bisecting property. Every time you ha= +ve to do an uncooperative withdrawal, you split the group into R groups. If= + your group is not cooperating because one person is permanently offline, t= +hen Accumulator pools *guarantee* you need to go through a full on-chain re= +demption. Not so with a CTV-style pool, as if you have a single failure amo= +ng [1,2,3,4,5,6,7,8,9,10] channels (let's say channel 8 fails), then wi= +th a radix 4 setup your next steps are:</div><div class=3D"gmail_default" s= +tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,= +0,0)">[1,2,3,4,5,6,7,8,9,10] <br></div><div class=3D"gmail_default" style= +=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= +">[1,2,3,4,5,6,7,X,9,10] </div><div class=3D"gmail_default" style=3D"font-f= +amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">[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:rgb(0,0,0)">[1,2,3,4] 5 6 = +7 X [9,10] </div><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)">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 e= +lse.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica= +,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail= +_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c= +olor:rgb(0,0,0)">With an accumulator based pool, if you re-pool after one f= +ailure, a second failure causes another O(N) work. So then total work in th= +at case is O(N^2). You can improve the design by making the evict in any or= +der option such that you can *kick out* a member in any order, that helps s= +olve 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.<br></div><div class=3D"gmail_default" style=3D"font-f= +amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di= +v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se= +rif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default= +" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb= +(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,= +helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Availability:</div><= +div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= +;font-size:small;color:rgb(0,0,0)">With CTV Pools, you can make a payment i= +f just your immediate conterparty is online in your channel. Opportunistica= +lly, 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.= + <br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic= +a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmai= +l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;= +color:rgb(0,0,0)">With Accumulator pools, you need all parties online to ma= +ke payments.</div><div class=3D"gmail_default" style=3D"font-family:arial,h= +elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class= +=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz= +e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f= +ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Coo= +peration Case:</div><div class=3D"gmail_default" style=3D"font-family:arial= +,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">CTV Pools and Accum= +ulator pools, in a cooperative case, both just act like a N of N multisig.<= +/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans= +-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defa= +ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:= +rgb(0,0,0)">Privacy:</div><div class=3D"gmail_default" style=3D"font-family= +:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Because Accum= +ulator pools always require N signers, it's possible to build a better = +privacy model where N parties are essentially managing a chaumian ecash lik= +e server for updates, giving good privacy of who initiated payments. You *c= +ould* do this with CTV pools as well, but I expect users to prefer making u= +pdates at the 2 party channel layer for low latency, and to get privacy ben= +efits out of the routability of the channels and ability to connect to the = +broader lightning network.</div><div class=3D"gmail_default" style=3D"font-= +family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d= +iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul= +t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg= +b(0,0,0)">Technical Complexity:</div><div class=3D"gmail_default" style=3D"= +font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Bo= +th protocols require new features in Bitcoin. CTV is relatively simple, I w= +ould posit that accumulators=C2=A0+ sighashnoinput are relatively not simpl= +e.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s= +ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:rgb(0,0,0)">The actual protocol design for CTV pools is pretty simple an= +d can be compatible with LN, I already have a rudimentary implementation of= + the required transactions (but not servers).<br></div><div class=3D"gmail_= +default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= +lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family= +:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di= +v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f= +ont-size:small;color:rgb(0,0,0)">Interactivity:</div><div class=3D"gmail_de= +fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo= +r:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:a= +rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In both designs= +, the payment pool can be created non-interactively. This is *super* import= +ant 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:rgb(0,0,0)"><br></d= +iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul= +t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg= +b(0,0,0)">Thanks for reading!</div><div class=3D"gmail_default" style=3D"fo= +nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br>= +</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san= +s-serif;font-size:small;color:rgb(0,0,0)">Jeremy<br></div><div class=3D"gma= +il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small= +;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fam= +ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>= +<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= +f;font-size:small;color:rgb(0,0,0)"><br clear=3D"all"></div><div><div dir= +=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin"= + target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRub= +in" target=3D"_blank"></a></div></div></div><br></div></div> +</blockquote></div> + +--0000000000001bbd7805a7ebada4-- + |