Date: Fri, 24 May 2019 03:51:13 +0000
To: Jimmy Song <jaejoon@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <t6W0uozSuBP3lw7_leWuRW28TY9d31o5G8GxHQc4VoDFG3xBX0AKvUvCJMZpfLtlt5S1UGJhJMN6_Nr5MZoWRbxvNRx_-DqBa51EffCjXjI=@protonmail.com>
In-Reply-To: <CAJR7vkqogCzy8_SpCxcAhnEdkS6DRKaDtvJa8Wc-TNGsCcjM5g@mail.gmail.com>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
	<CAJR7vkqogCzy8_SpCxcAhnEdkS6DRKaDtvJa8Wc-TNGsCcjM5g@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 Jimmy,

=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 Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:

> Hi Russell,
>
> This is probably a dumb question, but I'd like to get some clarity on you=
r proposal.
>
> OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.=
 Presumably, the message would then have to get constructed as part of the =
Script execution. What would such a message look like? What, in other words=
, would you be signing and would that be similar to what signatures sign no=
w? Would it be a single blob that incorporates all the input/output informa=
tion in some hashed manner (like BIP143)? Or would you need separate signat=
ures for different parts of the transaction? Or is it something more compli=
cated like aggregating multiple signatures over different parts of the tran=
saction?

In order to use `OP_CHECKSIGFROMSTACK` work to allow transaction introspect=
ion, the message to be signed would be the equivalent of the sighash digest=
 using `SIGHASH_ALL`.

As a general pattern, if you want a SCRIPT that imposes some rule on some f=
ield in the sighash digest of the transaction:

1.  You would require that the transaction be split into three parts, with =
those parts provided in the witness stack.
    One would be "data before the field", then "the field", then "data afte=
r the field".
2.  In addition, you would require a signature for the transaction in addit=
ion to the transaction parts above.
3.  You would ensure that "data before the field" is the correct size, so t=
hat you know "the field" is at the correct location in the transaction.
    Alternately you might need to also introspect some other fields in orde=
r to ensure other details like number of inputs, number of outputs, value o=
f inputs etc. etc. are what you expect.
4.  You would check that the given signature is `SIGHASH_ALL` (most easily =
by checking its size --- proposed Schnorr signatures have a fixed size, and=
 the lack of an extra sighash flags byte means `SIGHASH_ALL` by default, so=
 if the signature is exactly the fixed Schnorr signature size, it is `SIGHA=
SH_ALL`).
5.  You would use normal `OP_CHECKSIGVERIFY` to ensure that the signature s=
igns the actual transaction.
6.  You would concatenate the supposed parts of the transaction together an=
d use `OP_CHECKSIGFROMSTACKVERIFY` to ensure that the signature *also* is v=
alid for that.
    Since you know the signature is valid for the transaction itself, if it=
 *also* is valid for this, then the concatenation of the input "data before=
 the field", "the field", and "data after the field" is exactly the same si=
ghash digest as the actual transaction, and thus is accurate to the transac=
tion.
7.  Finally, you would actually validate the field you want to impose some =
rule on.

`SIGHASH_ALL` is suggested since it allows you to introspect all fields, bu=
t also because ensuring that the signature is indeed a `SIGHASH_ALL` signat=
ure is easier (just do the size check).
Alternately you can use some other flag, but you would require the signatur=
e on the stack to be flagless and concat the flag yourself before using `OP=
_CHECKSIGVERIFY`.

This mechanism is very general and allows SCRIPT to introspect *any* field =
of the transactions.
Indeed, one can argue that `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVE=
RIFY` are both superfluous in a system with `OP_CAT` and `OP_CHECKSIGFROMST=
ACK`.
OF course, these operations are significantly more optimized since they do =
not require that you quine the transaction.

Regards,
ZmnSCPxj


>
> Best,
>
> Jimmy
>
> On Thu, May 23, 2019 at 8:35 AM Russell O'Connor via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
>
> > Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT a=
nd OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for=
 Bitcoin via new Script operations.=C2=A0 However, I think that these propo=
sals miss the mark when it comes to how they approach Bitcoin Script and la=
nguage features.
> >
> > Bitcoin Script appears designed to be a flexible programmable system th=
at 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 fa=
il to achieve these design goals.=C2=A0 They are both are designed with ver=
y 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.=C2=A0 In the case of SIGHASH_ANYPREVO=
UT, the semantic domain is extended by adding new counters to track the use=
 of various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTH=
ASHVERIFY, it employs a new context-sensitive operation that peeks at the v=
alue of surrounding opcodes.
> >
> > Instead, I propose that, for the time being, we simply implement OP_CAT=
 and OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two byte arrays off the =
stack and pushes their concatenation back onto the stack.=C2=A0 OP_CHECKSIG=
FROMSTACKVERIFY pops a signature, message, and pubkey off the stack and per=
forms 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 Comp=
utation with Penalties" by Kumaresan and Bentov).
> > * Transaction introspection including:
> > +=C2=A0Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned s=
imply 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 am=
ong 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 it=
s 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.=C2=A0 The only semantic=
 side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the exi=
sting 'sigops_passed' count.=C2=A0 Moreover, I feel that adding these opera=
tions 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 i=
s meant by "programmable money".
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev