From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 45440C000E for ; Mon, 5 Jul 2021 13:51:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2433C403E4 for ; Mon, 5 Jul 2021 13:51:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ROnefkzMZZut for ; Mon, 5 Jul 2021 13:51:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by smtp4.osuosl.org (Postfix) with ESMTPS id A0B24403DD for ; Mon, 5 Jul 2021 13:51:37 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id k184so29177352ybf.12 for ; Mon, 05 Jul 2021 06:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2LoGEjTJyDzsI5X+pdWWcS8o6n1Gqr9uYGFeqXyoQMU=; b=eYd9e9eliBHcQMglhvvpJiziT7CGNbCUP+BE9HfcYUTgNi4bZR9XAZWDc1MlXDU8/M V/tXVxiZtngOBnzj+WCnZ/BDKLkp+UmMCOyKKK77fjo5QDH9gsCcf/cAk6Z7TtOIVezO GDuE7oR6BIHcmiI1QULBcu+tNcBW/k3OlXx6+gyvmnRb+CyOD0qalLCK+s1GHnBmo3zp BOI1wf4qLTWgZdgNDdJ0PSacHfrYVgtJ/Dav7n7+DJzRothduF06kQqE3pqIe/jVpwQr tEgy0Hy0rquh88oJDopcLHDKbg4WT4qnLDpEzKzbSB6rdK5ctcN0jNHmysHRtANyY9GO 0e0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2LoGEjTJyDzsI5X+pdWWcS8o6n1Gqr9uYGFeqXyoQMU=; b=QRqiedun3L/fSOvcyivJcJuLXSkrgkas/KOjR18kBJpbjA04Se/wL68h67n4vPWBhW 3U5dUoThgWVMiRZhGJy+R+X/8kTdBnHr/XqOMaI6P3ioLDLZLvGaHf1Tz4U3Eh1yJ1Sy GrjgtY6vVK0NAAhG7wVQQ7JSRC9td6zUVyGAuTIpghMXhIiBhGcRX1HaF0FngXpXcqwF qgLo+FpyZDB9Le14lU5HqOYURKrjWRJCWhw/ryQcMT0ultSKiWE3e5WkNbBVUVIYEqN1 2wClZt9NrNhHw7S9M+6WL7IneyYberY+NpWSwcy3km+jRgXboQ3/tsNB/SP27cC/WlI/ pJNQ== X-Gm-Message-State: AOAM5315e+v1wVqeyKE7Xuyz6/lFxdk/dh0C9maslRJVl+UY3uLCu24+ mGpx3zENPm/JuwQJIprN40n1eCyhr9vIOiThZ2E= X-Google-Smtp-Source: ABdhPJwNcVL/SwW4Trt4J99XwsOE34VeU0PCoOy6oW+zdD2/IuHbnF+z29Xz+FKAB1qy/9cXlCFyJHtZW8kAbJ+uCDA= X-Received: by 2002:a25:60d7:: with SMTP id u206mr18068048ybb.468.1625493096473; Mon, 05 Jul 2021 06:51:36 -0700 (PDT) MIME-Version: 1.0 References: <20210704011341.ddbiruuomqovrjn6@ganymede> <20210704203230.37hlpdyzr4aijiet@ganymede> <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com> <20210705050421.GA31145@erisian.com.au> <5e694d37-ac49-3c24-26ee-ed2a5580d76d@mattcorallo.com> In-Reply-To: <5e694d37-ac49-3c24-26ee-ed2a5580d76d@mattcorallo.com> From: Greg Sanders Date: Mon, 5 Jul 2021 21:51:25 +0800 Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000099aa1b05c6609a4c" Cc: Anthony Towns 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:51:39 -0000 --00000000000099aa1b05c6609a4c Content-Type: text/plain; charset="UTF-8" Funny AJ mentions the multisig idea, because I know for a fact it's being used in certain permissioned systems in this exact way. Regulators will dream up these ideas with or without more useful covenants! On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000099aa1b05c6609a4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Funny AJ mentions the multisig idea, because I know for a = fact it's being used in certain permissioned systems in this exact way.= Regulators will dream up these ideas with or without more useful covenants= !

On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfound= ation.org> wrote:
I find this point to be incredibly important. Indeed I, like sev= eral others, have historically been concerned with
covenants in the unbounded form. However, as more and more research has bee= n 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 bit= coin-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 governme= nt
> that wants to enforce KYC can require that funds be deposited into
> a multisig of "2 <recipient> <gov_key> 2 CHECKMULTISI= G", 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 spen= t
> 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 b= itcoins 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<= br> > 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/14= 11533549224693762
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000099aa1b05c6609a4c--