path: root/50/6d12e493537058ba954e8e1822b683fee26ef5

Return-Path: <salvatore.ingala@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B5A10C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 30 Jul 2023 21:38:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 95CDE81456
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 30 Jul 2023 21:38:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 95CDE81456
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=hcxIQ9kT
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id odqO3zQqDvNJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 30 Jul 2023 21:38:02 +0000 (UTC)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com
 [IPv6:2607:f8b0:4864:20::d2b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 594A581441
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 30 Jul 2023 21:38:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 594A581441
Received: by mail-io1-xd2b.google.com with SMTP id
 ca18e2360f4ac-790a8c74383so16887039f.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 30 Jul 2023 14:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1690753081; x=1691357881;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=WK4tMIkS0wNU0KYyur6q6toHIm8xLDsH/NeAS4Fyez8=;
 b=hcxIQ9kT/IioBVdArVew1mR/2l4k7brVZ7w361gLioSH4OFTDawVzUzI8nrDQD0Umn
 rfH13LZc3yj1xMvoSkl4CvtwI+vAoPDV9xrw39P1WQ6QH8EEh21csjfaI8RvJWtSs1OJ
 PIIdiaUYiBh/aJKu00ATgXYtfjlwMziFdd4fM/t+L/vg28weMAPUUD/A3C5hIPzQrR1s
 GE4F+pbLhfgkTafVcY8VIQmdJjPMIXZ2z7eNaDQbUYn+slUxQiLbD0JtdbJJsnlKWFU8
 SQUlQOwusxcg9qiTzoAAdbDIz+JKzyE5286Ya6U+QD4C5fCunNE66Qftj/xJnZjdaNAF
 eSeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690753081; x=1691357881;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=WK4tMIkS0wNU0KYyur6q6toHIm8xLDsH/NeAS4Fyez8=;
 b=cavnddVs4i/YajndYXh8Wj1e+IhHDRrHJVflDjSZOl0QPgi9dXa8iQXcwZtYtryvim
 2djdKHLc/w+2p1ChVzVmpWzXgfhchrUdcqpSpPL8ktn+V/egF/C6GTMpmNJo9FPYgoQX
 6kBLNNzxtt0vR79u7ZkpWa82bk2a/AXFenWd3WAqXWWS4WSSQHJoQ7uhkBGZz83wE7FX
 JLcSRvWw4slIr75Qrs9spVCU6+J4Axjrw8Ub9W1yV6TvDyUjzbpjRuQtu7Z1gFQ0TY8N
 eeV4TPM4CiigIDKVj/d3nYwhCcdX4qxQwgIbJ1LBTXI4R+S8ENQrHC+sD1bgCiivDmqB
 iCeA==
X-Gm-Message-State: ABy/qLajolUQhOg8/nOz7SWMEUk1DbD3z+via3cW6cxTlv6G4wTwIU4u
 afR3XHybOo2HzD3YP3TAR3LFsNRlB63qVBOza2HF1ob9X7vzDZS/
X-Google-Smtp-Source: APBJJlEV/3cgC03JDzViZYHvkHlxGNNXE1POYTFcZ2baZdZFwrCNJNRLEWbt3p+aFCz+G9b9qMTSgfj7aEuFVylG29E=
X-Received: by 2002:a05:6e02:1345:b0:348:c294:2b9b with SMTP id
 k5-20020a056e02134500b00348c2942b9bmr5765486ilr.12.1690753080721; Sun, 30 Jul
 2023 14:38:00 -0700 (PDT)
MIME-Version: 1.0
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Sun, 30 Jul 2023 23:37:49 +0200
Message-ID: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c788510601bb207f"
X-Mailman-Approved-At: Sun, 30 Jul 2023 21:50:42 +0000
Subject: [bitcoin-dev] Concrete MATT opcodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jul 2023 21:38:03 -0000

--000000000000c788510601bb207f
Content-Type: text/plain; charset="UTF-8"

Hi all,

I have put together a first complete proposal for the core opcodes of
MATT [1][2].
The changes make the opcode functionally complete, and the
implementation is revised and improved.

The code is implemented in the following fork of the
bitcoin-inquisition repo:

https://github.com/Merkleize/bitcoin/tree/checkcontractverify

Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a
previous early demo for vaults [3].

Please check out the diff [4] if you are interested in the
implementation details. It includes some basic functional tests for
the main cases of the opcode.

## Changes vs the previous draft

These are the changes compared to the initial incomplete proposal:
- OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode
  OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows
  to specify if the opcode operates on an input or an output.
  This also allows inspection of other inputs, that was not possible
  with the original opcodes.
- For outputs, the default behavior is to have the following deferred
  checks mechanism for amounts: all the inputs that have a CCV towards
  the same output, have their input amounts summed, and that act as a
  lower bound for that output's amount.
  A flag can disable this behavior. [*]
- A number of special values of the parameters were defined in order
  to optimize for common cases, and add some implicit introspection.
- The order of parameters is modified (particularly, <data> is at the
  bottom of the arguments, as so is more natural when writing Scripts).

## Semantics

The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:

  <data>, <index>, <pk>, <taptree>, <flags>

The core logic of the opcode is as follows:

"Check if the <index>-th input/output's scriptPubKey is a P2TR
whose public key is obtained from <pk>, (optionally) tweaked with
<data>, (optionally) tap-tweaked with <taptree>".

The following are special values of the parameters:

- if <pk> is empty, it is replaced with a fixed NUMS point. [**]
- if <pk> is -1, it is replaced with the current input's taproot
  internal key.
- if <index> is -1, it is replaced with the current input's index.
- if <data> is empty, the data tweak is skipped.
- if <taptree> is empty, the taptweak is skipped.
- if <taptree> is -1, it is replaced with the current input's root
  of the taproot merkle tree.

There are two defined flags:
- CCV_FLAG_CHECK_INPUT = 1: if present, <index> refers to an input;
  otherwise, it refers to an output.
- CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
  is absent, it disables the deferred checks logic for amounts.

Finally, if both the flags CCV_FLAG_CHECK_INPUT and
CCV_FLAG_IGNORE_OUTPUT_AMOUNT are absent:
  - Add the current input's amount to the <index>-th output's bucket.

After the evaluation of all inputs, it is verified that each output's
amount is greater than or equal to the total amount in the bucket
if that output (validation of the deferred checks).

## Comment

It is unclear if all the special values above will be useful in
applications; however, as each special case requires very little added
code, I tried to make the specs as flexible as possible at this time.

With this new opcode, the full generality of MATT (including the fraud
proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY
and OP_CAT.
However, additional opcodes (and additional introspection) would
surely benefit some applications.

I look forward to your comments, and to start drafting a BIP proposal.

Best,
Salvatore Ingala


[*] - Credits go to James O'Beirne for this approach, taken from his
      OP_VAULT proposal. I cherry-picked the commit containing the
      Deferred Checks framework.
[**] - The same NUMS point suggested in BIP-0341 was used.


References:

[1] - https://merkle.fun/
[2] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
[3] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
[4] -
https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify

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

<div dir=3D"ltr"><div><div><div>Hi all,<br><br>I have put together a first =
complete proposal for the core opcodes of<br>MATT [1][2].<br>The changes ma=
ke the opcode functionally complete, and the<br>implementation is revised a=
nd improved.<br><br>The code is implemented in the following fork of the</d=
iv><div>bitcoin-inquisition repo:<br><br><a href=3D"https://github.com/Merk=
leize/bitcoin/tree/checkcontractverify">https://github.com/Merkleize/bitcoi=
n/tree/checkcontractverify</a><br><br>Therefore, it also includes OP_CHECKT=
EMPLATEVERIFY, as in a<br>previous early demo for vaults [3].<br><br>Please=
 check out the diff [4] if you are interested in the<br>implementation deta=
ils. It includes some basic functional tests for<br>the main cases of the o=
pcode.<br><br>## Changes vs the previous draft<br><br>These are the changes=
 compared to the initial incomplete proposal:<br>- OP_CHECK{IN,OUT}CONTRACT=
VERIFY are replaced by a single opcode<br>=C2=A0 OP_CHECKCONTRACTVERIFY (CC=
V). An additional `flags` parameter allows<br>=C2=A0 to specify if the opco=
de operates on an input or an output.<br>=C2=A0 This also allows inspection=
 of other inputs, that was not possible<br>=C2=A0 with the original opcodes=
.<br>- For outputs, the default behavior is to have the following deferred<=
br>=C2=A0 checks mechanism for amounts: all the inputs that have a CCV towa=
rds<br>=C2=A0 the same output, have their input amounts summed, and that ac=
t as a<br>=C2=A0 lower bound for that output&#39;s amount.<br>=C2=A0 A flag=
 can disable this behavior. [*]<br>- A number of special values of the para=
meters were defined in order<br>=C2=A0 to optimize for common cases, and ad=
d some implicit introspection.<br>- The order of parameters is modified (pa=
rticularly, &lt;data&gt; is at the<br>=C2=A0 bottom of the arguments, as so=
 is more natural when writing Scripts).<br><br>## Semantics<br><br>The new =
OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:<br><br>=C2=A0 &lt=
;data&gt;, &lt;index&gt;, &lt;pk&gt;, &lt;taptree&gt;, &lt;flags&gt;<br><br=
>The core logic of the opcode is as follows:<br><br>&quot;Check if the &lt;=
index&gt;-th input/output&#39;s scriptPubKey is a P2TR<br>whose public key =
is obtained from &lt;pk&gt;, (optionally) tweaked with<br>&lt;data&gt;, (op=
tionally) tap-tweaked with &lt;taptree&gt;&quot;.<br><br>The following are =
special values of the parameters:<br><br>- if &lt;pk&gt; is empty, it is re=
placed with a fixed NUMS point. [**]<br>- if &lt;pk&gt; is -1, it is replac=
ed with the current input&#39;s taproot<br>=C2=A0 internal key.<br>- if &lt=
;index&gt; is -1, it is replaced with the current input&#39;s index.<br>- i=
f &lt;data&gt; is empty, the data tweak is skipped.<br>- if &lt;taptree&gt;=
 is empty, the taptweak is skipped.<br>- if &lt;taptree&gt; is -1, it is re=
placed with the current input&#39;s root<br>=C2=A0 of the taproot merkle tr=
ee.<br><br>There are two defined flags:<br>- CCV_FLAG_CHECK_INPUT =3D 1: if=
 present, &lt;index&gt; refers to an input;<br>=C2=A0 otherwise, it refers =
to an output.<br>- CCV_FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: only defined when _=
CHECK_INPUT<br>=C2=A0 is absent, it disables the deferred checks logic for =
amounts.<br><br>Finally, if both the flags CCV_FLAG_CHECK_INPUT and<br>CCV_=
FLAG_IGNORE_OUTPUT_AMOUNT are absent:<br>=C2=A0 - Add the current input&#39=
;s amount to the &lt;index&gt;-th output&#39;s bucket.<br><br>After the eva=
luation of all inputs, it is verified that each output&#39;s<br>amount is g=
reater than or equal to the total amount in the bucket<br>if that output (v=
alidation of the deferred checks).<br><br>## Comment<br><br>It is unclear i=
f all the special values above will be useful in<br>applications; however, =
as each special case requires very little added<br>code, I tried to make th=
e specs as flexible as possible at this time.<br><br>With this new opcode, =
the full generality of MATT (including the fraud<br>proofs) can be obtained=
 with just two opcodes: OP_CHECKCONTRACTVERIFY<br>and OP_CAT.<br>However, a=
dditional opcodes (and additional introspection) would<br>surely benefit so=
me applications.<br><br>I look forward to your comments, and to start draft=
ing a BIP proposal.</div><div><br>Best,<br>Salvatore Ingala<br><br><br>[*] =
- Credits go to James O&#39;Beirne for this approach, taken from his<br>=C2=
=A0 =C2=A0 =C2=A0 OP_VAULT proposal. I cherry-picked the commit containing =
the<br>=C2=A0 =C2=A0 =C2=A0 Deferred Checks framework.<br>[**] - The same N=
UMS point suggested in BIP-0341 was used.<br><br><br>References:<br><br>[1]=
 - <a href=3D"https://merkle.fun/">https://merkle.fun/</a><br>[2] - <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/0=
21182.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-No=
vember/021182.html</a><br>[3] - <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2023-April/021588.html">https://lists.linuxfoundati=
on.org/pipermail/bitcoin-dev/2023-April/021588.html</a><br>[4] -=C2=A0<a hr=
ef=3D"https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merklei=
ze:bitcoin:checkcontractverify">https://github.com/bitcoin-inquisition/bitc=
oin/compare/24.0...Merkleize:bitcoin:checkcontractverify</a><br></div></div=
></div></div>

--000000000000c788510601bb207f--