path: root/33/f60e55178aea647e08249db3328e3ddc0b5a55

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 29341C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 20:05:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 059EB41594
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 20:05:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZNvswf0gyeX1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 20:05:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [IPv6:2a00:1450:4864:20::22b])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 2659F40469
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Feb 2022 20:05:13 +0000 (UTC)
Received: by mail-lj1-x22b.google.com with SMTP id c15so662376ljf.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 02 Feb 2022 12:05:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=IgKOLaD3HhY1mKyZq5zGkGNbJGnOiuqJw2aYN3dxAPY=;
 b=P5lpm32PKUOZDrl23UiX8XGfI+MCrm/9ylL3Is3dPfa5+gutI7Ve06pjG644N8ecAm
 yP3eZ3EnvcfMa3AqC1apFwmwmsaWqBlXtN4Yikh0M4XDyCso3lCDC1bG/XACY4d5/64p
 +Bh4EmoLCWPwvnvoDl7sH1WX3qU5YpginLkojSOlRooYYCS8u8bDu7IJLwUyD9dQiH7Q
 ldT3OBvDpxZdVtAfyNxSbLNpzRl+uTIqy8xFVnz0zqRoxc5CSd3q4F0/s753ksQp+CoI
 kYbu9ETY3H8CKeuSStLAVueOVfjineMupSdf0e090yFB+4O6VHkCk9useEQ8CqJBeBqJ
 jRMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=IgKOLaD3HhY1mKyZq5zGkGNbJGnOiuqJw2aYN3dxAPY=;
 b=PdJg9SSb0sWTg5n5UPAWFEauDZeEUFHJN4BVlgtlSdAm++rsRTai4+dBes5bbyLb3a
 3joKsh+cFkYuV5JUFx7m+Ftxw+FHzKnz7bNsDxSMvH5jpSxXR2wF4ZkJfXUbRc/ywXqi
 UAHe6SY02pniWY1VEqmW9yRwSq7nf1AoKINDBnsaqYySiabC1OWhGj67J3Lfdg9fg9hz
 b7wAPmzKPo48fC3L7vBGAOdpi9y0imCB0fT6IYIT7njwj5jqXOeaSjOuxyInW1x2Qv/L
 6gmQNmirynpa6cbaH3efpd1M+6aVawE2tR9ngafMx4GClkequk+bYMNuYscscQZ1jaOe
 TXsA==
X-Gm-Message-State: AOAM532aYr8vkO7qjRZ6P9SazRkvuRwtOq4CIRBjyEzQdW64s2PmhGHL
 hbpd/QNom9k8j1bBzZ2W1JnrTMd8LZDd31mKU9eafGEMpT/SDw==
X-Google-Smtp-Source: ABdhPJxKbbSSeTK6l8RTSsgA94L2Swsj1YTFO2yk26clX8TPLYnG3OGduvQ1KWV8LgZxG91JBXPOqa/dgPrg9cNJEVo=
X-Received: by 2002:a2e:a811:: with SMTP id l17mr20586369ljq.81.1643832310297; 
 Wed, 02 Feb 2022 12:05:10 -0800 (PST)
MIME-Version: 1.0
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Wed, 2 Feb 2022 12:04:59 -0800
Message-ID: <CAD5xwhhRsmrzF-veVckxHpEsnmGbmkfkAJf7+T9EQPJNp1gV7w@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ecfc0c05d70e8859"
Subject: [bitcoin-dev] CTV Meeting #2 Summary & Minutes
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: Wed, 02 Feb 2022 20:05:15 -0000

--000000000000ecfc0c05d70e8859
Content-Type: text/plain; charset="UTF-8"

This meeting was held January 25th, 2022. The meeting logs are available
https://gnusha.org/ctv-bip-review/2022-01-25.log

Please review the agenda in conjunction with the notes:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019807.html

Feel free to make any corrections if I did not summarize accurately.

The next meeting is next Tuesday at 12:00 PT. I will attempt to circulate a
pre-meeting agenda draft shortly.

Best,

Jeremy

