ZmnSCPxj already observed in [1] that these ops would enable introspection of any field of the transactions and make both `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVERIFY` superfluous. There is much more to this as enumerated in generic terms by Russel O’Connor below and I would like to add a concrete example.
We could implement oracle less difficulty contracts without the need the of a
CISC type OP_WORKVERIFY but instead through resurrection/extension of OP_CAT,
OP_GREATERTHANOREQUAL and introduction of a new RISC opcode
OP_CHECKBLOCKATHEIGHT[3] suggested by Luke Dashjr. Thanks for the pointer to
Nathan Cook [4]
Technically we could resurrect and add them without burning more than one
OP_NOP by redefining it as a prefix (OP_EXTENSION), such as:
OP_EXTENSION OP_CAT would become a two byte opcode pointing to a resurrected
implementation of OP_CAT.
This could be soft forked in.
A concrete oracle less difficulty contract could look like:
It is an european digital call option on target difficulty after maturity and
10 blocks notice period. I gave you reasons while having these would increase
bitcoin's security in [2]
IF
<maturity as block height + 10> CHECKLOCKTIMEVERIFY DROP
<speculator’s key> CHECKSIGVERIFY
ELSE
OP_DUP <maturity as block height - 1> OP_CHECKBLOCKATHEIGHT
OP_LESSTHANEQUAL OP_VERIFY
OP_SWAP OP_CAT OP_CAT OP_HASH256 <contracted target> OP_LESSTHANEQUAL
OP_VERIFY
<miner’s key> CHECKSIGVERIFY
ENDIF
insurance premium could be collected by the seller of the insurance after
maturity + 10 blocks if target difficulty was not reached
<speculator’s signature>
miner would get back its insurance premium plus collateral of the seller if
target difficulty was not reached at maturity. Miner has 10 blocks time after
maturity to claim with:
<maturity block header after prevhash> <maturity block version> <prevhash>
The stack would be in second case processed as:
1: after pushes
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
2: after OP_DUP:
<maturity block prevhash>
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
3: after push
<maturity as block height - 1>
<maturity block prevhash>
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
4: after OP_CHECKBLOCKATHEIGHT OP_VERIFY is successful proving that prevhash is
the block at maturity block height - 1
<maturity block prevhash>
<maturity block version>
<maturity block block header after prevhash>
5: after OP_SWAP
<block version>
<maturity block prevhash>
<block header after prevhash>
6: after OP_CAT
<maturity block version concatenated with maturity prevhash>
<maturity block block header after maturity prevhash>
7: after OP_CAT
<complete block header>
8: after OP_HASH256
<block hash computed for header>
9: after push
<contracted target>
<block hash computed for header>
10: after OP_GREATERTHANOREQUAL OP_VERIFY proves that contracted target was
reached
Tamas Blummer
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.html>
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.html>
[3] https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
<https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki>
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.html>
[5] https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h
<https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h>
> On May 22, 2019, at 23:01, 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
