public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream•com>
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
Date: Tue, 6 Jul 2021 07:26:28 -0400	[thread overview]
Message-ID: <CAMZUoKkAUodCT+2aQG71xwHYD8KXeTAdQq4NmXZ4GBe0pcD=9A@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDZ6FhAn+dBf-_yf7YVzRB7NWV7zaKqKYewgZecBxWUx5A@mail.gmail.com>

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

On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud <billy.tetrud@gmail•com> wrote:

> >  when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think about enabling
> covenants, I'm thinking more about OP_CTV (or some similarly specific
> opcode
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>
> ).
>
> > OP_TWEAK
>
> I wasn't able to find anything about what that is. Would you mind
> clarifying what that concept is?
>

In tapscript one can generally recover the current input's scriptPubkey
through sighash introspection via the usual covenant tricks.  This allows
you to make a recursive covenant by spending funds back to the same
identical scriptPubkey.  However, in order for a recursive covenant to be
actually interesting, there needs to be some sort of state update in each
transition.  If there is no state update then sending funds back to itself
is of very limited value.  It will reset the timer on relative locks, but
that is about all.

The "normal" way of writing useful recursive covenants is to modify the
scriptPubkey by changing a fragment of it that contains some sort of
state.  However in order to update a tapscript pubkey one needs to apply
not only hashing, to create a Merkel root, but also to create a tweaked
taproot pubkey that commits to this root.  While script currently comes
with a SHA-256 hashing opcode, there is no opcode that will let you perform
the necessary tweaking to create a taproot scriptPubkey.

But as I mentioned afterwards, there are other places in the UTXO that you
could put data in order to perform a state update.

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

  parent reply	other threads:[~2021-07-06 11:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 16:31 [bitcoin-dev] " 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
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 [this message]
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='CAMZUoKkAUodCT+2aQG71xwHYD8KXeTAdQq4NmXZ4GBe0pcD=9A@mail.gmail.com' \
    --to=roconnor@blockstream$(echo .)com \
    --cc=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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