MIME-Version: 1.0
References: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com>
 <CALZpt+GVe0XTdWqV=LAcOj=nq+k2DEFqc+sKyxAujLDBR7bYbQ@mail.gmail.com>
 <CAMhCMoEONv3jriBU3qwm0pt75iF_sgra1H2Z4rOF8u+e7hs_cw@mail.gmail.com>
 <0f352f70-c93a-614f-e443-67d198ec2c26@protonmail.com>
 <7f3674d1-c1ad-9a82-e30f-7cf24d697faf@protonmail.com>
 <CAMhCMoGabEASO9CGc1hAMpYZn4nWH5D8XFs3eFcSSFAitSFUGA@mail.gmail.com>
 <CAGpPWDZkUYW=Qb763TPzUa6yUf217nh0Bo+O9Qyf=WS2pUQUYA@mail.gmail.com>
 <CAD3i26AXZKDCH3odhCjpMwzOTGQKSFqH9S+5N9UXNTb7CJHONA@mail.gmail.com>
 <CAMhCMoFgto3Bu5+yEoqn1Jf8fNd+EQK-t_H3TKR2=3RXe8FdcQ@mail.gmail.com>
 <CAMhCMoGdZsDO2eZYMf+G36gc5=-SB0HxHXbRSPx5OaCOjo5_Dw@mail.gmail.com>
 <CAD3i26BoasDQGg1VOxaHJzoXXKnYKuBdXOq+wVZ=QhKbycobPA@mail.gmail.com>
 <CAMhCMoH-MSfTeG6vnWPdG9bAxWXRatWQY8wUmOqM5mAyH=5n9Q@mail.gmail.com>
 <CAD3i26DMGj=KRfi=gqHPdCZ_WyUAvWV50g7TcH4n2e3xSCx8Lg@mail.gmail.com>
In-Reply-To: <CAD3i26DMGj=KRfi=gqHPdCZ_WyUAvWV50g7TcH4n2e3xSCx8Lg@mail.gmail.com>
From: Salvatore Ingala <salvatore.ingala@gmail.com>
Date: Sun, 28 May 2023 12:24:14 +0200
Message-ID: <CAMhCMoHSonS2_wcCZYH9FhC5B5UCgf26JPhkK13pZCbo3ZO7JQ@mail.gmail.com>
To: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000dc270d05fcbe5fc6"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Merkleize All The Things
Precedence: list

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

Hi Johan,

Exciting to finally see some merkleization, which was only confined
within the meme, up to this point!

> A simpler way IMO, would be to make OP_CICV and OP_COCV symmetrical:
> Have OP_CICV take an optional taproot and do the same check as is
> done for the output: Q =3D=3D tweak(tweak(X,D), T).

I think that's an excellent suggestion, which I was already exploring
for a different purpose: bringing externally signed data onto the
stack. My goal there was to allow eltoo-style replacement.

Until recently, I thought that a clean/efficient version of eltoo
would require OP_CHECKSIGFROMSTACK or ANYPREVOUT. However, extending
OP_CHECKINPUTCONTRACTVERIFY to enable introspection of other inputs
allows a reasonable workaround: producing a separate UTXO signed with
ANYONECANPAY, with the required data embedded as usual. Spending that
UTXO together with the channel's UTXO allows one to get that data
on the stack (with its signature already checked by consensus rules).
I drafted this idea in a gist [1].

Remark: it still seems easier (and probably slightly more efficient)
to build eltoo replacement with CSFS or APO in addition to MATT
opcodes.

A possible semantics for OP_CHECKINPUTCONTRACTVERIFY could then be
exactly symmetrical to that of OP_CHECKOUTPUTCONTRACTVERIFY, with
the exception that the special input index -1 would represent the
current input.

Pushing this further, another option that could be be worth exploring
is to have a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode, with the
same semantics as OP_CHECKOUTPUTCONTRACTVERIFY from [2], but with an
additional `flags` argument, which is a bitmap where:
- the lowest-significant bit determines if the index refers to inputs
  or outputs (where input index -1 refers to the current input)
- the second bit specifies if amounts should be preserved with
  deferred checks as described in [2] (only applicable to outputs)
- other bits are OP_SUCCESS and reserved for future behaviors.

This would make the opcodes 1-2 bytes larger, but might allow greater
flexibility, and keep some room for future extensions.

> 2.To make fully functioning CoinPools, one would need functionality
> similar to OP_MERKLESUB[4]: remove some data from the merkle tree,
> and remove a key from the aggregated internal key.

It seems likely that efficient use of the taproot internal pubkey with
"dynamic key aggregation" is not possible with the current semantics
(unless one ventures into the fraud proof machinery, which seems
overkill!).

