public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy <jlrubin@mit.edu>
To: "Russell O'Connor" <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Date: Fri, 24 May 2019 13:51:21 -0700	[thread overview]
Message-ID: <CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>

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

Hi Russell,

Thanks for this detailed comparison. The COSHV BIP does include a brief
comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more
detailed.


I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's
clearly one of the more flexible options available and would enable a
multitude of new use cases.

When I originally presented my work on congestion control at Jan 2017
BPASE, I also discussed it as an option for covenants. Unfortunately I
think it may be on the edge of too powerful -- there are a lot of use cases
and implications from having a potentially recursive covenant. If you see
my response to Matt in the OP_COSHV BIP thread I classify it as enabling a
non-computationally enumerable set of restrictions.

I think also from a developer point of view working with OP_COSHV is much
much simpler (maybe this can be abstracted) which will lead to increased
adoption. OP_COSHV also uses less per-block bandwidth which also makes it
preferable for a measure intended to decongest blocks. Do you know the
exact byte cost for OP_CHECKSIGFROMSTACK? OP_COSHV scripts, with templating
changes to taproot, can be a single byte. OP_COSHV also has less potential
to have a negative interaction with future opcodes we may want like
OP_PUBKEYTWEAK. While we're getting to an exact spec for the features we
want in Bitcoin scripting, it's hard to sign on to OP_CHECKSIGFROMSTACK
unless there's an exact specification which makes us confident we're
hitting all the points.

If the main complaint about OP_COSHV is that it peeks at surrounding data,
it's also possible to implement it more closely to a multi-byte pushdata
opcode or do the template optimization.

Lastly, as I have previously noted, OP_LEFT is probably safer to implement
than OP_CAT and should be more efficient for OP_CHECKSIGFROMSTACK scripts.

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

  parent reply	other threads:[~2019-05-24 20:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 21:01 [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK Russell O'Connor
2019-05-23 16:59 ` ZmnSCPxj
2019-05-23 22:06   ` Russell O'Connor
2019-05-23 17:36 ` Jimmy Song
2019-05-23 22:00   ` Russell O'Connor
2019-05-24  3:51   ` ZmnSCPxj
2019-05-24  4:15 ` ZmnSCPxj
2019-05-24 15:10 ` Russell O'Connor
2019-05-24 20:51 ` Jeremy [this message]
2019-05-24 23:07   ` Russell O'Connor
2019-05-25  1:08     ` Jeremy
2019-05-25 12:52       ` Russell O'Connor
2019-05-27  7:21 ` Anthony Towns
2019-05-28  3:41   ` ZmnSCPxj
2019-05-29  6:49   ` Russell O'Connor
2019-06-13  8:14 ` Tamas Blummer

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=CAD5xwhgVeTPP23SLrMrvXe6ApZyuuQq4us5z7wrPeJkx1+FSYA@mail.gmail.com \
    --to=jlrubin@mit.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.io \
    /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