From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3A49CC001A for ; Sat, 26 Feb 2022 06:44:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 2950160B04 for ; Sat, 26 Feb 2022 06:44:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, FROM_LOCAL_NOVOWEL=0.5, 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=protonmail.com 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 Sn287rPfobXX for ; Sat, 26 Feb 2022 06:44:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by smtp3.osuosl.org (Postfix) with ESMTPS id 0F769606B0 for ; Sat, 26 Feb 2022 06:44:06 +0000 (UTC) Date: Sat, 26 Feb 2022 06:43:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645857843; bh=9aGziilQk5fRYkTPf/6D6qBha+aSL4L1/tJYyKgxEn4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=pofWpgtpa9upWIcV9elD4mG5+37ep1V/lvJMgHCHhjgEk360CGOzzKWcCQNAMjC6X 7JOtT5Nm+7wLtNHoWa51fllPhSDZ29iD3VKqJu60fOaKjRAn0s2p2r91yHmBiXGZWS FPUUY02PLCMAt21eShh8hXB08gFKiTNwaJHAscvmdjIyh14zi6IPXCuVSHO2ZhPekG Ayp+hoVlDfNv9CQtX6vPUGy3N97W2hV/EOkQpMnKUf6zkn1mTnYJEFENwoDzqhbWvD Zjq/9pbV/7A47vaBj3R2f/KNMhV7s7IvfAD3qBVj1qMzNf5RvBt90xu8dEl4PKFgF3 fEo+4ChpLa81Q== To: Billy Tetrud From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> <20220224065305.GB1965@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion , Anthony Towns 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 06:44:10 -0000 Good morning AJ, > ZmnSCPaj, are you arguing that drivechains=C2=A0are bad for bitcoin or ar= e you arguing that it would be unwise to opt into a drivechain? Those are v= ery different arguments. If drivechains=C2=A0compromised things for normal = bitcoin nodes that ignore drivechains, then I agree that would be serious= =C2=A0reason to reject drivechains=C2=A0outright and reject things that all= ow it to happen. However, if all you're saying is that people can shoot the= mselves in the foot with drivechains, then avoiding drivechains=C2=A0should= not be a significant design consideration for bitcoin but rather for those= who might consider spending their time working on drivechains. Neither. My argument is simply: * If Drivechains are bad for whatever reason, we should not add recursive c= ovenants. * Otherwise, go ahead and add recursive covenants. Drivechains are not a scaling solution [FOOTNOTE 1] and I personally am int= erested only in scaling solutions, adding more non-scaling-useable function= ality is not of interest to me and I do not really care (but I would *prefe= r* if people focus on scaling-useable functionality, like `SIGHASH_NOINPUT`= , `OP_EVICT`, `OP_CTV`, `OP_TLUV` probably without the self-replace capabil= ity). I bring this up simply because I remembered those arguments against Drivech= ains, and as far as I could remember, those were the reasons for not adding= Drivechains. But if there is consensus that those arguments are bogus, then go ahead ---= add Drivechains and/or recursive covenants. I do not intend to utilize them any time soon anyway. My second position is that in general I am wary of adding Turing-completene= ss, due precisely to 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* techniq= ues, currently unknown, which may have negative effects on Bitcoin, or whic= h would be considered undesirable by a significant section of the userbase. Of course, I know of no such technique, but given that a technique (Drivech= ains) 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 n= ow *also* implementable purely in recursive covenants. Of course, that is largely just stop energy, so if there is *now* consensus= that Drivechains are not bad, go ahead, add recursive covenants (but pleas= e can we add `SIGHASH_NOINPUT` and `OP_CTV` first?). Regards, ZmnSCPxj [FOOTNOTE 1] Sidechains are not a scaling solution, or at least, are beaten= in raw scaling by Lightning. Blockchains are inefficient (THAT IS PRECISE= LY THE PROBLEM WHY YOU NEED A SCALING SOLUTION FOR BITCOIN THAT WAS LIKE TH= E FIRST RESPONSE TO SATOSHI ON THE CYPHERPUNK MAILING LIST) and you have to= show your transaction to everyone. While sidechains imply that particular= subsets are the only ones interested in particular transactions, compare h= ow large a sidechain-participant-set would be expected to be, to how many p= eople learn of a payment over the Lightning Network. If you want a sidecha= in to be as popular as LN, then you expect its participant set to be about = as large as LN as well, and on a sidechain, a transaction is published to a= ll sidechain participants, but on the LN, only a tiny tiny tiny fraction of= the network is involved in any payment. Thus LN is a superior scaling sol= ution. Now you might conter-argue that you can have multiple smaller sidec= hains and just use HTLCs to trade across them (i.e. microchains). I would = then counter-counter-argue that bringing this to the most extreme conclusio= n, you would have tons of sidechains with only 2 participants each, and the= n you would pay by transferring across multiple participants in a chain of = HTLCs and look, oh wow, surprise surprise, you just got the Lightning Netwo= rk. LN wins.