public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "James O'Beirne" <james.obeirne@gmail.com>
To: "David A. Harding" <dave@dtrt.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Fri, 11 Feb 2022 12:42:11 -0500	[thread overview]
Message-ID: <CAPfvXf+q-0JiM+qap9wgUB1FTAeHGio_XeWVBdRwKj-_GffeUQ@mail.gmail.com> (raw)
In-Reply-To: <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

I don't oppose recursive covenants per se, but in prior posts I have
expressed uncertainty about proposals that enable more "featureful"
covenants by adding more kinds of computation into bitcoin script.

Not that anyone here is necessarily saying otherwise, but I am very
interested in limiting operations in bitcoin script to "verification" (vs.
"computation") to the extent practical, and instead encouraging general
computation be done off-chain. This of course isn't a new observation and I
think the last few years have been very successful to that effect, e.g. the
popularity of the "scriptless scripts" idea and Taproot's emphasis on
embedding computational artifacts in key tweaks.

My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that
more logic will live in script than is necessary, and so the burden to
verify the chain may grow and the extra "degrees of freedom" in script may
make it harder to reason about. But I guess at this point there aren't
alternative means to construct new kinds of sighashes that are necessary
for some interesting covenants.

One thing I like about CTV is that it buys a lot of functionality without
increasing the "surface area" of script's design. In general I think there
is a lot to be said for this "jets"-style approach[0] of codifying the
script operations that you'd actually want to do into single opcodes. This
adds functionality while introducing minimal surface area to script, giving
script implementers more flexibility for, say, optimization. But of course
this comes at the cost of precluding experimentation, and probably
requiring more soft-forking. Though whether the place for script
experimentation using more general-purpose opcodes on the main chain is
another interesting debate...

Sorry for going a little off-topic there.

[0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589


On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist).  Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
>
> -Dave
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
> [2]
> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
>     (thanks to AJ who told me about stop energy one time when I was
>     producing it)
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4303 bytes --]

  parent reply	other threads:[~2022-02-11 17:42 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 17:20 [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT Russell O'Connor
2022-01-26 22:16 ` Jeremy
2022-01-27  4:20   ` James Lu
2022-01-27 19:16   ` Russell O'Connor
2022-01-28  0:18     ` James O'Beirne
2022-01-28 13:14       ` Michael Folkson
2022-01-28 14:17         ` Anthony Towns
2022-01-28 16:38           ` Jeremy
2022-01-28 14:13       ` Russell O'Connor
2022-01-28 15:14         ` James O'Beirne
2022-01-29 15:43           ` Russell O'Connor
2022-01-29 17:02             ` Jeremy Rubin
     [not found]             ` <CAD5xwhjHv2EGYb33p2MRS=VSz=ciGwAsiafX1yRHjxQEXfykSA@mail.gmail.com>
2022-01-29 17:14               ` Russell O'Connor
2022-01-31  2:18       ` Anthony Towns
2022-01-28  1:34 ` Anthony Towns
2022-01-28 13:56   ` Russell O'Connor
2022-02-01  1:16     ` Anthony Towns
2022-02-08  2:16       ` Russell O'Connor
2022-02-17 14:27         ` Anthony Towns
2022-02-17 14:50           ` Russell O'Connor
2022-02-08  3:40 ` Rusty Russell
2022-02-08  4:34   ` Jeremy Rubin
2022-02-11  0:55     ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11  3:42       ` Jeremy Rubin
2022-02-11 17:42       ` James O'Beirne [this message]
2022-02-11 18:12         ` digital vagabond
2022-02-12 10:54           ` darosior
2022-02-12 15:59             ` Billy Tetrud
2022-02-17 15:15           ` Anthony Towns
2022-02-18  7:34       ` ZmnSCPxj
2022-02-23 11:28       ` ZmnSCPxj
2022-02-23 18:14         ` Paul Sztorc
2022-02-24  2:20           ` ZmnSCPxj
2022-02-24  6:53         ` Anthony Towns
2022-02-24 12:03           ` ZmnSCPxj
2022-02-26  5:38             ` Billy Tetrud
2022-02-26  6:43               ` ZmnSCPxj
2022-02-27  0:58                 ` Paul Sztorc
2022-02-27  2:00                   ` ZmnSCPxj
2022-02-27  7:25                     ` ZmnSCPxj
2022-02-27 16:59                       ` Billy Tetrud
2022-02-27 23:50                         ` Paul Sztorc
2022-02-28  0:20                     ` Paul Sztorc
2022-02-28  6:49                       ` ZmnSCPxj
2022-02-28  7:55                         ` vjudeu
2022-03-04  8:42                           ` ZmnSCPxj
2022-03-04 13:43                             ` vjudeu
2022-02-28 22:54                         ` Paul Sztorc
2022-03-01  5:39                           ` Billy Tetrud
2022-03-02  0:00                             ` Paul Sztorc
2022-03-04 12:35                               ` Billy Tetrud
2022-03-04 20:06                                 ` Paul Sztorc
2022-02-26  6:00             ` Anthony Towns
2022-02-15  8:45     ` [bitcoin-dev] " Rusty Russell
2022-02-15 18:57       ` Jeremy Rubin
2022-02-15 19:12         ` Russell O'Connor
2022-02-16  2:26         ` Rusty Russell
2022-02-16  4:10           ` Russell O'Connor
2022-02-14  2:40 [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " Lucky Star
2022-02-26  7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud

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=CAPfvXf+q-0JiM+qap9wgUB1FTAeHGio_XeWVBdRwKj-_GffeUQ@mail.gmail.com \
    --to=james.obeirne@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@dtrt.org \
    /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