public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Tue, 15 Feb 2022 23:10:19 -0500	[thread overview]
Message-ID: <CAMZUoKm3vQDOQ1PiMBhyJz+m9G+RsDSvZ0k-QwoW5+HMbkUOQw@mail.gmail.com> (raw)
In-Reply-To: <87a6err1h5.fsf@rustcorp.com.au>

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

On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell <rusty@rustcorp.com.au>
wrote:

> Jeremy Rubin <jeremy.l.rubin@gmail.com> writes:
> > Hi Rusty,
> >
> > Please see my post in the other email thread
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
> >
> > The differences in this regard are several, and worth understanding
> beyond
> > "you can iterate CTV". I'd note a few clear examples for showing that
> "CTV
> > is just as powerful" is not a valid claim:
> >
> > 1) CTV requires the contract to be fully enumerated and is non-recursive.
> > For example, a simple contract that allows n participants to take an
> action
> > in any order requires factorially many pre-computations, not just linear
> or
> > constant. For reference, 24! is about 2**80. Whereas for a more
> > interpretive covenant -- which is often introduced with the features for
> > recursion -- you can compute the programs for these addresses in constant
> > time.
> > 2) CTV requires the contract to be fully enumerated: For example, a
> simple
> > contract one could write is "Output 0 script matches Output 1", and the
> set
> > of outcomes is again unbounded a-priori. With CTV you need to know the
> set
> > of pairs you'd like to be able to expand to a-priori
> > 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> > like creating many identical outputs over time but not constraining what
> > those outputs are. E.g., Output 0 matches Input 0, Output 1 matches
> Output
> > 2.
>
> Oh agreed.  It was distinction of "recursive" vs "not recursive" which
> was less useful in this context.
>
> "limited to complete enumeration" is the more useful distinction: it's a
> bright line between CTV and TXHASH IMHO.
>

If TXHASH is limited to requiring the flags be included in the hash (as is
done with sighash) I believe TXHASH has the same "up front" nature that CTV
has.

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

      reply	other threads:[~2022-02-16  4:10 UTC|newest]

Thread overview: 58+ 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
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 [this message]

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=CAMZUoKm3vQDOQ1PiMBhyJz+m9G+RsDSvZ0k-QwoW5+HMbkUOQw@mail.gmail.com \
    --to=roconnor@blockstream.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rusty@rustcorp.com.au \
    /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