path: root/42/cbcee75ee9a53ce8085daced48b2bedca1fcd6

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 431ECC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 14:11:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2BE3E425E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 14:11:27 +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_40=-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 Bd-HUFY7qwnz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 14:11:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [IPv6:2a00:1450:4864:20::432])
 by smtp4.osuosl.org (Postfix) with ESMTPS id D33D8425DE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 14:11:24 +0000 (UTC)
Received: by mail-wr1-x432.google.com with SMTP id t8so19992400wrq.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 18 Sep 2021 07:11:24 -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=e3+jBOtYXTnfV9b0vATDkjq3VYkbTzghowah2T2l9MM=;
 b=L2AyLEG6j24RgLqA6twb2yiS8oezQsnliCtLbvgeb3xQnVBpvI2SPoB6UkWN524E0n
 6Xbc2vw6LU96uIFxYOenBEnNdr2q0A+CIIXPdCuWBtoao8DEQoqNGjrJEnJM0a+glHIB
 84x7PKZljY3zSZyaTDRYv+LnLLSyD2l70kfVX3p8vUjbR78Nlx94xjBOMxCBffj9uksM
 bfEJlY3jY07qv3hM3AoyuI6/dN7kRMhItV4ZPTcE9WphEv2H56vnTu/JHt50BcCrEjzr
 JvXvyoWAShSzoPaazXHcqbelKgrz5ddRvJHkwPE2RdTbkTT52wMAb1uYx/flOf6uf5Xx
 vWKg==
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=e3+jBOtYXTnfV9b0vATDkjq3VYkbTzghowah2T2l9MM=;
 b=5eAgYzJ2LavhuoU3+ZPhJHkBFv1FGquuxGaSiqD6sB0nNEEt+rTkA/fPIFWf+ULrfT
 SFbgJitujqV7olkZGN7LjuwgIQvjkxgNkDjUM6o6dm4LS3BEHR8KDyT7z5F31kCqlRKw
 KZsBuZvoiAMm8Wn1lRIxVxNr70LpOTjChqFbwm56s9U3vuOayXwcGVTJDo4l+UGm0K+D
 YYX7cDG+3rod1tzqKC3kapaK4X0gciyd6Tgqtb0wEjncqLUgE3jKbAFq4d1xj+BWYX99
 rEOKb8NI8co0uOI/agk3dNS3idVm8efh2SIGGzkBFRCGbtHPCBUjv0NASSzTbRBx/kzy
 NkoA==
X-Gm-Message-State: AOAM530pg8U7EbremnXeYAGlf5zQhIbC/Pvkofd1VGsZbXkr+GUlMIRC
 KFHs5HMvJBMuhOtQwVApn1+IvVvd2h/SFyjKC2Ayq1akXWo=
X-Google-Smtp-Source: ABdhPJya1ml0IsViRPn9wIp3+xyZmC8ZWVD2Tnz2LGW+zuKQDEjWIlDG3xjJjvTNzGFHlaGv/0kXIzzxHP5NofoYL+M=
X-Received: by 2002:a5d:4b0b:: with SMTP id v11mr18599274wrq.359.1631974282969; 
 Sat, 18 Sep 2021 07:11:22 -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>
In-Reply-To: <20210915065051.GA26119@erisian.com.au>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 18 Sep 2021 10:11:10 -0400
Message-ID: <CALZpt+Hczvy1Fxu40cCKKC8bR9fouQ+sAiqV65-Z4VuLp+Bi7w@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000006b469205cc459ff4"
X-Mailman-Approved-At: Sat, 18 Sep 2021 18:04:38 +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: Sat, 18 Sep 2021 14:11:27 -0000

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

> I think "<I> <P> MERKLESUB" is the same as "<P> OP_0 2 TLUV", provided
> <I> happens to be the same index as the current input. So it misses the
> ability to add branches (replacing OP_0 with a hash), the ability to
> preserve the current script (replacing 2 with 0), and the ability to
> remove some of the parent paths (replacing 2 with 4*n); but gains the
> ability to refer to non-corresponding outputs.

Yes, I agree.

> That... doesn't sound very straightforward to me; it's basically
> introducing a new covenant approach, that's getting fixed into a
> signature, rather than being a separate opcode.

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. With a
lower level of cooperation than required by the key path. I think not an
ability offered by templated covenants.

> I'm not really sure what you're saying there; is that any different to a
> pool of (A and B) where A suddenly wants to withdraw funds ASAP and can't
> wait for a key path signature? In that case A authorises the withdrawal
> and does whatever she wants with the funds (including form a new pool),
> and B remains in the pool.

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 withdraw 2 =
BTC"

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 tre=
e
could be:

       (A, (((((B, C), BC), D), BCD), ((((E, F), EF), G), EFG)))

where:
A=3D"1 <alice> <caroll> 2 CHECKMULTISIG <usdt_oracle> CHECKSIG"
B=3D"<alice> DUP 0 2 TLUV CHECKSIG"
C=3D"<bob> DUP 0 2 TLUV CHECKSIG"
D=3D"<alice+bob> 0 6 TLUV 1 <caroll> <dave> 2 CHECKMULTISIG"
E=3D"<caroll> DUP 0 2 TLUV CHECKSIG"
F=3D"<dave> DUP 0 2 TLUV CHECKSIG"
G=3D"<caroll+dave> 0 6 TLUV 1 <alice> <bob> 2 CHECKMULTISIG"

E.g, if D is exercised, B+C+D are removed from the tree and A, E, F, G are
conserved in the Caroll/Dave fork. Then Caroll can exercise the USDT option
without trusting Dave.

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... One
improvement could be to have the "withdraw" script path (C,D,F,G) expressed
redundantly. That way when a "split" script path is exercised the uncle
split path and all the siblings "withdraw" paths can be removed.

Echoing your point about the difficulty of reliably composing arbitrary
subsets of the pool, I lean to agree that merkle trees aren't the most
straightforward way to encode that kind of contract policy.

> If you're worried about the cost of a single byte of witness data you
> probably can't afford to do script path spends at all -- certainly
> having to do 64 bytes of witness data to add a signature that commits
> to an amount and the like will be infeasible in that case.

Yes, I agree fully templated covenants are more efficient to save witness
data.

I still like the idea of inserting a key as you might have an interesting
ability.
Like a N-of-M, a subset of the vault/pool able to update the withdraw
pubkey.

