From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <FADC3B05-60D2-4E41-AA59-6A0C1519C5B1@gmail.com>
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: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Precedence: list


--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
	<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-May/016966.ht=
ml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016966.h=
tml>
[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017019.h=
tml =
<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.ht=
ml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016954.h=
tml>
[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:
>=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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">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.<br =
class=3D"">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.<br class=3D""><br class=3D"">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]<br class=3D""><br class=3D"">Technically we =
could resurrect and add them without burning more than one OP_NOP by =
redefining it as a prefix (OP_EXTENSION), such as:<br class=3D""><br =
class=3D"">OP_EXTENSION OP_CAT would become a two byte opcode pointing =
to a resurrected implementation of OP_CAT.<br class=3D""><br =
class=3D"">This could be soft forked in.<br class=3D""><br class=3D"">A =
concrete oracle less difficulty contract could look like:<br class=3D"">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]<br class=3D""><br class=3D"">IF<br =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span>&lt;maturity as block height + 10&gt; CHECKLOCKTIMEVERIFY DROP<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;speculator=E2=80=99s =
key&gt; CHECKSIGVERIFY<br class=3D"">ELSE<br class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space: pre;">	</span>OP_DUP =
&nbsp;&lt;maturity as block height - 1&gt; OP_CHECKBLOCKATHEIGHT =
OP_LESSTHANEQUAL OP_VERIFY<br class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space: pre;">	</span>OP_SWAP OP_CAT &nbsp;OP_CAT =
&nbsp;OP_HASH256 &lt;contracted target&gt; OP_LESSTHANEQUAL OP_VERIFY<br =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space: pre;">	=
</span>&lt;miner=E2=80=99s key&gt; CHECKSIGVERIFY<br class=3D"">ENDIF<br =
class=3D""><br class=3D"">insurance premium could be collected by the =
seller of the insurance after maturity + 10 blocks if target difficulty =
was not reached<br class=3D""><br class=3D"">&lt;speculator=E2=80=99s =
signature&gt;<br class=3D""><br class=3D"">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:<br class=3D""><br class=3D"">&lt;maturity block header after =
prevhash&gt; &lt;maturity block version&gt; &lt;prevhash&gt;<br =
class=3D""><br class=3D"">The stack would be in second case processed =
as:<br class=3D""><br class=3D"">1: after pushes<br =
class=3D"">&lt;maturity block prevhash&gt;<br class=3D"">&lt;maturity =
block version&gt;<br class=3D"">&lt;maturity block block header after =
prevhash&gt;<br class=3D""><br class=3D"">2: after OP_DUP:<br =
class=3D"">&lt;maturity block prevhash&gt;<br class=3D"">&lt;maturity =
block prevhash&gt;<br class=3D"">&lt;maturity block version&gt;<br =
class=3D"">&lt;maturity block block header after prevhash&gt;<br =
class=3D""><br class=3D"">3: after push<br class=3D"">&lt;maturity as =
block height - 1&gt;<br class=3D"">&lt;maturity block prevhash&gt;<br =
class=3D"">&lt;maturity block prevhash&gt;<br class=3D"">&lt;maturity =
block version&gt;<br class=3D"">&lt;maturity block block header after =
prevhash&gt;<br class=3D""><br class=3D"">4: after OP_CHECKBLOCKATHEIGHT =
OP_VERIFY is successful proving that prevhash is the block at maturity =
block height - 1<br class=3D"">&lt;maturity block prevhash&gt;<br =
class=3D"">&lt;maturity block version&gt;<br class=3D"">&lt;maturity =
block block header after prevhash&gt;<br class=3D""><br class=3D"">5: =
after OP_SWAP<br class=3D"">&lt;block version&gt;<br =
class=3D"">&lt;maturity block prevhash&gt;<br class=3D"">&lt;block =
header after prevhash&gt;<br class=3D""><br class=3D"">6: after =
OP_CAT<br class=3D"">&lt;maturity block version concatenated with =
maturity prevhash&gt;<br class=3D"">&lt;maturity block block header =
after maturity prevhash&gt;<br class=3D""><br class=3D"">7: after =
OP_CAT<br class=3D"">&lt;complete block header&gt;<br class=3D""><br =
class=3D"">8: after OP_HASH256<br class=3D"">&lt;block hash computed for =
header&gt;<br class=3D""><br class=3D"">9: after push<br =
class=3D"">&lt;contracted target&gt;<br class=3D"">&lt;block hash =
computed for header&gt;<br class=3D""><br class=3D"">10: after =
OP_GREATERTHANOREQUAL OP_VERIFY proves that contracted target was =
reached<br class=3D""><br class=3D"">Tamas Blummer<br class=3D""><br =
class=3D""><br class=3D"">[1]&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/0=
16966.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma=
y/016966.html</a><br class=3D"">[2]&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/=
017019.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ju=
ne/017019.html</a><br class=3D"">[3]&nbsp;<a =
href=3D"https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki" =
class=3D"">https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawik=
i</a><br class=3D"">[4]&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/0=
16954.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma=
y/016954.html</a><br class=3D"">[5]&nbsp;<a =
href=3D"https://github.com/bitcoin/bitcoin/blob/master/src/script/script.h=
" =
class=3D"">https://github.com/bitcoin/bitcoin/blob/master/src/script/scrip=
t.h</a><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On May 22, 2019, at 23:01, Russell O'Connor via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div =
dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D"">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.&nbsp; =
However, I think that these proposals miss the mark when it comes to how =
they approach Bitcoin Script and language features.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Bitcoin Script appears =
designed to be a flexible programmable system that provides generic =
features to be composed to achieve various purposes.&nbsp; 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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">I feel the SIGHASH_ANYPREVOUT and =
OP_CHECKOUTPUTHASHVERIFY proposals fail to achieve these design =
goals.&nbsp; 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.&nbsp; 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.&nbsp; In the case of =
OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation =
that peeks at the value of surrounding opcodes.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Instead, I propose that, for the time =
being, we simply implement OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.&nbsp; =
OP_CAT pops two byte arrays off the stack and pushes their concatenation =
back onto the stack.&nbsp; OP_CHECKSIGFROMSTACKVERIFY pops a signature, =
message, and pubkey off the stack and performs a bip-schnorr =
verification on the SHA256 hash of the message.<br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">In concert, these two =
operations enable:</div><div class=3D""><br class=3D""></div><div =
class=3D"">* Oracle signature verification, including discrete log =
contracts.</div><div class=3D"">* Amortized secure multiparty =
computations (see "Amortizing Secure Computation with Penalties" by =
Kumaresan and Bentov).</div><div class=3D"">* Transaction introspection =
including:<br class=3D""></div><div class=3D""><a =
class=3D"gmail_plusreply" =
id=3D"gmail-plusReplyChip-0">+</a>&nbsp;Simulated SIGHASH_ANYPREVOUT, =
which are necessarily chaperoned simply by the nature of the =
construction.<br class=3D""></div><div class=3D""><a =
class=3D"gmail_plusreply" id=3D"gmail-plusReplyChip-1">+</a> Decide if a =
transaction has exactly one input or not. (etc.)</div><div class=3D"">+ =
Weak covenants, which can verify output scripts to see if they are among =
a set of predefined values or verify the output hash.<br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">and =
presumably more applications as well.<br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">All this is accomplished =
by two straightforward opcodes whose semantics are pure computational =
operations on stack values.&nbsp; The only semantic side-effect is that =
OP_CHECKSIGFROMSTACKVERIFY would count towards the existing =
'sigops_passed' count.&nbsp; 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.<br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">I feel that this style of generic =
building blocks truly embodies what is meant by "programmable money".<br =
class=3D""></div></div></div></div></div></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--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--