public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Anthony Towns <aj@erisian.com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Russell O'Connor <roconnor@blockstream.com>
Subject: Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
Date: Mon, 5 Jul 2021 09:46:21 -0400	[thread overview]
Message-ID: <5e694d37-ac49-3c24-26ee-ed2a5580d76d@mattcorallo.com> (raw)
In-Reply-To: <20210705050421.GA31145@erisian.com.au>

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
> 


  reply	other threads:[~2021-07-05 13:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 16:31 [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin Jeremy
2021-07-03 17:50 ` Russell O'Connor
2021-07-03 18:30   ` Jeremy
2021-07-03 20:12     ` Russell O'Connor
2021-07-04 17:30       ` Jeremy
2021-07-04 19:03         ` Russell O'Connor
2021-07-06 17:54           ` Jeremy
2021-07-06 18:21             ` Russell O'Connor
2021-07-06 18:53               ` Jeremy
2021-07-04  1:13 ` David A. Harding
2021-07-04 18:39   ` Jeremy
2021-07-04 20:32     ` [bitcoin-dev] Unlimited covenants, was " David A. Harding
2021-07-04 20:50       ` Billy Tetrud
2021-07-05  0:50       ` ZmnSCPxj
2021-07-05  1:02         ` Russell O'Connor
2021-07-05  2:10           ` Russell O'Connor
2021-07-05  2:39             ` ZmnSCPxj
2021-07-05  5:04           ` Anthony Towns
2021-07-05 13:46             ` Matt Corallo [this message]
2021-07-05 13:51               ` Greg Sanders
2022-02-03  6:17               ` Anthony Towns
2021-07-05 17:20         ` Russell O'Connor
2021-07-06  6:25           ` Billy Tetrud
2021-07-06 10:20             ` Sanket Kanjalkar
2021-07-06 11:26             ` Russell O'Connor
2021-07-06 18:36               ` Jeremy
2021-07-07  4:26           ` ZmnSCPxj
2021-07-07  6:12             ` Billy Tetrud
2021-07-07 13:12             ` Russell O'Connor
2021-07-07 14:24               ` Russell O'Connor
2021-07-07 17:26                 ` Jeremy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e694d37-ac49-3c24-26ee-ed2a5580d76d@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox