path: root/76/b1dfcf383c197c3b61cdadddee1a0de72392bc

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 45440C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jul 2021 13:51:37 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id k184so29177352ybf.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
 <20210704011341.ddbiruuomqovrjn6@ganymede>
 <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
 <20210704203230.37hlpdyzr4aijiet@ganymede>
 <5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com>
 <CAMZUoKnVLRLgL1rcq8DYHRjM--8VEUC5kjUbzbY5S860QSbk5w@mail.gmail.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 <gsanders87@gmail.com>
Date: Mon, 5 Jul 2021 21:51:25 +0800
Message-ID: <CAB3F3DuSP5DUj5wLyP1_EC7hnv=THOYxRy0T9iK-FZzJKMJJhA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000099aa1b05c6609a4c"
Cc: Anthony Towns <aj@erisian.com.au>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <recipient> <gov_key> 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

<div dir=3D"ltr">Funny AJ mentions the multisig idea, because I know for a =
fact it&#39;s being used in certain permissioned systems in this exact way.=
 Regulators will dream up these ideas with or without more useful covenants=
!</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Mon, Jul 5, 2021 at 9:46 PM Matt Corallo via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">I find this point to be incredibly important. Indeed I, like sev=
eral others, have historically been concerned with <br>
covenants in the unbounded form. However, as more and more research has bee=
n done in what they can accomplish, the <br>
weighting of such arguments naturally has to be reduced. More importantly, =
AJ&#39;s point here neuters anti-covanent <br>
arguments rather strongly.<br>
<br>
Matt<br>
<br>
On 7/5/21 01:04, Anthony Towns via bitcoin-dev wrote:<br>
&gt; On Sun, Jul 04, 2021 at 09:02:25PM -0400, Russell O&#39;Connor via bit=
coin-dev wrote:<br>
&gt;&gt; Bear in mind that when people are talking about enabling covenants=
, we are<br>
&gt;&gt; talking about whether OP_CAT should be allowed or not.<br>
&gt; <br>
&gt; In some sense multisig *alone* enables recursive covenants: a governme=
nt<br>
&gt; that wants to enforce KYC can require that funds be deposited into<br>
&gt; a multisig of &quot;2 &lt;recipient&gt; &lt;gov_key&gt; 2 CHECKMULTISI=
G&quot;, and that<br>
&gt; &quot;recipient&quot; has gone through KYC. Once deposited to such an =
address,<br>
&gt; the gov can refus to sign with gov_key unless the funds are being spen=
t<br>
&gt; to a new address that follows the same rules.<br>
&gt; <br>
&gt; (That&#39;s also more efficient than an explicit covenant since it&#39=
;s all<br>
&gt; off-chain -- recipient/gov_key can jointly sign via taproot/MuSig at<b=
r>
&gt; that point, so that full nodes are only validating a single pubkey and=
<br>
&gt; signature per spend, rather than having to do analysis of whatever the=
<br>
&gt; underlying covenant is supposed to be [0])<br>
&gt; <br>
&gt; This is essentially what Liquid already does -- it locks bitcoins into=
<br>
&gt; a multisig and enforces an &quot;off-chain&quot; covenant that those b=
itcoins can<br>
&gt; only be redeemed after some valid set of signatures are entered into<b=
r>
&gt; the Liquid blockchain. Likewise for the various BTC-on-Ethereum tokens=
.<br>
&gt; To some extent, likewise for coins held in exchanges/custodial wallets=
<br>
&gt; where funds can be transferred between customers off-chain.<br>
&gt; <br>
&gt; You can &quot;escape&quot; from that recursive covenant by having the =
government<br>
&gt; (or Liquid functionaries, or exchange admins) change their signing<br>
&gt; policy of course; but you could equally escape any consensus-enforced<=
br>
&gt; covenant by having a hard fork to stop doing consensus-enforcement (cf=
<br>
&gt; ETH Classic?). To me, that looks more like a difference of procedure<b=
r>
&gt; and difficulty, rather than a fundamental difference in kind.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; aj<br>
&gt; <br>
&gt; [0] <a href=3D"https://twitter.com/pwuille/status/1411533549224693762"=
 rel=3D"noreferrer" target=3D"_blank">https://twitter.com/pwuille/status/14=
11533549224693762</a><br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000099aa1b05c6609a4c--