*Bug Bounty Update:*

   1. Basic Rules set, working to formalize the program.
   2. It turns out that 1 person allocating ~$10k is easy, a multi
   stakeholder organization requires more formality.
   3. 501c3 status / tax deducitbility available.
   4. See here for more details:
   https://docs.google.com/document/d/1pN6YzQ6HlR8t_-ZZoEdTegt88w6gJzCkcA_a4IXpKAo/edit
   5. Rules still subject to change, but issues found under the current
   descriptions awarded in good faith by me/Ariel for now.



*Notes from Feedback Review:*

*Luke's Feedback:*

   1. Sentiment that activation / CTV should be discussed somewhat
   separately.
   2. Sentiment that having more clear cut use cases is good, no agreement
   about what venue / type of document those should be (no disagreement really
   either, just that BIPs might be too formal, but blog posts might not be
   formal enough).


*James' Feedback:*

   1. Sentiment that a minor slowdown isn't problematic, we've done it
   before for other precomputations.
   2. James was to spend a bit more time on benchmarking in a more modern
   segment of the chain (the range he used was slightly irrelevant given low
   segwit adoption period).
   3. *After meeting: James' shows updates for CTV don't cause any notable
   slowdown for current chain segments.*


*Peter's Feedback:*

   1. Denial-of-Service concerns seem largely addressed.
   2. Comment on tests was a result of reviewing outdated branch, not PR.
   3. Main feedback that "sticks" is wanting more use cases to be more clear

I've seen some reviews that almost run into a kind of paradox of choice and
> are turned off by all the different potential applications. This isn't
> necessarily a bad thing. As we've seen with Taproot and now even CTV with
> the DLC post, there are going to be use cases and standards nobody's
> thought of yet, but having them out there all at once can be difficult for
> some to digest



*Sapio*

   1. Sapio can be used today, without CTV.
   2. Main change with CTV is more "non-interactivity".
   3. Need for a more descriptive terms than "non-interactive", e.g.,
   "asynchronous non-blocking", "independently verifiable", "non-stallable".
   4. Composability is cool, but people aren't doing that much composable
   stuff anyways so it's probably under-appreciated.



*Vaults*

   1. Very strong positive sentiment for Vaults.
   2. CTV eliminates "toxic waste" from the setup of vaults with pre-signed
   txns / requirement for a RNG.
   3. CTV/Sapio composability makes vaults somewhat "BIP Resistant" because
   vaults could be customized heavily per user, depending on needs.
   4. CPFP for smart contracts is in not the best state, improving
   CPFP/Package relay important for these designs.
   5. The ability to *prove* vaults constructed correctly w/o toxic waste,
   e.g., 30 years later, is pretty important for high security uses (as
   opposed to assume w/ presigned).
   6. More flexible vaults (e.g., withdraw up to X amount per step v.s.
   fixed X per step) are desirable, but can be emulated by withdrawing X and
   sending it somewhere else (e.g. another vault) without major loss of
   security properties or network load -- more flexible vault covenants have
   greater space/validation costs v.s. simpler CTV ones.



*Congestion Control*

   1. Sentiments shared that no one really cares about this issue and it's
   bad marketing.
   2. Layer 2 to 1 Index "21i" which is how long for a L2 (sidechain,
   exchange, mining pools, etc) to clear all liabilities to end users (CTV
   improves this to 1 block, currently clearing out and Exchange could take
   weeks and also trigger "thundering herd" behaviors whereby if the expected
   time to withdraw becomes too long, you then also need to withdraw).
   3. Anecdotally, Exchanges seem less interested in congestion control,
   Mining Pools and Lightning Channel openers seem more into it.


Main Issues & Answers:

Q: wallet complexity?
A: Wallets largely already need to understand most of the logic for CTV,
should they be rational
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019756.html

Q: uses more space overall
A: Doesn't use more space than existing incentive compatible behavior on
how you might split up txns already, and even if it did, it's a small
constant factor more. See https://utxos.org/analysis/batching_sim/ for more
analysis.

