MIME-Version: 1.0
References: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
 <CAD3i26AxcRCewX7vt5KV9vQp_mD=DaH1GEmqQQ1Ct8v_oW-WXQ@mail.gmail.com>
In-Reply-To: <CAD3i26AxcRCewX7vt5KV9vQp_mD=DaH1GEmqQQ1Ct8v_oW-WXQ@mail.gmail.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Wed, 9 Aug 2023 10:38:48 +0200
Message-ID: <CAMhCMoEoSiGPBczQerBe1TDJvo2Gkf4gbXOPUayKkNLsC_y4SQ@mail.gmail.com>
To: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000038de960602796918"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concrete MATT opcodes
Precedence: list

--00000000000038de960602796918
Content-Type: text/plain; charset="UTF-8"

Hi Johan,

Thanks a lot for the comments, and the independent implementation!

> - For the opcode parameter ordering, it feels unnatural for the two
> tweaks (data, taptree) to be separated by the internal key. A more
> natural ordering of parameters IMO would be (of course this is all
> subjective):
> <data> <taptree> <internalkey> <index> <flags> OP_CCV.
>
> If you disagree, I would love some rationale for the ordering you
> chose! (looks like you also changed it again after your last post?).

The main concern for the reordering was to put <data> at the bottom,
as that's typically passed via the witness stack.

I put the <index> right next, as I suspect there are use cases for
specifying via the witness what is the input index where a certain
(CCV-encumbered) UTXO is to be found, or which output should funds
be sent to, instead of hard-coding this in the script. This might
help in designing contracts that are more flexible in the way they
are spent, for example by allowing batching their transactions.

Instead, I expect the other parameters to almost always be hardcoded,
or propagated from the current input with the <-1> special values.

I agree that your ordering is more aesthetically pleasing, though.

> I'm wondering what other use cases you had in mind for the deferred
> output amount check? Maybe I have missed something, but if not it
> would perhaps be better to leave out the amount preservation check, or
> go the extra mile and propose a more powerful amount introspection
> machinery.

Yes, the deferred output amount check is not enough for coinpools;
however, it comes at no cost if we have a <flags> parameter anyway,
as OP_2 (value for CCV_IGNORE_OUTPUT_AMOUNT) is a single byte opcode.

The intent of preserving amounts for many-to-one contracts (vaults),
or the one-to-one cases (channels, any 2-party contract, etc.) seems
common enough to deserve 1 bit in the flags, IMHO.
Efforts to define and add explicit introspection to cover your
(exciting!) use cases can proceed independently, but I don't think
they would nullify the advantages of this (optional) feature of CCV.

Best,
Salvatore

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Johan,<br><br>Thanks a lot for the com=
ments, and the independent=C2=A0implementation!<br><br>&gt; - For the opcod=
e parameter ordering, it feels unnatural for the two<br>&gt; tweaks (data, =
taptree) to be separated by the internal key. A more<br>&gt; natural orderi=
ng of parameters IMO would be (of course this is all<br>&gt; subjective):<b=
r>&gt; &lt;data&gt; &lt;taptree&gt; &lt;internalkey&gt; &lt;index&gt; &lt;f=
lags&gt; OP_CCV.<br>&gt;<br>&gt; If you disagree, I would love some rationa=
le for the ordering you<br>&gt; chose! (looks like you also changed it agai=
n after your last post?).<br><br>The main concern for the reordering was to=
 put &lt;data&gt; at the bottom,<br>as that&#39;s typically passed via the =
witness stack.<br><br>I put the &lt;index&gt; right next, as I suspect ther=
e are use cases for<br>specifying via the witness what is the input index w=
here a certain<br>(CCV-encumbered) UTXO is to be found, or which output sho=
uld funds<br>be sent to, instead of hard-coding this in the script. This mi=
ght<br>help in designing contracts that are more flexible in the way they<b=
r>are spent, for example by allowing batching their transactions.<br><br>In=
stead, I expect the other parameters to almost always be hardcoded,<br>or p=
ropagated from the current input with the &lt;-1&gt; special values.<br><br=
>I agree that your ordering is more aesthetically pleasing, though.<br><br>=
&gt; I&#39;m wondering what other use cases you had in mind for the deferre=
d<br>&gt; output amount check? Maybe I have missed something, but if not it=
<br>&gt; would perhaps be better to leave out the amount preservation check=
, or<br>&gt; go the extra mile and propose a more powerful amount introspec=
tion<br>&gt; machinery.<br><br>Yes, the deferred output amount check is not=
 enough for coinpools;<br>however, it comes at no cost if we have a &lt;fla=
gs&gt; parameter anyway,<br>as OP_2 (value for CCV_IGNORE_OUTPUT_AMOUNT) is=
 a single byte opcode.<br><br>The intent of preserving amounts for many-to-=
one contracts (vaults),<br>or the one-to-one cases (channels, any 2-party c=
ontract, etc.) seems<br>common enough to deserve 1 bit in the flags, IMHO.<=
br>Efforts to define and add explicit introspection to cover your<br>(excit=
ing!) use cases can proceed independently, but I don&#39;t think<br>they wo=
uld nullify the advantages of this (optional) feature of CCV.</div><div dir=
=3D"ltr"><br>Best,<br>Salvatore</div></div>

--00000000000038de960602796918--