path: root/b4/9635b7c795c767ea188d122dbc199af8e8b670

Return-Path: <jtimon@jtimon.cc>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1331EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:23:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id F034C409F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:23:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.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 DW5yHx815dRN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:23:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [IPv6:2607:f8b0:4864:20::b2d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DD308409F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:23:01 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id f38so17376901ybi.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 07 May 2022 06:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=fecbJMS+yvQYeb/ttsJISjfXnG9NR2ABqt5sInrK988=;
 b=l0AuaMy1FvMWuUM+YWNgJB7tksCQqEgiObSpsUBvBr3svrrEG/8b1y9dFXDooq2aWX
 JIyu7mU1TW2jepJ2IsxnMTIp4GoXaDoGeXmkGPTyRZEV3W+Ds6w+ClAAecJ6C85WKYst
 dtcCwQZLCXkE7NoVpbFykPSSCdUCIICevdn3RoCBK2JYHpNIEYDOJZGdk3erXNNXW7N/
 duBfw+etQ0ukE1zRBK84YdE+UZzg6vQ38FvGKlkpeD+X6EHePaD2actS6/351wl2pSrM
 4am1aosC9QPqOIU9sGO2jPeyWl2/LQS20MFJbjGVoFPjo6rFBgGXFnY/rgqlfjy7Tps+
 Op9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=fecbJMS+yvQYeb/ttsJISjfXnG9NR2ABqt5sInrK988=;
 b=ucTUq+eWM7y5DgxKpY35KI3HT+jnUujAxhUtttJgD256YwtJWJcFDU92iTFrqGniuS
 obDxQ3p1G1GAnQXwwK86x13mkTNs4+LyzvaEy0bOyQEGnvkveADGmQ0Vlx3h+RcZD9LY
 Od9C2PeEC+EPAQHYY84EueQYSJ6o0VveR/CwvuVQwqDelHuGZOaB5WUgVrjVxc4YzXii
 G3zWpzHMHUc0mINgjvRKfcgli3fhTM7yFkSWoK816uHu/daJZi0olYZqdHD01uL7MFpy
 IYOuhnrwc7j+ahmd6UvNRy9px0Q7tbZNB+g7SwdmqP/PRRlcaRvz5HpT3SLSgJTnNDns
 i4FA==
X-Gm-Message-State: AOAM530Uq+AlsrNyNfzjFPAWlUsC9CtF8MD27bKNElwPRs9OD7TkR1Hu
 CEZKoXYKEuxICZy3LvhCvHIE6+xcIlYybeRg2vk10wVLMM1eB+J8
X-Google-Smtp-Source: ABdhPJxHLy6U3TKxFtbqflLRVfJiK8Th//l9LFwqbiV4kwjx4VyjdDQDLhjuO2efIKZxo0Ks3PkYJxwW/v0RlY+buIA=
X-Received: by 2002:a25:d1c8:0:b0:648:a463:f2ca with SMTP id
 i191-20020a25d1c8000000b00648a463f2camr6226339ybg.620.1651929780601; Sat, 07
 May 2022 06:23:00 -0700 (PDT)
MIME-Version: 1.0
References: <kbrvpw3Y5y3ko3Wf2VtcywN462JjMW6YjqecduPOXwrek2sR9FkWfSv6G2Fph22UTAAbgII88MtOn1AFo223jjryNAz8YNbbQlFRVQo_HMY=@protonmail.com>
In-Reply-To: <kbrvpw3Y5y3ko3Wf2VtcywN462JjMW6YjqecduPOXwrek2sR9FkWfSv6G2Fph22UTAAbgII88MtOn1AFo223jjryNAz8YNbbQlFRVQo_HMY=@protonmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sat, 7 May 2022 15:22:49 +0200
Message-ID: <CABm2gDqxOtrMrTu2Ovx32USJT2T+6DRpexct1-k3zwEEnsDPMA@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c45f1405de6bdf41"
X-Mailman-Approved-At: Sat, 07 May 2022 21:24:35 +0000
Subject: Re: [bitcoin-dev] CTV BIP Meeting #8 Notes
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: Sat, 07 May 2022 13:23:04 -0000

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

I think people may be scared of potential attacks based on covenants. For
example, visacoin.
But there was a thread with ideas of possible attacks based on covenants.
To me the most scary one is visacoin, specially seeing what happened in
canada and other places lately and the general censorship in the west, the
supposed war on "misinformation" going on (really a war against truth imo,
but whatever) it's getting really scary. But perhaps someone else can be
more scared about a covenant to add demurrage fees to coins or something, I
don't know.

https://bitcointalk.org/index.php?topic=278122

For example, what if Justin Castro, sorry, Justin Trudeu mandated a
visacoin covenant for all withdrawals from canadian exchanges?
What if ursula von der mengele, sorry, von der leyen wants to do the same
in europe?
What if nina Nina Jankowicz decides visacoin covenants are the best way to
"stop misinformation"?

Covenants can enable many attacks on bitcoin, not just new cool features.

Now, perhaps I am crazy for thinking there's a war against truth going on,
I don't know.
Perhaps most devs and bitcoin users love those lying politicians I
mentioned.
Perhaps I'm too biased because my political views. Or perhaps the people
who don't consider Justin a criminal against humanity are biased.

I guess this goes beyond the scope of this mailing list though. Perhaps we
should go back to the bitcoin forums to discuss this kind of thing.





On Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> Summary for the last CTV meeting:
>
> Topics:
>
> 1)APO version of the simple vault
> 2)APO as alternative to CTV
> 3)fiatjaf's CTV spacechain demo
> 4)Compare CTV with other covenant proposals
> 5)Recursive covenants
> 6)Responding to FUD
>
> ===================================================
> APO version of the simple vault
> ===================================================
>
> - It is vulnerable to the half-spend problem, where multiple vaulted
> outputs (of the same denomination) can be spent together, burning all but
> the first to fees. Fixing this requires amending APOAS to cover the current
> input index.
> - The unvault transaction is third-party malleable (it can have more
> inputs added to it). One practical implication is that you can't hand a
> list of the unvault txids to a watchtower, you have to tell them which
> outpoints to watch which is less privacy-preserving. Fixing this requires
> amending APOAS to cover the number of inputs.
> Both of these issues are fixed by the BIP 118 changes suggested by
> darosior (although they still not officially spec'd afaik), which would
> basically make APO have a CTV-equivalent hash mode (minus scriptSig of
> other inputs)
> - simple-apo-vault could use APO-as-spec'd with
> SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend
> problem (but not malleability) and have some other interesting properties,
> like more natural dynamic fees (add inputs+change) and the ability spend
> multiple vaulted outputs together. This would, however, introduce a tx
> pinning attack vector and prevent rate-limited vaults.
>
> ===================================================
> APO as alternative to CTV
> ===================================================
>
> - Current APO is unusable as a CTV alternative, (revised)APO seems to be
> as useful as CTV is (plus some extra flexibility from existing sighash
> flags)
> - Main drawbacks being the additional witness satisfaction cost, the
> network-side full-node validation costs of checking a signature instead of
> just a hash, and not being segwit0-compatible (meaning, among others, not
> quantumphobic-friendly)
> - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and
> CTV-in-bare-spk get you even more savings
> - APO is far from being ready, let alone (revised)APO
> - APOv2 would be both better for Eltoo and better for CTV, since you can
> use a trick to make the signatures smaller
> - "layered commitments" is essential for eltoo to be usable or not is
> unclear. AJ Towns thinks it is required while Christian Decker thinks it is
> not.
>
> ===================================================
> fiatjaf's CTV spacechain demo
> ===================================================
>
> https://github.com/fiatjaf/simple-ctv-spacechain
>
> ===================================================
> Compare CTV with other covenant proposals
> ===================================================
>
> Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really
> actually a defined way to compare them. So one exercise of value would be
> if everyone tries to actually either agree to or come up with their own
> framework for comparing covenants.
>
> Billy Tetrud's email:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html
>
> - Prefers CTV for several reasons. Mainly because of being simple,
> documentation, code, tools, review and testing.
> - Everything else either introduces malleability, infinite recursion, or
> has interactions with other proposed opcodes that could introduce
> potentially undesirable effects like those.
> - Anything involving OP_CAT is out for the time being. There are so many
> things it can enable that it seems most people aren't comfortable adding it
> at the moment.
> - APO wallet vaults seem rather hacky, inefficient, and limited.
> - TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and
> OP_CHECKOUTPUTVERIFY allows recursive covenants
>
> ===================================================
> Recursive covenants
> ===================================================
>
> jamesob:
> I don't particularly understand the aversion to infinite recursion, which
> seems no different than the risk of potentially burning your coins. It's
> not like infinite recursion on bitcoin is some kind of DoS vector or poses
> execution overhead like an Ethereum VM bug might.
>
> rgrant:
> i think people who want recursion for cool stuff are worried that
> pedestrian stuff will prevent it.
>
> jeremyrubin:
> i think people are afraid of weird shit happening, less so of recursion in
> particular
>
> hsjoberg:
> "Recursive covenants" is the boogie man
>
> shesek:
> "recursion" translates to "complex black magic" for nondevs' -- recursion
> is the new turing completeness
>
> ===================================================
> Responding to FUD
> ===================================================
>
> - It could be a good idea to include showing a way to do blacklists in the
> bug bounty offer
> - The potential concerns about recursive covenants have to clearly
> explained so they can be properly examined.
> - An article about CTV myths similar to segwit: :
> https://blog.blockstream.com/en-segwit-myths-debunked/
> - Some users think CTV might delay eltoo
>
> TL;DR
> "The initial resistance came from the Speedy Trial proposal. Then later on
> rumors and FUD started spreading around regarding CTV and covenants."
> - hsjoberg
>
> https://gnusha.org/ctv-bip-review/2022-05-03.log
>
>
> /dev/fd0
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>I think people may be scared of potential attacks bas=
ed on covenants. For example, visacoin.</div><div>But there was a thread wi=
th ideas of possible attacks based on covenants.</div><div>To me the most s=
cary one is visacoin, specially seeing what happened in canada and other pl=
aces lately and the general censorship in the west, the supposed war on &qu=
ot;misinformation&quot; going on (really a war against truth imo, but whate=
ver) it&#39;s getting really scary. But perhaps someone else can be more sc=
ared about a covenant to add demurrage fees to coins or something, I don&#3=
9;t know.<br><br></div><div><a href=3D"https://bitcointalk.org/index.php?to=
pic=3D278122">https://bitcointalk.org/index.php?topic=3D278122</a></div><di=
v><br></div><div>For example, what if Justin Castro, sorry, Justin Trudeu m=
andated a visacoin covenant for all withdrawals from canadian exchanges?</d=
iv><div>What if ursula von der mengele, sorry, von der leyen wants to do th=
e same in europe?</div><div>What if nina Nina Jankowicz decides visacoin co=
venants are the best way to &quot;stop misinformation&quot;?</div><div><br>=
</div><div>Covenants can enable many attacks on bitcoin, not just new cool =
features.<br></div><div><br></div><div>Now, perhaps I am crazy for thinking=
 there&#39;s a war against truth going on, I don&#39;t know. <br></div><div=
>Perhaps most devs and bitcoin users love those lying politicians I mention=
ed.</div><div>Perhaps I&#39;m too biased because my political views. Or per=
haps the people who don&#39;t consider Justin a criminal against humanity a=
re biased.</div><div><br></div><div>I guess this goes beyond the scope of t=
his mailing list though. Perhaps we should go back to the bitcoin forums to=
 discuss this kind of thing.</div><div><br></div><div><br></div><div><br></=
div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div style=3D"font-family:arial;font-size:14px">Hi =
Bitcoin Developers,<br>
<br>
Summary for the last CTV meeting:<br>
<br>
Topics:<br>
<br>
1)APO version of the simple vault<br>
2)APO as alternative to CTV<br>
3)fiatjaf&#39;s CTV spacechain demo<br>
4)Compare CTV with other covenant proposals<br>
5)Recursive covenants<br>
6)Responding to FUD<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
APO version of the simple vault<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
<br>
- It is vulnerable to the half-spend problem, where multiple vaulted output=
s (of the same denomination) can be spent together, burning all but the fir=
st to fees. Fixing this requires amending APOAS to cover the current input =
index.<br>
- The unvault transaction is third-party malleable (it can have more inputs=
 added to it). One practical implication is that you can&#39;t hand a list =