Q: block space is cheap right now, why do we need this?
A: we do not want or expect blockspace to be cheap in the future, we should
plan for that outcome.

Q: What might adoption look like for businesses / how required is their
adoption?
A: Users can request payouts into their own CTV-trees w/o exchanges
knowing. Exchanges do stand to benefit from this, so they might. They will
need to pick a SLA for users to receive until wallet software "catches up"
a bit more. SLA's and a gradual low-change path for changing industry norms
discussed more in https://stephanlivera.com/episode/339/

Q (unanswered): Can we show that CTV is the optimal congestion control?
What else might work?

*Payment Pools*

   1. Basically a Congestion Control + Cooperative Close.
   2. Compose with Channels as leaf nodes.
   3. CoinJoins can be done into payment pools.
   4. There are some high level design questions to ask of any payment pool
   design (see minutes), CTV seems to have OK tradeoffs.
   5. What is the "Dunbar's Number" for how big pools could be? If it's 10
   users, different design tradeoffs can be made than if it is 100.
   6. More study to be needed on fund availability tradeoffs between having
   1 Pool of size O(M) per user, N pools per user of size O(G), etc.
   7. CTV Pools particularly seem suited for participant privacy compared
   to other proposals which require all parties knowing all balances for all
   other parties to be secure.
   8. Need to better model/discuss alternatives and costs of
   failure scenarios, e.g. 1 Failure in a TLUV model could mean O(N log N)
   chainload, unless you precommit to paths for every 1 failure case, 2
   failure case, etc, which then blows up the costs of each transaction in the
   unilateral withdraw case. CTV Pools, being simpler have a bit more
   "symmetry" in kickout costs v.s. unilateral withdrawal.


*General Discussion:*

   1. Template covenants via APO can be made similar cost to CTV with the
   addition of OP_GENERATOR (pushes G to the stack) and OP_CAT via `<half
   sig> OP_G OP_CAT 0x01 OP_G OP_CAT CHECKSIG`, or without CAT by allowing
   checksig to read R and S separately and getting rid of APO 0x01 prefix tags.






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

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">This meeting was held Jan=
uary 25th, 2022. The meeting logs are available=C2=A0<a href=3D"https://gnu=
sha.org/ctv-bip-review/2022-01-25.log" target=3D"_blank">https://gnusha.org=
/ctv-bip-review/2022-01-25.log</a></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">Please review the agenda in conju=
nction with the notes:=C2=A0<a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2022-January/019807.html" target=3D"_blank">https://lis=
ts.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019807.html</a></=
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:#000=
000">Feel free to make any corrections if I did not summarize accurately.</=
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:#000=
000">The next meeting is next=C2=A0Tuesday at 12:00 PT. I will attempt to c=
irculate a pre-meeting agenda draft shortly.</div><div class=3D"gmail_defau=
lt" 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,h=
elvetica,sans-serif;font-size:small;color:#000000">Best,</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000"><b><br></b></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000"><b>Bug Bounty Update:</b></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
ol><li>Basic Rules set, working to formalize the program.<br></li><li>It tu=
rns out that 1 person allocating ~$10k is easy, a multi stakeholder organiz=
ation requires more formality.<br></li><li>501c3 status / tax deducitbility=
 available.<br></li><li>See here for more details:=C2=A0<a href=3D"https://=
docs.google.com/document/d/1pN6YzQ6HlR8t_-ZZoEdTegt88w6gJzCkcA_a4IXpKAo/edi=
t" target=3D"_blank">https://docs.google.com/document/d/1pN6YzQ6HlR8t_-ZZoE=
dTegt88w6gJzCkcA_a4IXpKAo/edit</a></li><li>Rules still subject to change, b=
ut issues found under the current descriptions awarded in good faith by me/=
Ariel for now.<br></li></ol></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"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><b>Notes from Feedback Review:</b></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><b><br></b></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000"><b>Luke&#39;s Feedback:<=
/b></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><ol><li>Sentiment that activation=
 / CTV should be discussed somewhat separately.<br></li><li>Sentiment that =