> That doesn't work. Suppose you start off with an even internal pubkey,
> with three scripts, (A, (B,C)). All of those scripts have tapscript
> version 0xc0 because the internal pubkey is even. You spend using A and
> calculate the new internal pubkey which turns out to be odd. You then
> need to change B and C's script version from 0xc0 to 0x20, but you can't
> do that (at least, you can't do it without revealing every script).

I'm not sure we're aligned on the mechanism.

We introduce a new tapscript version 0x20.

At spent taproot commitment verification, if the tapscript version=3D0x20,
the second-lowest bit of the first byte of the control block is interpreted
as the parity bit of the spent internal pubkey (i.e control[0] & 0x2).

This parity bit is used to compute a new format of TapTweakV2=3DH(p || m ||
bit) and commitment verification keep proceeding unmodified.

As the leaf version is committed as part of every TapLeaf, I think any
usage of MERKLESUB would require to use tapscript version 0x20 for the
whole set of leaves.

If you build a tree blurring 0xc0 leaves and TapTweakV2, I think those
leaves will be unspendable as they will always fail the commitment
verification.

> Changing the TapTweak calculation is a hard fork; existing software
> already verifies the calculation even if the script version is unknown.

Thinking more, you're right...

In case of TapTweakV2, non-upgraded nodes won't be able to pass the
validation of unknown script version (0x20), and the failure will provoke a
fork.

Could we commit the spent internal pubkey parity bit as a one-more-tweak
transparent to non-upgrades nodes ?

For upgraded, P =3D R + (t2 * G) and Q =3D P + (t1 * G)
For non-upgraded, Q =3D P + (t1 * G).

Could we add a new validation rule (e.g VerifyInternalPubkeyCommitment)
conditional on a newer tapscript version just before
VerifyTaprootCommitment ?

> That is, the strategy isn't "tweak the scripts by delaying them 3 months"
> it's "tweak the merkle tree, to replace the scripts that would be delayed
> with a new script that has a delay and then allows itself to be replaced
> by the original scripts that we now want back".

Yes, that's a good strategy to have logically equivalent subtree embedded
in the modifying tapscript.

If you have multiple modifying scripts and you can't predict the order, I
think the tree complexity will be quickly too high and grafroot-like
approaches are likely better

Le mer. 15 sept. 2021 =C3=A0 02:51, Anthony Towns <aj@erisian.com.au> a =C3=
=A9crit :

> On Sun, Sep 12, 2021 at 07:37:56PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > While MERKLESUB is still WIP, here the semantic. [...]
> > I believe this is matching your description and the main difference
> compared to
> > your TLUV proposal is the lack of merkle tree extension, where a new
> merkle
> > path is added in place of the removed tapscript.
>
> I think "<I> <P> MERKLESUB" is the same as "<P> OP_0 2 TLUV", provided
> <I> happens to be the same index as the current input. So it misses the
> ability to add branches (replacing OP_0 with a hash), the ability to
> preserve the current script (replacing 2 with 0), and the ability to
> remove some of the parent paths (replacing 2 with 4*n); but gains the
> ability to refer to non-corresponding outputs.
>
> > > That would mean anyone who could do a valid spend of the tx could
> > > violate the covenant by spending to an unencumbered witness v2 output
> > > and (by collaborating with a miner) steal the funds. I don't think
> > > there's a reasonable way to have existing covenants be forward
> > > compatible with future destination addresses (beyond something like C=
TV
> > > that strictly hardcodes them).
> > That's a good catch, thanks for raising it :)
> > Depends how you define reasonable, but I think one straightforward fix
> is to
> > extend the signature digest algorithm to encompass the segwit version
> (and
> > maybe program-size ?) of the spending transaction outputs.
>
> That... doesn't sound very straightforward to me; it's basically
> introducing a new covenant approach, that's getting fixed into a
> signature, rather than being a separate opcode.
>
> I think a better approach for that would be to introduce the opcode (eg,
> PUSH_OUTPUT_SCRIPTPUBKEY, and SUBSTR to be able to analyse the segwit
> version), and make use of graftroot to allow a signature to declare that
> it's conditional on some extra script code. But it feels like it's going
> a bit off topic.
>
> > > Having the output position parameter might be an interesting way to
> > > merge/split a vault/pool, but it's not clear to me how much sense it
> > > makes sense to optimise for that, rather than just doing that via the
> key
> > > path. For pools, you want the key path to be common anyway (for priva=
cy
> > > and efficiency), so it shouldn't be a problem; but even for vaults,
> > > you want the cold wallet accessible enough to be useful for the case
> > > where theft is attempted, and maybe that's also accessible enough for
> > > the ocassional merge/split to keep your utxo count/sizes reasonable.
> > I think you can come up with interesting contract policies. Let's say
> you want
> > to authorize the emergency path of your pool/vault balances if X happen=
s
> (e.g a
> > massive drop in USDT price signed by DLC oracles). You have (A+B+C+D)
> forking
> > into (A+B) and (C+D) pooled funds. To conserve the contracts
> pre-negotiated
> > economic equilibrium, all the participants would like the emergency pat=
h
> to be
> > inherited on both forks. Without relying on the key path interactivity,
> which
> > is ultimately a trust on the post-fork cooperation of your counterparty=
 ?
>
> I'm not really sure what you're saying there; is that any different to a
> pool of (A and B) where A suddenly wants to withdraw funds ASAP and can't
> wait for a key path signature? In that case A authorises the withdrawal
> and does whatever she wants with the funds (including form a new pool),
> and B remains in the pool.
>
> I don't think you can reliably have some arbitrary subset of the pool
> able to withdraw atomically without using the key path -- if A,B,C,D have
> individual scripts allowing withdrawal, then there's no way of setting
> the tree up so that every pair of members can have their scripts cut
> off without also cutting off one or both of the other members withdrawal
> scripts.
>
> If you know in advance which groups want to stick together, you could
> set things up as:
>
>   (((A, B), AB), C)
>
> where:
>
>   A =3D   "A DUP H(B') 10 TLUV CHECKSIG"  -> (B', C)
>   B =3D   "B DUP H(A') 10 TLUV CHECKSIG"  -> (A', C)
>   A' =3D  "A DUP 0 2 TLUV CHECKSIG"   -> (C)
>   B' =3D  "B DUP 0 2 TLUV CHECKSIG"   -> (C)
>   AB =3D  "(A+B) DUP 6 TLUV CHECKSIG  -> (C)
>   C  =3D  "C DUP 0 2 TLUV CHECKSIG"   -> ((A,B), AB)
>
> (10 =3D 2+4*2 =3D drop my script, my sibling and my uncle; 6 =3D 2+4*1 =
=3D
> drop my script and my sibling; 2 =3D drop my script only)
>
> Which would let A and B exit together in a single tx rather than needing
> two
> transactions to exit separately.
>
> > > Saving a byte of witness data at the cost of specifying additional
> > > opcodes seems like optimising the wrong thing to me.
> > I think we should keep in mind that any overhead cost in the usage of a
> script
> > primitive is echoed to the user of off-chain contract/payment channels.
> If the
> > tapscripts are bigger, your average on-chain spends in case of
> non-cooperative
> > scenarios are increased in consequence, and as such your fee-bumping
> reserve.
> > Thus making those systems less economically accessible.
>
> If you're worried about the cost of a single byte of witness data you
> probably can't afford to do script path spends at all -- certainly
> having to do 64 bytes of witness data to add a signature that commits
> to an amount and the like will be infeasible in that case.
>
> > > I don't think that works, because different scripts in the same merkl=
e
> > > tree can have different script versions, which would here indicate
> > > different parities for the same internal pub key.
> > Let me make it clearer. We introduce a new tapscript version 0x20,
> forcing a
> > new bit in the first byte of the control block to be interpreted as the
> parity
> > bit of the spent internal pubkey.
>
> That doesn't work. Suppose you start off with an even internal pubkey,
> with three scripts, (A, (B,C)). All of those scripts have tapscript
> version 0xc0 because the internal pubkey is even. You spend using A and
> calculate the new internal pubkey which turns out to be odd. You then
> need to change B and C's script version from 0xc0 to 0x20, but you can't
> do that (at least, you can't do it without revealing every script).
>
> > To ensure this parity bit is faithful and
> > won't break the updated key path, it's committed in the spent taptweak.
>
> Changing the TapTweak calculation is a hard fork; existing software
> already verifies the calculation even if the script version is unknown.
>
> > > The IN_OUT_AMOUNT opcode lets you do maths on the values, so you can
> > > specify "hot wallets can withdraw up to X" rather than "hot wallets
> > > must withdraw exactly X". I don't think there's a way of doing that
> with
> > > SIGHASH_GROUP, even with a modifier like ANYPUBKEY?
> > You can exchange signatures for withdraw outputs with multiples `nValue=
`
> > covering the authorized range, assuming the ANYAMOUNT modifier ?
>
> If you want your hotwallet to be able to withdraw up to $2000, that's
> around 4,000,000 sats, so you'd be doing up to 4M signatures there if you
> wanted to get the exact value you're trying to send, without having to
> either overpay, or first pay yourself then have another tx that splits
> your withdrawal into what you're spending and change that's no longer
> in your vault.
>
> > One advantage
> > of leveraging sighash is the ability to update a withdraw policy in
> real-time.
> > Vaults participants might be willing to bump the withdraw policy beyond
> X,
> > assuming you have N-of-M consents.
>
> I mean, maybe? It seems like a very heavy weight construct where a more
> general approach would probably be better (eg, graftroot to attach a
> script to a signature; or checkdatasig or whatever so you push a value
> to the stack then check it's signature, then reuse the authenticated
> data against other checks) so that you only have to supply a signature
> when you want to be able to approve things after the fact.
>
> > I think I would like to express the following contract policy. Let's sa=
y
> you
> > have 1) a one-time conditional script path to withdraw fund ("a put on
> strike
> > price X"), 2) a conditional script path to tweak by 3 months all the
> usual
> > withdraw path and 3) those remaining withdraw paths. Once played out,
> you would
> > like the one-time path to be removed from your merkle tree. And this
> removal to
> > be inherited on the tweaked tree if 2) plays out.
>
> Okay, so I think that means we've got the unconditional withdraw path
> "U" (your 1), the delay path "D" (your 2) and some normal path(s) "N"
> (your 3). I think you can get that behaviour with:
>
>    S1 =3D Merkle( U, (D, N) )
>    S2 =3D Merkle( U, W )
>    S3 =3D Merkle( N )
>
> that is, you start off with the funds in scriptPubKey S1, then spend
> using D to get to S2, then spend using W to get to S3, then presumably
> spend using N at some point.
>
> The script for W is just:
>
>    "IN_OUT_AMOUNT EQUALVERIFY 0 <N> 6 TLUV <3 months> CSV"
>        (drop the script, drop its sibling, add N, wait 3 months)
>
> The script for D is:
>
>    "IN_OUT_AMOUNT EQUALVERIFY 0 <W> 6 TLUV <sigcheck...>"
>        (drop the script, drop its sibling, add W, extra conditions
>         to avoid anyone being able to delay things)
>
> That is, the strategy isn't "tweak the scripts by delaying them 3 months"
> it's "tweak the merkle tree, to replace the scripts that would be delayed
> with a new script that has a delay and then allows itself to be replaced
> by the original scripts that we now want back".
>
> Cheers,
> aj
>
>

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

<div dir=3D"ltr">&gt; I think &quot;&lt;I&gt; &lt;P&gt; MERKLESUB&quot; is =
the same as &quot;&lt;P&gt; OP_0 2 TLUV&quot;, provided<br>&gt; &lt;I&gt; h=
appens to be the same index as the current input. So it misses the<br>&gt; =
ability to add branches (replacing OP_0 with a hash), the ability to<br>&gt=
; preserve the current script (replacing 2 with 0), and the ability to<br>&=
gt; remove some of the parent paths (replacing 2 with 4*n); but gains the<b=
r>&gt; ability to refer to non-corresponding outputs.<br><br>Yes, I agree.<=
br><br>&gt; That... doesn&#39;t sound very straightforward to me; it&#39;s =
basically<br>&gt; introducing a new covenant approach, that&#39;s getting f=
ixed into a<br>&gt; signature, rather than being a separate opcode.<br><br>=
I think one design advantage of combining scope-minimal opcodes like MERKLE=
SUB with sighash malleability is the ability to update a subset of the off-=
chain contract transactions fields after the funding phase. With a lower le=
vel of cooperation than required by the key path. I think not an ability of=
fered by templated covenants.<br><br>&gt; I&#39;m not really sure what you&=
#39;re saying there; is that any different to a<br>&gt; pool of (A and B) w=
here A suddenly wants to withdraw funds ASAP and can&#39;t<br>&gt; wait for=
 a key path signature? In that case A authorises the withdrawal<br>&gt; and=
 does whatever she wants with the funds (including form a new pool),<br>&gt=
; and B remains in the pool.<br><br>Yes this is a different contract policy=
 that I would like to set up.<br><br>Let&#39;s say you would like to expres=
s the following set of capabilities.<br><br>C0=3D&quot;Split the 4 BTC fund=
s between Alice/Bob and Caroll/Dave&quot;<br>C1=3D&quot;Alice can withdraw =
1 BTC after 2 weeks&quot;<br>C2=3D&quot;Bob can withdraw 1 BTC after 2 week=
s&quot;<br>C3=3D&quot;Caroll can withdraw 1 BTC after 2 weeks&quot;<br>C4=
=3D&quot;Dave can withdraw 1 BTC after 2 weeks&quot;<br>C5=3D&quot;If USDT =
price=3DX, Alice can withdraw 2 BTC or Caroll can withdraw 2 BTC&quot;<br><=
br>If C4 is exercised, to avoid trust in the remaining counterparty, both A=
lice or Caroll should be able to conserve the C5 option, without relying on=
 the updated key path.<br><br>As you&#39;re saying, as we know the group in=
 advance, one way to setup the tree<br>could be:<br><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0(A, (((((B, C), BC), D), BCD), ((((E, F), EF), G), EFG)))<br><br>=
where:<br>A=3D&quot;1 &lt;alice&gt; &lt;caroll&gt; 2 CHECKMULTISIG &lt;usdt=
_oracle&gt; CHECKSIG&quot;<br>B=3D&quot;&lt;alice&gt; DUP 0 2 TLUV CHECKSIG=
&quot;<br>C=3D&quot;&lt;bob&gt; DUP 0 2 TLUV CHECKSIG&quot;<br>D=3D&quot;&l=
t;alice+bob&gt; 0 6 TLUV 1 &lt;caroll&gt; &lt;dave&gt; 2 CHECKMULTISIG&quot=
;<br>E=3D&quot;&lt;caroll&gt; DUP 0 2 TLUV CHECKSIG&quot;<br>F=3D&quot;&lt;=
dave&gt; DUP 0 2 TLUV CHECKSIG&quot;<br>G=3D&quot;&lt;caroll+dave&gt; 0 6 T=
LUV 1 &lt;alice&gt; &lt;bob&gt; 2 CHECKMULTISIG&quot;<br><br>E.g, if D is e=
xercised, B+C+D are removed from the tree and A, E, F, G are conserved in t=
he Caroll/Dave fork. Then Caroll can exercise the USDT option without trust=
ing Dave.<br><br>Note, this solution isn&#39;t really satisfying as the G p=
ath isn&#39;t neutralized on the Caroll/Dave fork and could be replayed by =
Alice or Bob... One improvement could be to have the &quot;withdraw&quot; s=
cript path (C,D,F,G) expressed redundantly. That way when a &quot;split&quo=
t; script path is exercised the uncle split path and all the siblings &quot=
;withdraw&quot; paths can be removed.<br><br>Echoing your point about the d=
ifficulty of reliably composing arbitrary subsets of the pool, I lean to ag=
ree that merkle trees aren&#39;t the most straightforward way to encode tha=
t kind of contract policy.<br><br>&gt; If you&#39;re worried about the cost=
 of a single byte of witness data you<br>&gt; probably can&#39;t afford to =
do script path spends at all -- certainly<br>&gt; having to do 64 bytes of =
witness data to add a signature that commits<br>&gt; to an amount and the l=
ike will be infeasible in that case.<br><br>Yes, I agree fully templated co=
venants are more efficient to save witness data.<br><br>I still like the id=
ea of inserting a key as you might have an interesting ability.<br>Like a N=
-of-M, a subset of the vault/pool able to update the withdraw pubkey.<br><b=
r>&gt; That doesn&#39;t work. Suppose you start off with an even internal p=
ubkey,<br>&gt; with three scripts, (A, (B,C)). All of those scripts have ta=
pscript<br>&gt; version 0xc0 because the internal pubkey is even. You spend=
 using A and<br>&gt; calculate the new internal pubkey which turns out to b=
e odd. You then<br>&gt; need to change B and C&#39;s script version from 0x=
c0 to 0x20, but you can&#39;t<br>&gt; do that (at least, you can&#39;t do i=
t without revealing every script).<br><br>I&#39;m not sure we&#39;re aligne=
d on the mechanism.<br><br>We introduce a new tapscript version 0x20.<br><b=
r>At spent taproot commitment verification, if the tapscript version=3D0x20=
, the second-lowest bit of the first byte of the control block is interpret=
ed as the parity bit of the spent internal pubkey (i.e control[0] &amp; 0x2=
).<br><br>This parity bit is used to compute a new format of TapTweakV2=3DH=
(p || m || bit) and commitment verification keep proceeding unmodified.<br>=
<br>As the leaf version is committed as part of every TapLeaf, I think any =
usage of MERKLESUB would require to use tapscript version 0x20 for the whol=
e set of leaves.<br><br>If you build a tree blurring 0xc0 leaves and TapTwe=
akV2, I think those leaves will be unspendable as they will always fail the=
 commitment verification.<br><br>&gt; Changing the TapTweak calculation is =
a hard fork; existing software<br>&gt; already verifies the calculation eve=
n if the script version is unknown.<br><br>Thinking more, you&#39;re right.=
..<br><br>In case of TapTweakV2, non-upgraded nodes won&#39;t be able to pa=
ss the validation of unknown script version (0x20), and the failure will pr=
ovoke a fork. <br><br>Could we commit the spent internal pubkey parity bit =
as a one-more-tweak transparent to non-upgrades nodes ?<br><br>For upgraded=
, P =3D R + (t2 * G) and Q =3D P + (t1 * G)<br>For non-upgraded, Q =3D P + =
(t1 * G).<br><br>Could we add a new validation rule (e.g VerifyInternalPubk=
eyCommitment) conditional on a newer tapscript version just before VerifyTa=
prootCommitment ?<br><br>&gt; That is, the strategy isn&#39;t &quot;tweak t=
he scripts by delaying them 3 months&quot;<br>&gt; it&#39;s &quot;tweak the=
 merkle tree, to replace the scripts that would be delayed<br>&gt; with a n=
ew script that has a delay and then allows itself to be replaced<br>&gt; by=
 the original scripts that we now want back&quot;.<br><br>Yes, that&#39;s a=
 good strategy to have logically equivalent subtree embedded in the modifyi=
ng tapscript.<br><br>If you have multiple modifying scripts and you can&#39=
;t predict the order, I think the tree complexity will be quickly too high =
and grafroot-like approaches are likely better</div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 15 sept. 2021 =
=C3=A0=C2=A002:51, Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au">a=
j@erisian.com.au</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Sun, Sep 12, 2021 at 07:37:56PM -0400, Anto=
ine Riard via bitcoin-dev wrote:<br>
&gt; While MERKLESUB is still WIP, here the semantic. [...]<br>
&gt; I believe this is matching your description and the main difference co=
mpared to<br>
&gt; your TLUV proposal is the lack of merkle tree extension, where a new m=
erkle<br>
&gt; path is added in place of the removed tapscript.<br>
<br>
I think &quot;&lt;I&gt; &lt;P&gt; MERKLESUB&quot; is the same as &quot;&lt;=
P&gt; OP_0 2 TLUV&quot;, provided<br>
&lt;I&gt; happens to be the same index as the current input. So it misses t=
he<br>
ability to add branches (replacing OP_0 with a hash), the ability to<br>
preserve the current script (replacing 2 with 0), and the ability to<br>
remove some of the parent paths (replacing 2 with 4*n); but gains the<br>
ability to refer to non-corresponding outputs.<br>
<br>
&gt; &gt; That would mean anyone who could do a valid spend of the tx could=
<br>
&gt; &gt; violate the covenant by spending to an unencumbered witness v2 ou=
tput<br>
&gt; &gt; and (by collaborating with a miner) steal the funds. I don&#39;t =
think<br>
&gt; &gt; there&#39;s a reasonable way to have existing covenants be forwar=
d<br>
&gt; &gt; compatible with future destination addresses (beyond something li=
ke CTV<br>
&gt; &gt; that strictly hardcodes them).<br>
&gt; That&#39;s a good catch, thanks for raising it :)<br>
&gt; Depends how you define reasonable, but I think one straightforward fix=
 is to<br>
&gt; extend the signature digest algorithm to encompass the segwit version =
(and<br>
&gt; maybe program-size ?) of the spending transaction outputs.<br>
<br>
That... doesn&#39;t sound very straightforward to me; it&#39;s basically<br=
>
introducing a new covenant approach, that&#39;s getting fixed into a<br>
signature, rather than being a separate opcode.<br>
<br>
I think a better approach for that would be to introduce the opcode (eg,<br=
>
PUSH_OUTPUT_SCRIPTPUBKEY, and SUBSTR to be able to analyse the segwit<br>
version), and make use of graftroot to allow a signature to declare that<br=
>
it&#39;s conditional on some extra script code. But it feels like it&#39;s =
going<br>
a bit off topic.<br>
<br>
&gt; &gt; Having the output position parameter might be an interesting way =
to<br>
&gt; &gt; merge/split a vault/pool, but it&#39;s not clear to me how much s=
ense it<br>
&gt; &gt; makes sense to optimise for that, rather than just doing that via=
 the key<br>
&gt; &gt; path. For pools, you want the key path to be common anyway (for p=
rivacy<br>
&gt; &gt; and efficiency), so it shouldn&#39;t be a problem; but even for v=
aults,<br>
&gt; &gt; you want the cold wallet accessible enough to be useful for the c=
ase<br>
&gt; &gt; where theft is attempted, and maybe that&#39;s also accessible en=
ough for<br>
&gt; &gt; the ocassional merge/split to keep your utxo count/sizes reasonab=
le.<br>
&gt; I think you can come up with interesting contract policies. Let&#39;s =
say you want<br>
&gt; to authorize the emergency path of your pool/vault balances if X happe=
ns (e.g a<br>
&gt; massive drop in USDT price signed by DLC oracles). You have (A+B+C+D) =
forking<br>
&gt; into (A+B) and (C+D) pooled funds. To conserve the contracts pre-negot=
iated<br>
&gt; economic equilibrium, all the participants would like the emergency pa=
th to be<br>
&gt; inherited on both forks. Without relying on the key path interactivity=
, which<br>
&gt; is ultimately a trust on the post-fork cooperation of your counterpart=
y ?<br>
<br>
I&#39;m not really sure what you&#39;re saying there; is that any different=
 to a<br>
pool of (A and B) where A suddenly wants to withdraw funds ASAP and can&#39=
;t<br>
wait for a key path signature? In that case A authorises the withdrawal<br>
and does whatever she wants with the funds (including form a new pool),<br>
and B remains in the pool.<br>
<br>
I don&#39;t think you can reliably have some arbitrary subset of the pool<b=
r>
able to withdraw atomically without using the key path -- if A,B,C,D have<b=
r>
individual scripts allowing withdrawal, then there&#39;s no way of setting<=
br>
the tree up so that every pair of members can have their scripts cut<br>
off without also cutting off one or both of the other members withdrawal<br=
>
scripts.<br>
<br>
If you know in advance which groups want to stick together, you could<br>
set things up as:<br>
<br>
=C2=A0 (((A, B), AB), C)<br>
<br>
where:<br>
<br>
=C2=A0 A =3D=C2=A0 =C2=A0&quot;A DUP H(B&#39;) 10 TLUV CHECKSIG&quot;=C2=A0=
 -&gt; (B&#39;, C)<br>
=C2=A0 B =3D=C2=A0 =C2=A0&quot;B DUP H(A&#39;) 10 TLUV CHECKSIG&quot;=C2=A0=
 -&gt; (A&#39;, C)<br>
=C2=A0 A&#39; =3D=C2=A0 &quot;A DUP 0 2 TLUV CHECKSIG&quot;=C2=A0 =C2=A0-&g=
t; (C)<br>
=C2=A0 B&#39; =3D=C2=A0 &quot;B DUP 0 2 TLUV CHECKSIG&quot;=C2=A0 =C2=A0-&g=
t; (C)<br>
=C2=A0 AB =3D=C2=A0 &quot;(A+B) DUP 6 TLUV CHECKSIG=C2=A0 -&gt; (C)<br>
=C2=A0 C=C2=A0 =3D=C2=A0 &quot;C DUP 0 2 TLUV CHECKSIG&quot;=C2=A0 =C2=A0-&=
gt; ((A,B), AB)<br>
<br>
(10 =3D 2+4*2 =3D drop my script, my sibling and my uncle; 6 =3D 2+4*1 =3D<=
br>
drop my script and my sibling; 2 =3D drop my script only)<br>
<br>
Which would let A and B exit together in a single tx rather than needing tw=
o<br>
transactions to exit separately.<br>
<br>
&gt; &gt; Saving a byte of witness data at the cost of specifying additiona=
l<br>
&gt; &gt; opcodes seems like optimising the wrong thing to me.<br>
&gt; I think we should keep in mind that any overhead cost in the usage of =
a script<br>
&gt; primitive is echoed to the user of off-chain contract/payment channels=
. If the<br>
&gt; tapscripts are bigger, your average on-chain spends in case of non-coo=
perative<br>
&gt; scenarios are increased in consequence, and as such your fee-bumping r=
eserve.<br>
&gt; Thus making those systems less economically accessible.<br>
<br>
If you&#39;re worried about the cost of a single byte of witness data you<b=
r>
probably can&#39;t afford to do script path spends at all -- certainly<br>
having to do 64 bytes of witness data to add a signature that commits<br>
to an amount and the like will be infeasible in that case.<br>
<br>
&gt; &gt; I don&#39;t think that works, because different scripts in the sa=
me merkle<br>
&gt; &gt; tree can have different script versions, which would here indicat=
e<br>
&gt; &gt; different parities for the same internal pub key.<br>
&gt; Let me make it clearer. We introduce a new tapscript version 0x20, for=
cing a<br>
&gt; new bit in the first byte of the control block to be interpreted as th=
e parity<br>
&gt; bit of the spent internal pubkey.<br>
<br>
That doesn&#39;t work. Suppose you start off with an even internal pubkey,<=
br>
with three scripts, (A, (B,C)). All of those scripts have tapscript<br>
version 0xc0 because the internal pubkey is even. You spend using A and<br>
calculate the new internal pubkey which turns out to be odd. You then<br>
need to change B and C&#39;s script version from 0xc0 to 0x20, but you can&=
#39;t<br>
do that (at least, you can&#39;t do it without revealing every script).<br>
<br>
&gt; To ensure this parity bit is faithful and<br>
&gt; won&#39;t break the updated key path, it&#39;s committed in the spent =
taptweak.<br>
<br>
Changing the TapTweak calculation is a hard fork; existing software<br>
already verifies the calculation even if the script version is unknown.<br>
<br>
&gt; &gt; The IN_OUT_AMOUNT opcode lets you do maths on the values, so you =
can<br>
&gt; &gt; specify &quot;hot wallets can withdraw up to X&quot; rather than =
&quot;hot wallets<br>
&gt; &gt; must withdraw exactly X&quot;. I don&#39;t think there&#39;s a wa=
y of doing that with<br>
&gt; &gt; SIGHASH_GROUP, even with a modifier like ANYPUBKEY?<br>
&gt; You can exchange signatures for withdraw outputs with multiples `nValu=
e`<br>
&gt; covering the authorized range, assuming the ANYAMOUNT modifier ?<br>
<br>
If you want your hotwallet to be able to withdraw up to $2000, that&#39;s<b=
r>
around 4,000,000 sats, so you&#39;d be doing up to 4M signatures there if y=
ou<br>
wanted to get the exact value you&#39;re trying to send, without having to<=
br>
either overpay, or first pay yourself then have another tx that splits<br>
your withdrawal into what you&#39;re spending and change that&#39;s no long=
er<br>
in your vault.<br>
<br>
&gt; One advantage<br>
&gt; of leveraging sighash is the ability to update a withdraw policy in re=
al-time.<br>
&gt; Vaults participants might be willing to bump the withdraw policy beyon=
d X,<br>
&gt; assuming you have N-of-M consents.<br>
<br>
I mean, maybe? It seems like a very heavy weight construct where a more<br>
general approach would probably be better (eg, graftroot to attach a<br>
script to a signature; or checkdatasig or whatever so you push a value<br>
to the stack then check it&#39;s signature, then reuse the authenticated<br=
>
data against other checks) so that you only have to supply a signature<br>
when you want to be able to approve things after the fact.<br>
<br>
&gt; I think I would like to express the following contract policy. Let&#39=
;s say you<br>
&gt; have 1) a one-time conditional script path to withdraw fund (&quot;a p=
ut on strike<br>
&gt; price X&quot;), 2) a conditional script path to tweak by 3 months all =
the usual<br>
&gt; withdraw path and 3) those remaining withdraw paths. Once played out, =
you would<br>
&gt; like the one-time path to be removed from your merkle tree. And this r=
emoval to<br>
&gt; be inherited on the tweaked tree if 2) plays out.<br>
<br>
Okay, so I think that means we&#39;ve got the unconditional withdraw path<b=
r>
&quot;U&quot; (your 1), the delay path &quot;D&quot; (your 2) and some norm=
al path(s) &quot;N&quot;<br>
(your 3). I think you can get that behaviour with:<br>
<br>
=C2=A0 =C2=A0S1 =3D Merkle( U, (D, N) )<br>
=C2=A0 =C2=A0S2 =3D Merkle( U, W )<br>
=C2=A0 =C2=A0S3 =3D Merkle( N )<br>
<br>
that is, you start off with the funds in scriptPubKey S1, then spend<br>
using D to get to S2, then spend using W to get to S3, then presumably<br>
spend using N at some point.<br>
<br>
The script for W is just:<br>
<br>
=C2=A0 =C2=A0&quot;IN_OUT_AMOUNT EQUALVERIFY 0 &lt;N&gt; 6 TLUV &lt;3 month=
s&gt; CSV&quot;=C2=A0 =C2=A0<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(drop the script, drop its sibling, add N, wait =
3 months)<br>
<br>
The script for D is:<br>
<br>
=C2=A0 =C2=A0&quot;IN_OUT_AMOUNT EQUALVERIFY 0 &lt;W&gt; 6 TLUV &lt;sigchec=
k...&gt;&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(drop the script, drop its sibling, add W, extra=
 conditions<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to avoid anyone being able to delay things)<br>
<br>
That is, the strategy isn&#39;t &quot;tweak the scripts by delaying them 3 =
months&quot;<br>
it&#39;s &quot;tweak the merkle tree, to replace the scripts that would be =
delayed<br>
with a new script that has a delay and then allows itself to be replaced<br=
>
by the original scripts that we now want back&quot;.<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div>

--0000000000006b469205cc459ff4--