of the unvault txids to a watchtower, you have to tell them which outpoints=
 to watch which is less privacy-preserving. Fixing this requires amending A=
POAS to cover the number of inputs.<br>
Both of these issues are fixed by the BIP 118 changes suggested by darosior=
 (although they still not officially spec&#39;d afaik), which would basical=
ly make APO have a CTV-equivalent hash mode (minus scriptSig of other input=
s)<br>
- simple-apo-vault could use APO-as-spec&#39;d with SIGHASH_SINGLE|SIGHASH_=
ANYONECANPAY, which would solve the half-spend problem (but not malleabilit=
y) and have some other interesting properties, like more natural dynamic fe=
es (add inputs+change) and the ability spend multiple vaulted outputs toget=
her. This would, however, introduce a tx pinning attack vector and prevent =
rate-limited vaults.<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
APO as alternative to CTV<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
<br>
- Current APO is unusable as a CTV alternative, (revised)APO seems to be as=
 useful as CTV is (plus some extra flexibility from existing sighash flags)=
<br>
- Main drawbacks being the additional witness satisfaction cost, the networ=
k-side full-node validation costs of checking a signature instead of just a=
 hash, and not being segwit0-compatible (meaning, among others, not quantum=
phobic-friendly)<br>
- Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and CT=
V-in-bare-spk get you even more savings<br>
- APO is far from being ready, let alone (revised)APO<br>
- APOv2 would be both better for Eltoo and better for CTV, since you can us=
e a trick to make the signatures smaller<br>
- &quot;layered commitments&quot; is essential for eltoo to be usable or no=
t is unclear. AJ Towns thinks it is required while Christian Decker thinks =
it is not.<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
fiatjaf&#39;s CTV spacechain demo<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
<br>
<a href=3D"https://github.com/fiatjaf/simple-ctv-spacechain" target=3D"_bla=
nk">https://github.com/fiatjaf/simple-ctv-spacechain</a><br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
Compare CTV with other covenant proposals<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
<br>
Unlike crypto primitves (e.g., BLS vs Schnorr), there&#39;s not really actu=
ally a defined way to compare them. So one exercise of value would be if ev=
eryone tries to actually either agree to or come up with their own framewor=
k for comparing covenants.<br>
<br>
Billy Tetrud&#39;s email: <a href=3D"https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2022-May/020402.html" target=3D"_blank">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html</a><br>
<br>
- Prefers CTV for several reasons. Mainly because of being simple, document=
ation, code, tools, review and testing.<br>
- Everything else either introduces malleability, infinite recursion, or ha=
s interactions with other proposed opcodes that could introduce potentially=
 undesirable effects like those.<br>
- Anything involving OP_CAT is out for the time being. There are so many th=
ings it can enable that it seems most people aren&#39;t comfortable adding =
it at  the moment.<br>
- APO wallet vaults seem rather hacky, inefficient, and limited.<br>
- TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and OP_CHECKOUTPUTVERIF=
Y allows recursive covenants<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
Recursive covenants<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
<br>
jamesob:<br>
I don&#39;t particularly understand the aversion to infinite recursion, whi=
ch seems no different than the risk of potentially burning your coins. It&#=
39;s not like infinite recursion on bitcoin is some kind of DoS vector or p=
oses execution overhead like an Ethereum VM bug might.<br>
<br>
rgrant:<br>
i think people who want recursion for cool stuff are worried that pedestria=
n stuff will prevent it.<br>
<br>
jeremyrubin:<br>
i think people are afraid of weird shit happening, less so of recursion in =
particular<br>
<br>
hsjoberg:<br>
&quot;Recursive covenants&quot; is the boogie man<br>
<br>
shesek:<br>
&quot;recursion&quot; translates to &quot;complex black magic&quot; for non=
devs&#39; -- recursion is the new turing completeness<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
Responding to FUD<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>
<br>
- It could be a good idea to include showing a way to do blacklists in the =
bug bounty offer<br>
- The potential concerns about recursive covenants have to clearly explaine=
d so they can be properly examined.<br>
- An article about CTV myths similar to segwit: : <a href=3D"https://blog.b=
lockstream.com/en-segwit-myths-debunked/" target=3D"_blank">https://blog.bl=
ockstream.com/en-segwit-myths-debunked/</a><br>
- Some users think CTV might delay eltoo<br>
<br>
TL;DR<br>
&quot;The initial resistance came from the Speedy Trial proposal. Then late=
r on rumors and FUD started spreading around regarding CTV and covenants.&q=
uot;<br>
- hsjoberg<br>
<br>
<a href=3D"https://gnusha.org/ctv-bip-review/2022-05-03.log" target=3D"_bla=
nk">https://gnusha.org/ctv-bip-review/2022-05-03.log</a><br>
<br>
<br>
/dev/fd0<br>

<div style=3D"font-family:arial;font-size:14px">
    <div>

            </div>

            <div>
        Sent with <a href=3D"https://protonmail.com/" rel=3D"noopener noref=
errer" target=3D"_blank">ProtonMail</a> secure email.
    </div>
</div>
</div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c45f1405de6bdf41--