having more clear cut use cases is good, no agreement about what venue / ty=
pe of document those should be (no disagreement really either, just that BI=
Ps might be too formal, but blog posts might not be formal enough).<br></li=
></ol></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"><b>James&#39; Feedback:</b><br><ol><li>Sentiment that a minor =
slowdown isn&#39;t problematic, we&#39;ve done it before for other precompu=
tations.<br></li><li>James was to spend a bit more time on benchmarking in =
a more modern segment of the chain (the range he used was slightly irreleva=
nt given low segwit adoption period).<br></li><li><i>After meeting: James&#=
39; shows updates for CTV don&#39;t cause any notable slowdown for current =
chain segments.</i><br></li></ol></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
i><br></i></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><b>Peter&#39;s Feedback:</=
b></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000"><ol><li>Denial-of-Service concerns=
 seem largely addressed.<br></li><li>Comment on tests was a result of revie=
wing outdated branch, not PR.<br></li><li>Main feedback that &quot;sticks&q=
uot; is wanting more use cases to be more clear<br></li></ol></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-l=
eft:1ex">I&#39;ve seen some reviews that almost run into a kind of paradox =
of choice and are turned off by all the different potential applications. T=
his isn&#39;t necessarily a bad thing. As we&#39;ve seen with Taproot and n=
ow even CTV with the DLC post, there are going to be use cases and standard=
s nobody&#39;s thought of yet, but having them out there all at once can be=
 difficult for some to digest</blockquote><div><br></div><div><br></div><di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><b>Sapio</b></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><ol><li>Sapio can be used today, without CTV.<br></li><li>=
Main change with CTV is more &quot;non-interactivity&quot;.<br></li><li>Nee=
d for a more descriptive terms than &quot;non-interactive&quot;, e.g., &quo=
t;asynchronous non-blocking&quot;, &quot;independently verifiable&quot;, &q=
uot;non-stallable&quot;.<br></li><li>Composability is cool, but people aren=
&#39;t doing that much composable stuff anyways so it&#39;s probably under-=
appreciated.<br></li></ol></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)"><b>Vaults</b></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><ol><li>Ve=
ry strong positive sentiment for Vaults.<br></li><li>CTV eliminates &quot;t=
oxic waste&quot; from the setup of vaults with pre-signed txns / requiremen=
t for a RNG.<br></li><li>CTV/Sapio composability makes vaults somewhat &quo=
t;BIP Resistant&quot; because vaults could be customized heavily per user, =
depending on needs.<br></li><li>CPFP for smart contracts is in not the best=
 state, improving CPFP/Package relay important for these designs.<br></li><=
li>The ability to *prove* vaults constructed correctly w/o toxic waste, e.g=
., 30 years later, is pretty important for high security uses (as opposed t=
o assume w/ presigned).<br></li><li>More flexible vaults (e.g., withdraw up=
 to X amount per step v.s. fixed X per step) are desirable, but can be emul=
