From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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: Thu, 23 May 2019 16:59:15 +0000 [thread overview]
Message-ID: <-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com> (raw)
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
Good morning Russell,
While I am sympathetic to this argument from first principles, as I understand it, it requires that provided witness inputs will become larger, compared to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`.
For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and `OP_CHECKSIGFROMSTACK`, I would effectively split the unsigned transaction into its "inputs" and "outputs" part, concat them and use `OP_CHECKSIGFROMSTACK` on the chaperone signature, and also use a normal `OP_CHECKSIGVERIFY` on that same chaperone signature, then dup the "outputs" part and use `OP_CHECKSIGFROMSTACK` on the "any prevout"/"noinput" signature.
I would effectively give the transaction to itself as part of the witness, and further, I would also have to very carefully write the script (admittedly the writing of the template could be done once, but it would require far more review than simple usages of the "limited" operations like `SIGHASH_ANYPREVOUT`).
So my witness stack would contain two signatures, and a duplicate of the transaction itself, plus a very much complicated script, whereas use of `SIGHASH_ANYPREVOUT` just requires two signatures and a script not much longer than pre-Schnorr multisig scripts.
It seems to me desirable, to try to reduce bandwidth consumption on the Bitcoin blockchain, including witness data.
Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK` in a federated sidechain (Elements/Liquid) was to try to identify common patterns of usage for that opcode, and *then* to propose those common patterns as specific "optimized" opcodes as a sort of "jet" for Bitcoin itself (but not `OP_CHECKSIGFROMSTACK` itself).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 23, 2019 5:01 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for Bitcoin via new Script operations. However, I think that these proposals miss the mark when it comes to how they approach Bitcoin Script and language features.
>
> Bitcoin Script appears designed to be a flexible programmable system that provides generic features to be composed to achieve various purposes. Thus, when we design new language features for Script, we should be striving, as much as possible, to similarly build general purpose tools which can in turn be used for a variety of purposes.
>
> I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail to achieve these design goals. They are both are designed with very narrow applications in mind, while also going out of their way to extend the semantic domain of the interpretation of Bitcoin operations in new ways that complicate their specification. In the case of SIGHASH_ANYPREVOUT, the semantic domain is extended by adding new counters to track the use of various v0 and v2 signature types. In the case of OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that peeks at the value of surrounding opcodes.
>
> Instead, I propose that, for the time being, we simply implement OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. OP_CAT pops two byte arrays off the stack and pushes their concatenation back onto the stack. OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off the stack and performs a bip-schnorr verification on the SHA256 hash of the message.
>
> In concert, these two operations enable:
>
> * Oracle signature verification, including discrete log contracts.
> * Amortized secure multiparty computations (see "Amortizing Secure Computation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the nature of the construction.
> + Decide if a transaction has exactly one input or not. (etc.)
> + Weak covenants, which can verify output scripts to see if they are among a set of predefined values or verify the output hash.
>
> and presumably more applications as well.
>
> For better or for worse, without an OP_PUBKEYTWEEK operation available, the more interesting recursive-covenants remain largely out of reach, with the exception of a recursive covenant that is only able to send back to its own address, possibly abusing its own TXO value as a state variable.
>
> All this is accomplished by two straightforward opcodes whose semantics are pure computational operations on stack values. The only semantic side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the existing 'sigops_passed' count. Moreover, I feel that adding these operations does not preclude adding more specialized opcodes in the future as an optimization for whatever popular constructions come up, once we know what those are.
>
> I feel that this style of generic building blocks truly embodies what is meant by "programmable money".
next prev parent reply other threads:[~2019-05-23 16:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 21:01 Russell O'Connor
2019-05-23 16:59 ` ZmnSCPxj [this message]
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
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='-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/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