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
Precedence: list

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
>