However, in constructions with MATT opcodes, I would never expect the
need for data to be stored in the taptree. In particular, for the case
of CoinPools, the pubkeys of the members could also be stored in the
embedded data, having a single "unilateral withdrawal" tapleaf.
Removing a key would then amount to replacing it with a fixed NUMS key
and computing the new root (re-using the same Merkle proof).
Note that this is not a lot costlier than using a tapleaf per user:
instead of paying the cost for the Merkle proof in the control block,
you pay for it explicitly in the Script witness.

Therefore, I would expect there to be reasonable CoinPools designs
without additional opcodes =E2=88=92 but I am only moderately confident as
this is beyond the level of sophistication I've been exploring so far.

Best,
Salvatore

[1] - https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63
[2] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.h=
tml

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Johan,<br><br>Exciting to finally see =
some merkleization, which was only confined<br>within the meme, up to this =
point!<br><br>&gt; A simpler way IMO, would be to make OP_CICV and OP_COCV =
symmetrical:<br>&gt; Have OP_CICV take an optional taproot and do the same =
check as is<br>&gt; done for the output: Q =3D=3D tweak(tweak(X,D), T).<br>=
<br>I think that&#39;s an excellent suggestion, which I was already explori=
ng<br>for a different purpose: bringing externally signed data onto the<br>=
stack. My goal there was to allow eltoo-style replacement.<br><br>Until rec=
ently, I thought that a clean/efficient version of eltoo<br>would require O=
P_CHECKSIGFROMSTACK or ANYPREVOUT. However, extending<br>OP_CHECKINPUTCONTR=
ACTVERIFY to enable introspection of other inputs<br>allows a reasonable wo=
rkaround: producing a separate UTXO signed with<br>ANYONECANPAY, with the r=
equired data embedded as usual. Spending that<br>UTXO together with the cha=
nnel&#39;s UTXO=C2=A0allows one to get that data<br>on the stack (with its =
signature already checked by consensus rules).<br>I drafted this idea in a =
gist [1].<br><br>Remark: it still seems easier (and probably slightly more =
efficient)<br>to build eltoo replacement with CSFS or APO in addition to MA=
TT<br>opcodes.<br><br>A possible semantics for OP_CHECKINPUTCONTRACTVERIFY =
could then be<br>exactly symmetrical to that of OP_CHECKOUTPUTCONTRACTVERIF=
Y, with<br>the exception that the special input index -1 would represent th=
e<br>current input.<br><br>Pushing this further, another option that could =
be be worth exploring<br>is to have a single OP_CHECK_IN_OUT_CONTRACT_VERIF=
Y opcode, with the<br>same semantics as OP_CHECKOUTPUTCONTRACTVERIFY from [=
2], but with an<br>additional `flags` argument, which is a bitmap where:<br=
>- the lowest-significant bit determines if the index refers to inputs<br>=
=C2=A0 or outputs (where input index -1 refers to the current input)<br>- t=
he second bit specifies if amounts should be preserved with<br>=C2=A0 defer=
red checks as described in [2] (only applicable to outputs)<br>- other bits=
 are OP_SUCCESS and reserved for future behaviors.<br><br>This would make t=
he opcodes 1-2 bytes larger, but might allow greater<br>flexibility, and ke=
ep some room for future extensions.<br><br>&gt; 2.To make fully functioning=
 CoinPools, one would need functionality<br>&gt; similar to OP_MERKLESUB[4]=
: remove some data from the merkle tree, <br>&gt; and remove a key from the=
 aggregated internal key.<br><br>It seems likely that efficient use of the =
taproot internal pubkey with<br>&quot;dynamic key aggregation&quot; is not =
possible with the current semantics<br>(unless one ventures into the fraud =
proof machinery, which seems<br>overkill!).<br><br>However, in construction=
s with MATT opcodes, I would never expect the<br>need for data to be stored=
 in the taptree. In particular, for the case<br>of CoinPools, the pubkeys o=
f the members could also be stored in the<br>embedded data, having a single=
 &quot;unilateral withdrawal&quot; tapleaf.<br>Removing a key would then am=
ount to replacing it with a fixed NUMS key<br>and computing the new root (r=
e-using the same Merkle proof).<br>Note that this is not a lot costlier tha=
n using a tapleaf per user:<br>instead of paying the cost for the Merkle pr=
oof in the control block,<br>you pay for it explicitly in the Script witnes=
s.<br><br>Therefore, I would expect there to be reasonable CoinPools design=
s<br>without additional opcodes =E2=88=92 but I am only moderately confiden=
t as<br>this is beyond the level of sophistication I&#39;ve been exploring =
so far.<br><br>Best,<br>Salvatore<br><br>[1] - <a href=3D"https://gist.gith=
ub.com/bigspider/041ebd0842c0dcc74d8af087c1783b63">https://gist.github.com/=
bigspider/041ebd0842c0dcc74d8af087c1783b63</a><br>[2] - <a href=3D"https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html">htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html=
</a></div></div>

--000000000000dc270d05fcbe5fc6--