From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EA60EC000E for ; Mon, 5 Jul 2021 13:46:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with UTF8SMTP id CD13B82C4D for ; Mon, 5 Jul 2021 13:46:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=mattcorallo.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with UTF8SMTP id bcyMHZdyVM45 for ; Mon, 5 Jul 2021 13:46:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp1.osuosl.org (Postfix) with UTF8SMTPS id D989D82AC6 for ; Mon, 5 Jul 2021 13:46:25 +0000 (UTC) Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id F2B9960E0AB; Mon, 5 Jul 2021 13:46:21 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1625491263; t=1625492782; bh=rug6ZURQ1CLE1V/DU8ovZmrMNnOEjYaiAIICWjcnP7Y=; h=Date:Subject:To:References:From:In-Reply-To:From; b=WN0z8LQDYmqfmWWyrkdWTK9mOkqiC04gjtF3w2uQE1BV9Pdk7rYd5opIrHlDVdZ4x 9GJn+TUK54UkpwKTamb++K6iaGNt7MjP/+BGcqwjMYcB0cAosno1LbaqSbbd0jFr+n raErOh628vQiM5KSKEtGCtk9PMn8looNdfC2zR9hUlnZlMy6BZlTfmooPKs03WdEa5 lEQ9ej2sUFKqXa/e1wglqu5ebpHFSQIf296jp+7yLzDWoDk5WaorvOtkOioMNRiVpy gY0UzMXdxoyqEsHvU6B9YSi3UVrXoEr3wQD71lMwgSNIfGwHq8eDu/a4fBB7CcvLEu bgkx4ztpx9TZg== Message-ID: <5e694d37-ac49-3c24-26ee-ed2a5580d76d@mattcorallo.com> Date: Mon, 5 Jul 2021 09:46:21 -0400 MIME-Version: 1.0 Content-Language: en-US To: Anthony Towns , Bitcoin Protocol Discussion , Russell O'Connor References: <20210704011341.ddbiruuomqovrjn6@ganymede> <20210704203230.37hlpdyzr4aijiet@ganymede> <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com> <20210705050421.GA31145@erisian.com.au> From: Matt Corallo In-Reply-To: <20210705050421.GA31145@erisian.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 13:46:27 -0000 I find this point to be incredibly important. Indeed I, like several others, have historically been concerned with covenants in the unbounded form. However, as more and more research has been done in what they can accomplish, the weighting of such arguments naturally has to be reduced. More importantly, AJ's point here neuters anti-covanent arguments rather strongly. Matt On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote: > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >