Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F0569C000B for ; Thu, 17 Feb 2022 15:15:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CA24C41832 for ; Thu, 17 Feb 2022 15:15:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 DBF6fWRt8MsZ for ; Thu, 17 Feb 2022 15:15:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp4.osuosl.org (Postfix) with ESMTPS id E3CF141547 for ; Thu, 17 Feb 2022 15:15:34 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1nKiVH-00073B-57; Fri, 18 Feb 2022 01:15:32 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 18 Feb 2022 01:15:28 +1000 Date: Fri, 18 Feb 2022 01:15:28 +1000 From: Anthony Towns To: digital vagabond , Bitcoin Protocol Discussion Message-ID: <20220217151528.GC1429@erisian.com.au> References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - 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: Thu, 17 Feb 2022 15:15:36 -0000 On Fri, Feb 11, 2022 at 12:12:28PM -0600, digital vagabond via bitcoin-dev wrote: > Imagine a covenant design that was > flexible enough to create an encumbrance like this: a script specifies a > specific key in a multisig controlled by some authority figure (or a branch > in the script that would allow unilateral control by such an authority), > and the conditions of the covenant would perpetually require than any spend > from the covenant can only be sent to a script involving that key from said > authority, preventing by consensus any removal of that central authorities > involvement in control over that UTXO. > I know that such a walled garden could easily be constructed now with > multisig and restrictions on where coins can be withdrawn to from exchanges > or whatever [...], but I think the important distinction > between such non-consensus system designed to enforce such restrictions and > a recursive covenant to accomplish the same is that in the case of a > multisig/non-consensus based system, exit from that restriction is still > possible under the consensus rules of the protocol. I think that sort of encumberance is already possible: you send bitcoin to an OP_RETURN address and that is registered on some other system as a way of "minting" coins there (ie, "proof of burn") at which point rules other than bitcoin's apply. Bitcoin consensus guarantees the value can't be extracted back out of the OP_RETURN value. I think spacechains effectively takes up this concept for their one-way peg: https://bitcoin.stackexchange.com/questions/100537/what-is-spacechain https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302 (I think spacechains requires a covenant construct to track the single-tx-per-bitcoin-block that commits to the spacechain, but that's not directly used for the BTC value that was pegged into the spacechain) If we didn't have OP_RETURN, you could instead pay to a pubkey that's constructed from a NUMS point / or a pedersen commitment, that's (roughly) guaranteed unspendable, at least until secp256k1 is broken via bitcoin's consensus rules (with the obvious disadvantage that nodes then can't remove these outputs from the utxo set). That was also used for XCP/Counterparty's ICO in 2014, at about 823 uBTC per XCP on average (depending on when you got in it was between 666 uBTC/XCP and 1000 uBTC/XCP apparently), falling to a current price of about 208 uBTC per XCP. It was about 1000 uBTC/XCP until mid 2018 though. https://counterparty.io/news/why-proof-of-burn/ https://github.com/CounterpartyXCP/Documentation/blob/master/Basics/FAQ-XCP.md These seem like they might be bad things for people to actually do (why would you want to be paid to mine a spacechain in coins that can only fall in value relative to bitcoin?), and certainly I don't think we should do things just to make this easier; but it seems more like a "here's why you're hurting yourself if you do this" thing, rather than a "we can prevent you from doing it and we will" thing. Cheers, aj