Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A5A86AF0 for ; Thu, 13 Jun 2019 08:14:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FC75174 for ; Thu, 13 Jun 2019 08:14:07 +0000 (UTC) Received: by mail-wr1-f41.google.com with SMTP id n9so19737251wru.0 for ; Thu, 13 Jun 2019 01:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mxVZb8lcjiQrpjmF3pr0raIcvBiKwwAWF1eeU3DlERM=; b=GxD6NqwFBvsizQDpwCBjJQeaKDRq481jt4G602z6N3droLACf7IkcBhECu1z9osoKc lH3WQoizLNCfN5A1oofz1Utz43M8xdrnKVEjgJ2wWu+nz6M+XLmAaiT8DdjXyMdZknBJ G4qxT/fYraOnY726XYfT4LHINXrX3l0BnQqgL1y81Wg7Uh+53isYd/DoEdOGjKz9QEI6 c9S1xr1NaO+AYd3Nz8RPKZ+OByjspL7BpSPe8KTVUg6Wo9I1b9lpuzKga3kFvp/QubOr tsciz2jiux0ICq743HuWyCdSJDFigwmqf5AVfYB6ehmtnDEdefad5m14DctFhbyIYKlj DzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mxVZb8lcjiQrpjmF3pr0raIcvBiKwwAWF1eeU3DlERM=; b=RgOAjr9Rl8loptehhaNVGUC19Gq6TXsNu4rVVRyLBNVBWwGTLFDpFHJC5/Yu6rMbH9 j7IehrXYBG9pmC981zFNhxlanhtqPpOKarjDTYLVKFe+WOPcN63nv9HNKa7DZVpv+8V8 llElM7AGcWhcTdkMF2q9z5o3QTMyew17YnBCvDiVghuJrrpeoqxLB4AqUu8Ya7xeYprQ ZfIjp9hlJ2Pl3OjVULVJO0U6Wf0CuXf5uFQsajewCLt3eIH/OgCRhlR4XMj0E0jIlZaY pLgFNGqLJ1ymlViUsAkVgSvn+MC1lGRxHTnffIRA4Ea305tzw+RT6DrSNiccWrz72vgp Qhvw== X-Gm-Message-State: APjAAAUsb0DgQsu0SFG32Sb1nxrAIjPuFicMN0b21LuwdtUkE3+DER8q 83LSVP4eq0dEnY9hLmiqDoE= X-Google-Smtp-Source: APXvYqzipgqmjs2S19tABAFULEAit3JSQTJtrRXWXndIvI4iSVR46sBNItxXL+xym6BRxyv6o0pDrA== X-Received: by 2002:a5d:404a:: with SMTP id w10mr40629048wrp.177.1560413645719; Thu, 13 Jun 2019 01:14:05 -0700 (PDT) Received: from p200300dd67196b511d34f5eec60431f6.dip0.t-ipconnect.de (p200300DD67196B511D34F5EEC60431F6.dip0.t-ipconnect.de. [2003:dd:6719:6b51:1d34:f5ee:c604:31f6]) by smtp.gmail.com with ESMTPSA id x3sm2048807wrp.78.2019.06.13.01.14.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 01:14:04 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_33E73E44-2178-4D77-AA3A-F44A391DE819"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 13 Jun 2019 10:14:02 +0200 In-Reply-To: To: Russell O'Connor , Bitcoin Protocol Discussion References: X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 13 Jun 2019 13:26:27 +0000 Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 08:14:08 -0000 --Apple-Mail=_33E73E44-2178-4D77-AA3A-F44A391DE819 Content-Type: multipart/alternative; boundary="Apple-Mail=_15765CC3-F1E4-4D7C-9807-B3057F36F669" --Apple-Mail=_15765CC3-F1E4-4D7C-9807-B3057F36F669 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99Connor 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 CHECKLOCKTIMEVERIFY DROP CHECKSIGVERIFY ELSE OP_DUP OP_CHECKBLOCKATHEIGHT = OP_LESSTHANEQUAL OP_VERIFY OP_SWAP OP_CAT OP_CAT OP_HASH256 = OP_LESSTHANEQUAL OP_VERIFY CHECKSIGVERIFY ENDIF insurance premium could be collected by the seller of the insurance = after maturity + 10 blocks if target difficulty was not reached 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: = The stack would be in second case processed as: 1: after pushes 2: after OP_DUP: 3: after push 4: after OP_CHECKBLOCKATHEIGHT OP_VERIFY is successful proving that = prevhash is the block at maturity block height - 1 5: after OP_SWAP 6: after OP_CAT 7: after OP_CAT 8: after OP_HASH256 9: after push 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.ht= ml = [2] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.h= tml = [3] https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki = [4] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.ht= ml = [5] https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h = > On May 22, 2019, at 23:01, Russell O'Connor via bitcoin-dev = wrote: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > In concert, these two operations enable: >=20 > * 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. >=20 > and presumably more applications as well. >=20 > 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. >=20 > 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. >=20 > 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 --Apple-Mail=_15765CC3-F1E4-4D7C-9807-B3057F36F669 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99Connor 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=E2=80=99s = 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=E2=80=99s 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=E2=80=99s = 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-Ma= y/016966.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ju= ne/017019.html
[3] https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawik= i
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma= y/016954.html
[5] https://github.com/bitcoin/bitcoin/blob/master/src/script/scrip= t.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<= br class=3D"">

= --Apple-Mail=_15765CC3-F1E4-4D7C-9807-B3057F36F669-- --Apple-Mail=_33E73E44-2178-4D77-AA3A-F44A391DE819 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0CBcoACgkQ9nKRxRdx ORxwSgf/TMM26xgNKdWdzeldeJnd2bVfrzrEFXar0RPLoB26gKR4VxzkiTRGZEYn ZS+C0bEjZ5oz0YaIl5x1te9R5LjEnb6EvmJ/WNcpRH6d1RkrxXdM79VSDXkVmtxB 18mtXGtAAYNDkbBb2vUUUfW7LLAwYPayyAzKkQ3GAuNzUOrvDjPBHi908+o4wgPc B8lJUSUalFQ0VK0Yagnc4dp46RsnWBPylMr8/vxwf8r19atHsQuBS3HApbbgdl/V +M+Rfz8M5bb28AoAejy7vCL9G5CW+XUOiZTJsO8+VPCOGuz3MmkEON2RkbqytAyy 09VeTKM7XmULXBHPAca7lJ0F1D0+8w== =448m -----END PGP SIGNATURE----- --Apple-Mail=_33E73E44-2178-4D77-AA3A-F44A391DE819--