path: root/22/ba33d8ffa2c94b7a5ae823fe9d0a2e7fa6597d

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 14C24C001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 16:19:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 011304015A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 16:19:17 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id THpnc_fqfr-W
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 16:19:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com
 [IPv6:2a00:1450:4864:20::632])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8817D4002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 16:19:15 +0000 (UTC)
Received: by mail-ej1-x632.google.com with SMTP id a8so16626274ejc.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 08:19:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=PhEU+yGCm/aMX5NLhPMeKhEFT831etxDX3r9njyq9zs=;
 b=X4/RL20KG8H7/4MjupV1UB066I55BRgm3XvZdi2TFMYGE/gFYNkELT1HAgP2vg87cR
 s9OIFFIE6JtscnW34jmG5fCcJNUkD47o7DEcAx4v+s2kRStjqQEjOi7sI1bdbRnncuhj
 udJfeZDbt+sD04+InMgVqb+P0rnX9X8m2ng3HO3ybcIWVxKUFg9mEnYu6zpYJouG/WZq
 55WlMo0PwuDYjT1Pr3zc7yc0GkR+DY+oflFp1L3Mrba7IXyrY1ELxamMZ99VRJHDz+Kl
 myx6D//bnp8GAC0/gwpAATSoedkMiaJE141t//QNTpQqDk84chA7D8wzo7HHE3bXHWZF
 2Phw==
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:cc;
 bh=PhEU+yGCm/aMX5NLhPMeKhEFT831etxDX3r9njyq9zs=;
 b=c1KIi1Y4Ng9C5RGLMkTRBsLGlm46cCprZProuJkVDdVDNxZy3OZise0B2i0reB9TgW
 2UVOcEai8+Q6OKbvaCD1zpz3eGfe7sClaVlIsv8xLU3HD06h6aQ73+k3P3PgbZpHCzxx
 +K8ERHNf5vquIjAQChVAAAE+xz7rmu6PtDaHEXz1dH+jrhtolXofjUabQw44jnSs6w24
 RDIrYFY4BVUNU/Gs6Y/Q0/F/01AEVsm+mJlBTsMCLs9e9rPrnlKYBpSHecRIz4s5obwr
 FVhS4I3U4OSJSJ08iNszG2uRiB/4TV8W4yAaRJyNn1ch0TY2VCs4ldKsKDpwkxChJAvk
 8hsg==
X-Gm-Message-State: AOAM532yzY4lQfyOxa8BkGff4qf+uSch0PGBRRzn1Hod6av7s1gpqtd8
 wTKe3u64NZLvsSa6XY2t8jCtHAj54GR4CDHt28B0GMmq
X-Google-Smtp-Source: ABdhPJzUUrIno5J4scOnSw+UVffGwjdYTLeFhUs6R7vfpfc0kbLiRhQADpKohSTC38RGZ4xlebX3eFbYHwVBa3GoS/Y=
X-Received: by 2002:a17:906:80c7:b0:6cf:9c76:1404 with SMTP id
 a7-20020a17090680c700b006cf9c761404mr9739879ejx.207.1645892353410; Sat, 26
 Feb 2022 08:19:13 -0800 (PST)
MIME-Version: 1.0
References: <MwozrvU--3-2@tutanota.de>
In-Reply-To: <MwozrvU--3-2@tutanota.de>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 26 Feb 2022 10:18:55 -0600
Message-ID: <CAGpPWDb6WVQ=VPMV8EJsuajck-uVPxET_NL-x1=HksDijiKuRg@mail.gmail.com>
To: Prayank <prayank@tutanota.de>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001073cd05d8ee2d16"
X-Mailman-Approved-At: Sat, 26 Feb 2022 17:31:38 +0000
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
 or the absence thereof,
 was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
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, 26 Feb 2022 16:19:17 -0000

--0000000000001073cd05d8ee2d16
Content-Type: text/plain; charset="UTF-8"

> If Drivechains are bad for whatever reason, we should not add recursive
covenants.

Bad "for who" was the crux of my question to you. Even if drivechains are
always bad for their users, I don't think that's a good enough reason to
block things that could allow people to build user-space drivechains, as
long as it doesn't negatively affect normal Bitcoin users.

> Drivechains are not a scaling solution

I generally agree, more of a laboratory where many things (including
scaling solutions) can be tested.

> Principle of Least Power.
A concern is that, since it turns out recursive covenants are sufficient to
implement Drivechains, recursive covenants may also enable *other*
techniques, currently unknown, which may have negative effects on Bitcoin,
or which would be considered undesirable by a significant section of the
userbase.

I think the principle of least power is a good one, but it cannot be dogma.
I think your point about unknown consequences is reasonable and a study on
that kind of thing would be quite valuable. The community has discussed it
multiple times in the past, and so at least some thought has gone into it,
with nothing very strong in opposition that I know of. Has anyone made a
good summary/study of the kinds of things recursive covenants allows?

On Sat, Feb 26, 2022, 02:35 Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning ZmnSCPxj,
>
> > Of course, I know of no such technique, but given that a technique
> (Drivechains) which before would have required its own consensus change,
> turns out to be implementable inside recursive covenants, then I wonder if
> there are other things that would have required their own consensus change
> that are now *also* implementable purely in recursive covenants.
>
>
> Agree. I would be interested to know what is NOT possible once we have
> recursive covenants.
>
> > if there is *now* consensus that Drivechains are not bad, go ahead, add
> recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV`
> first?)
>
>
> Agree and I think everything can be done in separate soft forks.
>
>
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto">&gt;=C2=A0<span style=
=3D"font-size:12.8px">If Drivechains are bad for whatever reason, we should=
 not add recursive covenants.</span><div dir=3D"auto"><span style=3D"font-s=
ize:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"font-size:12.=
8px">Bad &quot;for who&quot; was the crux of my question to you. Even if dr=
ivechains are always bad for their users, I don&#39;t think that&#39;s a go=
od enough reason to block things that could allow people to build user-spac=
e drivechains, as long as it doesn&#39;t negatively affect normal Bitcoin u=
sers.=C2=A0</span></div><div dir=3D"auto"><span style=3D"font-size:12.8px">=
<br></span></div><div dir=3D"auto"><span style=3D"font-size:12.8px">&gt;=C2=
=A0</span><span style=3D"font-size:12.8px">Drivechains are not a scaling so=
lution</span></div><div dir=3D"auto"><span style=3D"font-size:12.8px"><br><=
/span></div><div dir=3D"auto"><span style=3D"font-size:12.8px">I generally =
agree, more of a laboratory where many things (including scaling solutions)=
 can be tested.</span></div><div dir=3D"auto"><span style=3D"font-size:12.8=
px"><br></span></div><div dir=3D"auto"><span style=3D"font-size:12.8px">&gt=
;=C2=A0</span><span style=3D"font-size:12.8px">Principle of Least Power.</s=
pan></div><span style=3D"font-size:12.8px">A concern is that, since it turn=
s out recursive covenants are sufficient to implement Drivechains, recursiv=
e covenants may also enable *other* techniques, currently unknown, which ma=
y have negative effects on Bitcoin, or which would be considered undesirabl=
e by a significant section of the userbase.</span></div><div dir=3D"auto"><=
span style=3D"font-size:12.8px"><br></span></div><div dir=3D"auto"><span st=
yle=3D"font-size:12.8px">I think the principle of least power is a good one=
, but it cannot be dogma. I think your point about unknown consequences is =
reasonable and a study on that kind of thing would be quite valuable. The c=
ommunity has discussed it multiple times in the past, and so at least some =
thought has gone into it, with nothing very strong in opposition that I kno=
w of. Has anyone made a good summary/study of the kinds of things recursive=
 covenants allows?</span></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Sat, Feb 26, 2022, 02:35 Prayank via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noref=
errer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div>
<div>Good morning ZmnSCPxj,<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">&gt; Of course, I know of no such technique, but given that a tec=
hnique (Drivechains) which before would have required its own consensus cha=
nge, turns out to be implementable inside recursive covenants, then I wonde=
r if there are other things that would have required their own consensus ch=
ange that are now *also* implementable purely in recursive covenants.<br></=
div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Agree. I would be interested to know what is NOT possible once we have r=
ecursive covenants.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
&gt; if there is *now* consensus that Drivechains are not bad, go ahead, ad=
d recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV`=
 first?)<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Agree and I think everything can be done in separate soft =
forks.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><br></div><div><br></div><div>-- <br></div><div>Prayank<br></div=
><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div>  </div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</div>

--0000000000001073cd05d8ee2d16--