Date: Thu, 23 May 2019 16:59:15 +0000
To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com>
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Precedence: list

Good morning Russell,

While I am sympathetic to this argument from first principles, as I underst=
and it, it requires that provided witness inputs will become larger, compar=
ed to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`=
.

For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and `OP_CHECKS=
IGFROMSTACK`, I would effectively split the unsigned transaction into its "=
inputs" and "outputs" part, concat them and use `OP_CHECKSIGFROMSTACK` on t=
he chaperone signature, and also use a normal `OP_CHECKSIGVERIFY` on that s=
ame chaperone signature, then dup the "outputs" part and use `OP_CHECKSIGFR=
OMSTACK` 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 (admitted=
ly 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_A=
NYPREVOUT`).
So my witness stack would contain two signatures, and a duplicate of the tr=
ansaction itself, plus a very much complicated script, whereas use of `SIGH=
ASH_ANYPREVOUT` just requires two signatures and a script not much longer t=
han pre-Schnorr multisig scripts.


It seems to me desirable, to try to reduce bandwidth consumption on the Bit=
coin 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 pa=
tterns of usage for that opcode, and *then* to propose those common pattern=
s as specific "optimized" opcodes as a sort of "jet" for Bitcoin itself (bu=
t not `OP_CHECKSIGFROMSTACK` itself).

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Thursday, May 23, 2019 5:01 AM, Russell O'Connor via bitcoin-dev <bitcoi=
n-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 B=
itcoin via new Script operations.=C2=A0 However, I think that these proposa=
ls miss the mark when it comes to how they approach Bitcoin Script and lang=
uage features.
>
> Bitcoin Script appears designed to be a flexible programmable system that=
 provides generic features to be composed to achieve various purposes.=
=C2=A0 Thus, when we design new language features for Script, we should be =
striving, as much as possible, to similarly build general purpose tools whi=
ch 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.=C2=A0 They are both are designed with very =
narrow applications in mind, while also going out of their way to extend th=
e semantic domain of the interpretation of Bitcoin operations in new ways t=
hat complicate their specification.=C2=A0 In the case of SIGHASH_ANYPREVOUT=
, the semantic domain is extended by adding new counters to track the use o=
f various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTHAS=
HVERIFY, it employs a new context-sensitive operation that peeks at the val=
ue of surrounding opcodes.
>
> Instead, I propose that, for the time being, we simply implement OP_CAT a=
nd OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two byte arrays off the st=
ack and pushes their concatenation back onto the stack.=C2=A0 OP_CHECKSIGFR=
OMSTACKVERIFY pops a signature, message, and pubkey off the stack and perfo=
rms 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 Comput=
ation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> +=C2=A0Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned sim=
ply 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 amon=
g 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, t=
he more interesting recursive-covenants remain largely out of reach, with t=
he 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 a=
re pure computational operations on stack values.=C2=A0 The only semantic s=
ide-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the exist=
ing 'sigops_passed' count.=C2=A0 Moreover, I feel that adding these operati=
ons does not preclude adding more specialized opcodes in the future as an o=
ptimization for whatever popular constructions come up, once we know what t=
hose are.
>
> I feel that this style of generic building blocks truly embodies what is =
meant by "programmable money".