Good morning Jimmy,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Russell,
>
> This is probably a dumb question, but I'd like to get some clarity on your
> 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 now?
> Would it be a single blob that incorporates all the input/output information
> in some hashed manner (like BIP143)? Or would you need separate signatures
> for different parts of the transaction? Or is it something more complicated
> like aggregating multiple signatures over different parts of the transaction?
In order to use `OP_CHECKSIGFROMSTACK` work to allow transaction introspection,
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 field
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 after
the field".
2. In addition, you would require a signature for the transaction in addition
to the transaction parts above.
3. You would ensure that "data before the field" is the correct size, so that
you know "the field" is at the correct location in the transaction.
Alternately you might need to also introspect some other fields in order to
ensure other details like number of inputs, number of outputs, value of 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 `SIGHASH_ALL`).
5. You would use normal `OP_CHECKSIGVERIFY` to ensure that the signature signs
the actual transaction.
6. You would concatenate the supposed parts of the transaction together and
use `OP_CHECKSIGFROMSTACKVERIFY` to ensure that the signature *also* is valid
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 sighash
digest as the actual transaction, and thus is accurate to the transaction.
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, but
also because ensuring that the signature is indeed a `SIGHASH_ALL` signature is
easier (just do the size check).
Alternately you can use some other flag, but you would require the signature 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_CHECKSEQUENCEVERIFY` are both superfluous in a system with `OP_CAT` and
`OP_CHECKSIGFROMSTACK`.
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 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".
> > _______________________________________________
> > 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
