Date: Sat, 26 Nov 2022 00:12:10 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Andrew Melnychuk Oseen <amo.personal@protonmail.com>
From: Rijndael <rot13maxi@protonmail.com>
Message-ID: <5ded6a45-9e79-511b-f1db-384168102890@protonmail.com>
In-Reply-To: <Kcqi_Svol1F4H8rGnnECZXRkb5Aa_763DlNUP4froIqLovFk-SrOnWXC5ZPtfRjzHb55_BTe07h6PH5OdaY2zpNPNTix__bqYiBIEw2IbjA=@protonmail.com>
References: <zKbMpqEqH6Z4p1GE2rlsOky1fMPBsEFGaeNk8WIcbez__-fR3ahnYEWOgExHC8KXAYCqtt4gMa7WBXkNSqL6fO9sjsvyu9AZRPQIQADqthg=@protonmail.com>
 <Kcqi_Svol1F4H8rGnnECZXRkb5Aa_763DlNUP4froIqLovFk-SrOnWXC5ZPtfRjzHb55_BTe07h6PH5OdaY2zpNPNTix__bqYiBIEw2IbjA=@protonmail.com>
Feedback-ID: 41648937:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Relative txout amounts with a Merkleized Sum Tree
	and explicit miner fee.
Precedence: list

Hello Andrew,

As ZmnSCPxj mentioned, covenant schemes are probably something that you
should be looking at and thinking about. In addition to CTV, I'd also
recommend you take a look (if you haven't already) at
`TAPLEAF_UPDATE_VERIFY`
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019=
419.html).
 From your description, it sounds like you may be barking up a similar tree=
.

Rijndael


On 11/21/22 6:52 PM, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Andrew,
>
>>
>> Can output amounts be mapped to a tap branch? For the goal of secure par=
tial spends of a single UTXO? Looking for feedback on this idea. I got it f=
rom Taro.
>
> Not at all.
>
> The issue you are facing here is that only one tap branch will ever consu=
me the entire input amount.
> That is: while Taproot has multiple leaves, only exactly one leaf will ev=
er be published onchain and that gets the whole amount.
>
> What you want is multiple tree leaves where ALL of them will EVENTUALLY b=
e published, just not right now.
>
> In that case, look at the tree structures for `OP_CHECKTEMPLATEVERIFY`, w=
hich are exactly what you are looking for, and help make `OP_CTV` a reality=
.
>
> Without `OP_CHECKTEMPLATEVERIFY` it is possible to use presigned transact=
ions in a tree structure to do this same construction.
> Presigned transactions are known to be larger than `OP_CHECKTEMPLATEVERIF=
Y` --- signatures on taproot are 64 bytes of witness, but an `OP_CHECKTEMPL=
ATEVERIFY` in a P2WSH reveals just 32 bytes of witness plus the `OP_CHECKTE=
MPLATEVERIFY` opcode.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev