Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 14C24C001A for ; 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 ; 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 ; 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 ; Sat, 26 Feb 2022 16:19:15 +0000 (UTC) Received: by mail-ej1-x632.google.com with SMTP id a8so16626274ejc.8 for ; 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: In-Reply-To: From: Billy Tetrud Date: Sat, 26 Feb 2022 10:18:55 -0600 Message-ID: To: Prayank , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
>=C2=A0If 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 dr= ivechains are always bad for their users, I don't think that's a go= od enough reason to block things that could allow people to build user-spac= e drivechains, as long as it doesn't negatively affect normal Bitcoin u= sers.=C2=A0
=
>=C2= =A0Drivechains are not a scaling so= lution

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

>= ;=C2=A0Principle of Least Power.
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 style=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?

On Sat, Feb 26, 2022, 02:35 Prayank via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org> wrote:
=20 =20 =20
Good morning ZmnSCPxj,

> 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.


Agree. I would be interested to know what is NOT possible once we have r= ecursive covenants.

= > 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?)


<= div dir=3D"auto">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--