MIME-Version: 1.0
References: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
 <99A6BB96-50B4-4894-9EFD-E36047D890E3@dtrt.org>
In-Reply-To: <99A6BB96-50B4-4894-9EFD-E36047D890E3@dtrt.org>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Mon, 7 Aug 2023 10:31:40 +0200
Message-ID: <CAMhCMoEcxJc4Ov3iQyahaBtEcpGmFqN4k2Kg78_2vPXn8B8JQA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="00000000000004986a0602511419"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concrete MATT opcodes
Precedence: list

--00000000000004986a0602511419
Content-Type: text/plain; charset="UTF-8"

Hi Dave,

I apologize for the confusion and the inconsistent use of plurals.
The reason I called it a "complete proposal" is that the opcode is
now functionally complete, unlike the previous attempt where the
approach for the output amount introspection was not yet specified.

The semantics are informally defined in the previous e-mail, and
implemented in the code [1], which is the only formal specification
at this time. I believe the code is now fairly stable and ready to
experiment with.
My own and (hopefully) others' experimentation will help in writing
a more informed BIP proposal in the next few months.

About the plurals: OP_CHECKCONTRACTVERIFY is indeed now a single
opcode that is useful on its own, but I will also be maintaining a
separate branch [2] that contains both OP_CHECKCONTRACTVERIFY and
OP_CAT, which enables the full generality of the MATT proposal.

Best,
Salvatore

[1] -
https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify
[2] - https://github.com/Merkleize/bitcoin/tree/matt

--00000000000004986a0602511419
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Dave,</div><div><br></div><div>I apologize for the=
 confusion and the inconsistent use of plurals.<br>The reason I called it a=
 &quot;complete proposal&quot; is that the opcode is<br>now functionally co=
mplete, unlike the previous attempt where the<br>approach for the output am=
ount introspection was not yet specified.<br><br>The semantics are informal=
ly defined in the previous e-mail, and<br>implemented in the code [1], whic=
h is the only formal specification<br>at this time. I believe the code is=
=C2=A0now fairly stable and ready to<br>experiment with.<br>My own and (hop=
efully) others&#39; experimentation will help in writing<br>a more informed=
 BIP proposal in the next few months.<br><br>About the plurals: OP_CHECKCON=
TRACTVERIFY is indeed now a single<br>opcode that is useful on its own, but=
 I will also be maintaining a<br>separate branch [2] that contains both OP_=
CHECKCONTRACTVERIFY and<br>OP_CAT, which enables the full generality of the=
 MATT proposal.<br><br>Best,<br>Salvatore<br><br>[1] - <a href=3D"https://g=
ithub.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:chec=
kcontractverify" target=3D"_blank">https://github.com/bitcoin-inquisition/b=
itcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify</a><br>[2] - <a=
 href=3D"https://github.com/Merkleize/bitcoin/tree/matt" target=3D"_blank">=
https://github.com/Merkleize/bitcoin/tree/matt</a><br><br></div></div>

--00000000000004986a0602511419--