public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Daniel Robinson <danrobinson010@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY
Date: Thu, 3 Nov 2016 16:02:33 -0400	[thread overview]
Message-ID: <CAMZUoKmxO51p7y8rXiOF35=7gfg-jTXDZsvgmikjKex7gmVU0g@mail.gmail.com> (raw)
In-Reply-To: <CAD438HsZRZcRWu=++3kuvyA5Ns9cU360utJMCyc6bROT-fdcHg@mail.gmail.com>

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

On Thu, Nov 3, 2016 at 3:37 AM, Daniel Robinson <danrobinson010@gmail.com>
wrote:

> Really cool!
>
> How about "poison transactions," the other covenants use case proposed by
> Möser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also make
> it easier to check fraud proofs, the other prerequisite for poison
> transactions.)
>

I admit I didn't study their poison transactions very carefully.  It seemed
specific to Bitcoin-NG.


> Seems a little wasteful to do those two "unnecessary" signature checks,
> and to have to construct the entire transaction data structure, just to
> verify a single output in the transaction. Any plans to add more flexible
> introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?
>

I used to be hesitant to the idea of adding transaction introspection
operations, because the script design seemed to be deliberately avoiding
doing that.  One of the big takeaways from this work, for me at least, is
that since the transaction data is so easily recoverable anyways, adding
transaction introspection operations isn't really going to provide any more
power to script; it will just save everyone a bunch of work.  There are no
specific plans to put transaction introspection opcodes into Elements at
this moment, but I feel that the door for that possibility is wide open now.

Really minor nit: "Notice that we have appended 0x83 to the end of the
> transaction data"—should this say "to the end of the signature"?
>

Probably should reed "Notice that we have appended 0x83000000 to the end of
the transaction data".  I'll make an update.


>
> On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Right.  There are minor trade-offs to be made with regards to that design
> point of OP_CHECKSIGFROMSTACKVERIFY.  Fortunately this covenant
> construction isn't sensitive to that choice and can be made to work with
> either implementation of OP_CHECKSIGFROMSTACKVERIFY.
>
> On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012@xbt.hk> wrote:
>
> Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different
> way from the Elements. Instead of hashing the data on stack, I directly put
> the 32 byte hash to the stack. This should be more flexible as not every
> system are using double-SHA256
>
> https://github.com/jl2012/bitcoin/commits/mast_v3_master
>
>
> On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> It is possible to implement covenants using two script extensions: OP_CAT
> and OP_CHECKSIGFROMSTACKVERIFY.  Both of these op codes are already
> available in the Elements Alpha sidechain, so it is possible to construct
> covenants in Elements Alpha today.  I have detailed how the construction
> works in a blog post at <https://blockstream.com/2016/
> 11/02/covenants-in-elements-alpha.html>.  As an example, I've constructed
> scripts for the Moeser-Eyal-Sirer vault.
>
> I'm interested in collecting and implementing other useful covenants, so
> if people have ideas, please post them.
>
> If there are any questions, I'd be happy to answer.
>
> --
> Russell O'Connor
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  reply	other threads:[~2016-11-03 20:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 17:30 [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY Russell O'Connor
2016-11-03  3:35 ` Johnson Lau
     [not found] ` <E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>
2016-11-03  4:19   ` Russell O'Connor
2016-11-03  7:37     ` Daniel Robinson
2016-11-03 20:02       ` Russell O'Connor [this message]
2016-11-04 14:35       ` Tim Ruffing
2016-11-07 19:30         ` Jeremy
2016-11-03 17:42 ` Ryan Grant

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='CAMZUoKmxO51p7y8rXiOF35=7gfg-jTXDZsvgmikjKex7gmVU0g@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=danrobinson010@gmail.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