Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7DA52C001A for ; Sat, 26 Feb 2022 07:47:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 65F9C60B1D for ; Sat, 26 Feb 2022 07:47:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er9vpQcnDrJc for ; Sat, 26 Feb 2022 07:47:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp3.osuosl.org (Postfix) with ESMTPS id 29F4C60B1A for ; Sat, 26 Feb 2022 07:47:16 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id F2696FBF4C9; Sat, 26 Feb 2022 07:47:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1645861634; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=IH0ob6YNHjK6AvYK5VlxG9fUF+tuNkFvMD/qoC+S2o4=; b=0OcCS8jHt4UCHmZLP5O1ObuzLCSH10hWqZc+QmSQwoihW5KoPtOFa0S4m/P94hGL QdhDyyccqPBLKq+QFzhURdhMW8E6JeLkXdEJzQ7CeFkdfnDkvTS/u057xBm9PvfZ+6b Mr1ETjj0ypMepvyG9NFch6cVAsTkpRIOZuCnPFIgKW9oQrrB9hMN0AYzsYtXHBPcH5L OzcTxIzPLgmi8ZW7GpQSjeK/jem7TIvQpgk1fdDkTMfhkaX7o/0wIs4aLl8Rli61koq C6wQmICo7Xcid4CB/KJBA5Z5rDXLFfoegt7Aaf+AKwuIfVmitp19ChTu9bP6lEUGbDO hKPe7pF9oA== Date: Sat, 26 Feb 2022 08:47:14 +0100 (CET) From: Prayank To: ZmnSCPxj Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_321589_1387632195.1645861634979" X-Mailman-Approved-At: Sat, 26 Feb 2022 08:34:24 +0000 Cc: Bitcoin Dev 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 07:47:18 -0000 ------=_Part_321589_1387632195.1645861634979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ------=_Part_321589_1387632195.1645861634979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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
------=_Part_321589_1387632195.1645861634979--