1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id EA60EC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Russell O'Connor <roconnor@blockstream.com>
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>
From: Matt Corallo <lf-lists@mattcorallo.com>
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 <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: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 <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
>
|
