From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 84FDEC000D for ; 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 ; 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 ; 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 ; Wed, 22 Sep 2021 01:40:30 +0000 (UTC) Received: by mail-wr1-x42e.google.com with SMTP id t8so2078747wrq.4 for ; 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> <20210911032644.GB23578@erisian.com.au> <20210915065051.GA26119@erisian.com.au> <20210920145246.GB21263@erisian.com.au> In-Reply-To: <20210920145246.GB21263@erisian.com.au> From: Antoine Riard Date: Tue, 21 Sep 2021 21:40:16 -0400 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="0000000000005723c405cc8b9901" X-Mailman-Approved-At: Wed, 22 Sep 2021 08:19:44 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 2 CHECKMULTISIG ELSE 2 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 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 DUP 0 6 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 2BT= C > LESSTHAN > CD =3D same but for carol+dave > A =3D DUP 10 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC LESS= THAN > B' =3D 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 CHECKSIGVERIFY 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
> Hmm, I'm reading C5 as "If an oracle says X,= and Alice and Carol agree,
> they can distribute all the remaining f= unds as they see fit".

Should be read as an OR:

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 IF 2 <oracle_sig> <alice_sig> 2 CHECKMULTI= SIG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ELSE 2 <oracle_sig> <bob_sig>= ; 2 CHECKMULTISIG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ENDIF
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 <> 2 IN_OUT_AMOUNT

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

> (Relative timelocks would probabl= y be annoying for everyone who wasn't
> the first to exit the poo= l)

And I think unsafe, if you're wrapping a time-sensitive outpu= t 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 pai= r (A, B).

Le=C2=A0lun. 20 sept. 2021 =C3=A0=C2=A010:52, Anthony Towns &l= t;aj@erisian.com.au> a =C3=A9cr= it=C2=A0:
On Sat= , Sep 18, 2021 at 10:11:10AM -0400, Antoine Riard wrote:
> I think one design advantage of combining scope-minimal opcodes like M= ERKLESUB
> 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"; an= d 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 capabilit= ies.
> C0=3D"Split the 4 BTC funds between Alice/Bob and Caroll/Dave&quo= t;
> 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 w= ithdraw 2 BTC"

Hmm, I'm reading C5 as "If an oracle says X, and Alice and Carol a= gree,
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 th= e updated
> key path.

> As you're saying, as we know the group in advance, one way to setu= p the tree
> could be:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(A, (((((B, C), BC), D), BCD), ((((E, F), E= F), G), EFG)))

Make it:

=C2=A0 (((AB, (A,B)), (CD, (C,D))), ACO)

AB =3D DROP <alice+bob> DUP 0 6 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB= 2BTC LESSTHAN
CD =3D same but for carol+dave
A =3D <alice> DUP <B'> 10 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT= SUB 1BTC LESSTHAN
B' =3D <bob> DUP 0 2 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC L= ESSTHAN
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 wel= l.
(Relative timelocks would probably be annoying for everyone who wasn't<= br> 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--