path: root/6a/df39f087697e1e68e60ecae55c4150131852cc

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 84FDEC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Sep 2021 01:40:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 7463B406F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Sep 2021 01:40:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id p5XaNk5Ph8BT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Sep 2021 01:40:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com
 [IPv6:2a00:1450:4864:20::42e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7E787406E9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Sep 2021 01:40:30 +0000 (UTC)
Received: by mail-wr1-x42e.google.com with SMTP id t8so2078747wrq.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Sep 2021 18:40:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=NN9fP1lPqGM4xOS/I5/i4z01h6XujeyhzFZbzIBSwMQ=;
 b=ISASoG1UCu+T5lxdjncahFRzuXgc+nvvQHUblCs1v3Hsg7TQcjCt08gIYrne9NFtth
 uZo/gOhdyVZqSY6PIqtDbjjlR3pXGt1kVNoeZ0ex3ii5qI3w8+6eZRAd1MDrSFHhG4ud
 RUo+fhaQpNH+SAgg+mO5D1zPawv2lTZjaNxE4hc8aeeNZyUSlEY6k90zwmgKuUK+C5vG
 36OjdVe3h74gl419zTZiLGfbpDXzZYRFyT2FXh40TmfwsCylOcCTqYFg9OwsYcFnokY7
 wwN00QV1jNnmV2Ju2tnwxlPUtPR0/0SdTrZmu5Qr9OE2vtpZChUpHkjhPgqaw+7CnaX2
 l2vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=NN9fP1lPqGM4xOS/I5/i4z01h6XujeyhzFZbzIBSwMQ=;
 b=XCOdAYvQu7ba2LwnzF2k5dQNvxf6Sn7On4mxafxpJO4KkpMcZagzzMpaq+VtElUzXx
 yW8/migmCzqKXmWE9ok+4BPPqRhvZCVI47FfnBmChUxGP7G8GYo2kOo+QDonllvw6XF/
 rZQvE4XNEKWmIyx8UKoTk3rzNUhKKvQCYrt+ZYxiBfNlJDBnzgnU5xI/ZJ4L5uNh0rp8
 ElK31EIbvPRgApkF/30CGyiI8Hkjt3sGGMkphxUrGWzxC2yMJMUoJs09gGGdUceM0O8e
 iRaHlhWH31Jdki/QXsG8u3TmpHaKNQKSEk/Aeg8aUcq/y2tr6VS+uqtzuXaqMlW84VX9
 1Qvg==
X-Gm-Message-State: AOAM5306rBx+Sxh4oCBYC8n8XpLM4QYS6JGS+rqWrPGhGEKkVZffKnX+
 J0Inz/OiYslZKLd9x9DyUuKk/0NO3pThRer/thjsxc7EJfU=
X-Google-Smtp-Source: ABdhPJzUosCJjq8djVdeleudWlgiudZ0+Ki7s3+ccnF0ys14sNIfI3xGKFA97a0zmbDyJJzulU/8iPaDXk/8iHboRnA=
X-Received: by 2002:a5d:65ce:: with SMTP id e14mr39227202wrw.328.1632274828697; 
 Tue, 21 Sep 2021 18:40:28 -0700 (PDT)
MIME-Version: 1.0
References: <20210909064138.GA22496@erisian.com.au>
 <CALZpt+FnnbGJC4=KO_OPiKxt0Ey9Bzh1gxP1dQSDz2aBi9WyOA@mail.gmail.com>
 <20210911032644.GB23578@erisian.com.au>
 <CALZpt+HzM__OJntegOhDqkg5zU=PQXtKgQoB518A2qP9=foovw@mail.gmail.com>
 <20210915065051.GA26119@erisian.com.au>
 <CALZpt+Hczvy1Fxu40cCKKC8bR9fouQ+sAiqV65-Z4VuLp+Bi7w@mail.gmail.com>
 <20210920145246.GB21263@erisian.com.au>
In-Reply-To: <20210920145246.GB21263@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 21 Sep 2021 21:40:16 -0400
Message-ID: <CALZpt+HTnrpcXE-kd3_WMZyrYH6-g3Y2H_gOfc5YAn=qFHxo+w@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000005723c405cc8b9901"
X-Mailman-Approved-At: Wed, 22 Sep 2021 08:19:44 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode
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: Wed, 22 Sep 2021 01:40:31 -0000

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

> Hmm, I'm reading C5 as "If an oracle says X, and Alice and Carol agree,
> they can distribute all the remaining funds as they see fit".

Should be read as an OR:

        IF 2 <oracle_sig> <alice_sig> 2 CHECKMULTISIG
        ELSE 2 <oracle_sig> <bob_sig> 2 CHECKMULTISIG
        ENDIF
        <> 2 IN_OUT_AMOUNT

The empty vector is a wildcard on the spent amount, as this tapscript may
be executed before/
after the split or any withdraw option.

> (Relative timelocks would probably be annoying for everyone who wasn't
> the first to exit the pool)

And I think unsafe, if you're wrapping a time-sensitive output in your
withdraw scriptPubkey.

> I think the above fixes that -- when AB is spent it deletes itself and
> the (A,B) pair; when A is spent, it deletes (A, B and AB) and replaces
> them with B'; when B' is spent it just deletes itself.

Right, here the subtlety in reading the scripts is about the B'
substitution tapscript in the
A one. And it sounds correct to me that AB exercise deletes the withdraw
pair (A, B).

Le lun. 20 sept. 2021 =C3=A0 10:52, Anthony Towns <aj@erisian.com.au> a =C3=
=A9crit :

> On Sat, Sep 18, 2021 at 10:11:10AM -0400, Antoine Riard wrote:
> > I think one design advantage of combining scope-minimal opcodes like
> MERKLESUB
> > with sighash malleability is the ability to update a subset of the
> off-chain
> > contract transactions fields after the funding phase.
>
> Note that it's not "update" so much as "add to"; and I mostly think
> graftroot (and friends), or just updating the utxo onchain, are a better
> general purpose way of doing that. It's definitely a tradeoff though.
>
> > Yes this is a different contract policy that I would like to set up.
> > Let's say you would like to express the following set of capabilities.
> > C0=3D"Split the 4 BTC funds between Alice/Bob and Caroll/Dave"
> > C1=3D"Alice can withdraw 1 BTC after 2 weeks"
> > C2=3D"Bob can withdraw 1 BTC after 2 weeks"
> > C3=3D"Caroll can withdraw 1 BTC after 2 weeks"
> > C4=3D"Dave can withdraw 1 BTC after 2 weeks"
> > C5=3D"If USDT price=3DX, Alice can withdraw 2 BTC or Caroll can withdra=
w 2
> BTC"
>
> Hmm, I'm reading C5 as "If an oracle says X, and Alice and Carol agree,
> they can distribute all the remaining funds as they see fit".
>
> > If C4 is exercised, to avoid trust in the remaining counterparty, both
> Alice or
> > Caroll should be able to conserve the C5 option, without relying on the
> updated
> > key path.
>
> > As you're saying, as we know the group in advance, one way to setup the
> tree
> > could be:
> >        (A, (((((B, C), BC), D), BCD), ((((E, F), EF), G), EFG)))
>
> Make it:
>
>   (((AB, (A,B)), (CD, (C,D))), ACO)
>
> AB =3D DROP <alice+bob> DUP 0 6 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 2BT=
C
> LESSTHAN
> CD =3D same but for carol+dave
> A =3D <alice> DUP <B'> 10 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC LESS=
THAN
> B' =3D <bob> DUP 0 2 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC LESSTHAN
> B,C,D =3D same as A but for bob, etc
> A',C',D' =3D same as B' but for alice, etc
> ACO =3D <alice+carol> CHECKSIGVERIFY <oracle> CHECKSIG
>
> Probably AB, CD, A..D, A'..D' all want a CLTV delay in there as well.
> (Relative timelocks would probably be annoying for everyone who wasn't
> the first to exit the pool)
>
> > Note, this solution isn't really satisfying as the G path isn't
> neutralized on
> > the Caroll/Dave fork and could be replayed by Alice or Bob...
>
> I think the above fixes that -- when AB is spent it deletes itself and
> the (A,B) pair; when A is spent, it deletes (A, B and AB) and replaces
> them with B'; when B' is spent it just deletes itself.
>
> Cheers,
> aj
>

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

<div dir=3D"ltr">&gt; Hmm, I&#39;m reading C5 as &quot;If an oracle says X,=
 and Alice and Carol agree,<br>&gt; they can distribute all the remaining f=
unds as they see fit&quot;.<br><br>Should be read as an OR:<br><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 IF 2 &lt;oracle_sig&gt; &lt;alice_sig&gt; 2 CHECKMULTI=
SIG<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ELSE 2 &lt;oracle_sig&gt; &lt;bob_sig&gt=
; 2 CHECKMULTISIG<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ENDIF<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 &lt;&gt; 2 IN_OUT_AMOUNT<br><br>The empty vector is a wildcard o=
n the spent amount, as this tapscript may be executed before/<br>after the =
split or any withdraw option.<br><br>&gt; (Relative timelocks would probabl=
y be annoying for everyone who wasn&#39;t<br>&gt; the first to exit the poo=
l)<br><br>And I think unsafe, if you&#39;re wrapping a time-sensitive outpu=
t in your withdraw scriptPubkey.<br><br>&gt; I think the above fixes that -=
- when AB is spent it deletes itself and<br>&gt; the (A,B) pair; when A is =
spent, it deletes (A, B and AB) and replaces<br>&gt; them with B&#39;; when=
 B&#39; is spent it just deletes itself.<br><br>Right, here the subtlety in=
 reading the scripts is about the B&#39; substitution tapscript in the<br>A=
 one. And it sounds correct to me that AB exercise deletes the withdraw pai=
r (A, B).<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Le=C2=A0lun. 20 sept. 2021 =C3=A0=C2=A010:52, Anthony Towns &l=
t;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; a =C3=A9cr=
it=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat=
, Sep 18, 2021 at 10:11:10AM -0400, Antoine Riard wrote:<br>
&gt; I think one design advantage of combining scope-minimal opcodes like M=
ERKLESUB<br>
&gt; with sighash malleability is the ability to update a subset of the off=
-chain<br>
&gt; contract transactions fields after the funding phase.<br>
<br>
Note that it&#39;s not &quot;update&quot; so much as &quot;add to&quot;; an=
d I mostly think<br>
graftroot (and friends), or just updating the utxo onchain, are a better<br=
>
general purpose way of doing that. It&#39;s definitely a tradeoff though.<b=
r>
<br>
&gt; Yes this is a different contract policy that I would like to set up.<b=
r>
&gt; Let&#39;s say you would like to express the following set of capabilit=
ies.<br>
&gt; C0=3D&quot;Split the 4 BTC funds between Alice/Bob and Caroll/Dave&quo=
t;<br>
&gt; C1=3D&quot;Alice can withdraw 1 BTC after 2 weeks&quot;<br>
&gt; C2=3D&quot;Bob can withdraw 1 BTC after 2 weeks&quot;<br>
&gt; C3=3D&quot;Caroll can withdraw 1 BTC after 2 weeks&quot;<br>
&gt; C4=3D&quot;Dave can withdraw 1 BTC after 2 weeks&quot;<br>
&gt; C5=3D&quot;If USDT price=3DX, Alice can withdraw 2 BTC or Caroll can w=
ithdraw 2 BTC&quot;<br>
<br>
Hmm, I&#39;m reading C5 as &quot;If an oracle says X, and Alice and Carol a=
gree,<br>
they can distribute all the remaining funds as they see fit&quot;.<br>
<br>
&gt; If C4 is exercised, to avoid trust in the remaining counterparty, both=
 Alice or<br>
&gt; Caroll should be able to conserve the C5 option, without relying on th=
e updated<br>
&gt; key path.<br>
<br>
&gt; As you&#39;re saying, as we know the group in advance, one way to setu=
p the tree<br>
&gt; could be:<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0(A, (((((B, C), BC), D), BCD), ((((E, F), E=
F), G), EFG)))<br>
<br>
Make it:<br>
<br>
=C2=A0 (((AB, (A,B)), (CD, (C,D))), ACO)<br>
<br>
AB =3D DROP &lt;alice+bob&gt; DUP 0 6 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB=
 2BTC LESSTHAN<br>
CD =3D same but for carol+dave<br>
A =3D &lt;alice&gt; DUP &lt;B&#39;&gt; 10 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT=
 SUB 1BTC LESSTHAN<br>
B&#39; =3D &lt;bob&gt; DUP 0 2 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC L=
ESSTHAN<br>
B,C,D =3D same as A but for bob, etc<br>
A&#39;,C&#39;,D&#39; =3D same as B&#39; but for alice, etc<br>
ACO =3D &lt;alice+carol&gt; CHECKSIGVERIFY &lt;oracle&gt; CHECKSIG<br>
<br>
Probably AB, CD, A..D, A&#39;..D&#39; all want a CLTV delay in there as wel=
l.<br>
(Relative timelocks would probably be annoying for everyone who wasn&#39;t<=
br>
the first to exit the pool)<br>
<br>
&gt; Note, this solution isn&#39;t really satisfying as the G path isn&#39;=
t neutralized on<br>
&gt; the Caroll/Dave fork and could be replayed by Alice or Bob...<br>
<br>
I think the above fixes that -- when AB is spent it deletes itself and<br>
the (A,B) pair; when A is spent, it deletes (A, B and AB) and replaces<br>
them with B&#39;; when B&#39; is spent it just deletes itself.<br>
<br>
Cheers,<br>
aj<br>
</blockquote></div>

--0000000000005723c405cc8b9901--