ated by withdrawing X and sending it somewhere else (e.g. another vault) wi=
thout major loss of security properties or network load -- more flexible va=
ult covenants have greater space/validation costs v.s. simpler CTV ones.</l=
i></ol></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></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)"><b>Conges=
tion Control</b></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><ol><li>Sentiment=
s shared that no one really cares about this issue and it&#39;s bad marketi=
ng.<br></li><li>Layer 2 to 1 Index &quot;21i&quot; which is how long for a =
L2 (sidechain, exchange, mining pools, etc) to clear all liabilities to end=
 users (CTV improves this to 1 block, currently clearing out and Exchange c=
ould take weeks and also trigger &quot;thundering herd&quot; behaviors wher=
eby if the expected time to withdraw becomes too long, you then also need t=
o withdraw).<br></li><li>Anecdotally, Exchanges seem less interested in con=
gestion control, Mining Pools and Lightning Channel openers seem more into =
it.<br></li></ol></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)">Main Issues &amp; Answers:</div><br></di=
v><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">Q: </span>wallet complexity<span cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">?</span></div><div><span class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">A: Wallets largely already need to understand most of the logic fo=
r CTV, should they be rational <a href=3D"https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2022-January/019756.html" target=3D"_blank">https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019756.html</a=
></span></div><div><br></div><div>Q: uses more space overall</div><div>A: <=
span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">D</span>oesn&#39;t use more space than =
existing incentive compatible behavior on how you might split up txns alrea=
dy, and even if it did, it&#39;s a small constant factor more<span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><span class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">. See=C2=A0</span></span><a href=3D"https://utxos.org/a=
nalysis/batching_sim/" target=3D"_blank">https://utxos.org/analysis/batchin=
g_sim/</a><span class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"> for more analysis.</span><s=
pan style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"></spa=
n></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sa=
ns-serif"><br></span></div><div><span class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Q: </s=
pan>block<span class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"> </span>s<span class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">pace is cheap right now,=C2=A0</span><span class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">=
why do we need this?</span></div><div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">A=
: we do not want or expect blockspace to be cheap in the future, we should =
plan for that outcome.</div><div class=3D"gmail_default" style=3D"font-fami=
ly: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)">Q: What might adoption look like for bus=
inesses / how required is their adoption?</div><div class=3D"gmail_default"=
><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">A: Users can=
 request payouts into their own CTV-trees w/o=C2=A0</font>exchanges knowing=
. Exchanges do stand to benefit from this, so they might. They will need to=
 pick a SLA for users to receive until wallet software &quot;catches up&quo=
t; a bit more. SLA&#39;s and a gradual low-change path for changing industr=
y norms discussed more in <a href=3D"https://stephanlivera.com/episode/339/=
" target=3D"_blank">https://stephanlivera.com/episode/339/</a></div><div cl=
ass=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)=
">Q (unanswered): Can we show that CTV is the optimal congestion control? W=
hat else might work?</div></div><div>=C2=A0</div><div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)"><b>Payment Pools</b></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><ol><li>Basically a Congestion Control + Cooperative Close.<br></li><li>C=
ompose with Channels as leaf nodes.<br></li><li>CoinJoins can be done into =
payment pools.</li><li>There are some high level design questions to ask of=
 any payment pool design (see minutes), CTV seems to have OK tradeoffs.<br>=
</li><li>What is the &quot;Dunbar&#39;s Number&quot; for how big pools coul=
d be? If it&#39;s 10 users, different design tradeoffs can be made than if =
it is 100.<br></li><li>More study to be needed on fund availability tradeof=
fs between having 1 Pool of size O(M) per user, N pools per user of size O(=
G), etc.<br></li><li>CTV Pools particularly seem suited for participant pri=
vacy compared to other proposals which require all parties knowing all bala=
nces for all other parties to be secure.<br></li><li>Need to better model/d=
iscuss alternatives and costs of failure=C2=A0scenarios, e.g. 1 Failure in =
a TLUV model could mean O(N log N) chainload, unless you precommit to paths=
 for every 1 failure case, 2 failure case, etc, which then blows up the cos=
ts of each transaction in the unilateral withdraw case. CTV Pools, being si=
mpler have a bit more &quot;symmetry&quot; in kickout costs v.s. unilateral=
 withdrawal.<br></li></ol></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)"><b>General Discussion:</b></div><div=
 class=3D"gmail_default"><ol><li><font color=3D"#000000" face=3D"arial, hel=
vetica, sans-serif"><span style=3D"caret-color: rgb(0, 0, 0);">Template cov=
enants via APO can be made similar cost to CTV with the addition of OP_GENE=
RATOR (pushes G to the stack) and OP_CAT via `</span></font>&lt;half sig&gt=
; OP_G OP_CAT 0x01 OP_G OP_CAT CHECKSIG`, or without CAT by allowing checks=
ig to read R and S separately and getting rid of APO 0x01 prefix tags.</li>=
</ol></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><b><br></b></div><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" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
<br></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature"=
 data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https=
://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br></div></d=
iv></div></div>

--000000000000ecfc0c05d70e8859--