Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5BA88C000E for ; Mon, 5 Jul 2021 05:32:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 279E340168 for ; Mon, 5 Jul 2021 05:32:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 kzmZ18gInCw3 for ; Mon, 5 Jul 2021 05:32:42 +0000 (UTC) X-Greylist: delayed 00:28:08 by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2FD37400B5 for ; Mon, 5 Jul 2021 05:32:42 +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 1m0GmQ-0000of-IX; Mon, 05 Jul 2021 15:04:29 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 05 Jul 2021 15:04:21 +1000 Date: Mon, 5 Jul 2021 15:04:21 +1000 From: Anthony Towns To: Russell O'Connor , Bitcoin Protocol Discussion Message-ID: <20210705050421.GA31145@erisian.com.au> References: <20210704011341.ddbiruuomqovrjn6@ganymede> <20210704203230.37hlpdyzr4aijiet@ganymede> <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.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] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin 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: Mon, 05 Jul 2021 05:32:43 -0000 On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O'Connor via bitcoin-dev wrote: > Bear in mind that when people are talking about enabling covenants, we are > talking about whether OP_CAT should be allowed or not. In some sense multisig *alone* enables recursive covenants: a government that wants to enforce KYC can require that funds be deposited into a multisig of "2 2 CHECKMULTISIG", and that "recipient" has gone through KYC. Once deposited to such an address, the gov can refus to sign with gov_key unless the funds are being spent to a new address that follows the same rules. (That's also more efficient than an explicit covenant since it's all off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at that point, so that full nodes are only validating a single pubkey and signature per spend, rather than having to do analysis of whatever the underlying covenant is supposed to be [0]) This is essentially what Liquid already does -- it locks bitcoins into a multisig and enforces an "off-chain" covenant that those bitcoins can only be redeemed after some valid set of signatures are entered into the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens. To some extent, likewise for coins held in exchanges/custodial wallets where funds can be transferred between customers off-chain. You can "escape" from that recursive covenant by having the government (or Liquid functionaries, or exchange admins) change their signing policy of course; but you could equally escape any consensus-enforced covenant by having a hard fork to stop doing consensus-enforcement (cf ETH Classic?). To me, that looks more like a difference of procedure and difficulty, rather than a fundamental difference in kind. Cheers, aj [0] https://twitter.com/pwuille/status/1411533549224693762