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/019419.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 partial
>> spends of a single UTXO? Looking for feedback on this idea. I got it from
>> Taro.
>
> Not at all.
>
> The issue you are facing here is that only one tap branch will ever consume
> the entire input amount.
> That is: while Taproot has multiple leaves, only exactly one leaf will ever
> be published onchain and that gets the whole amount.
>
> What you want is multiple tree leaves where ALL of them will EVENTUALLY be
> published, just not right now.
>
> In that case, look at the tree structures for `OP_CHECKTEMPLATEVERIFY`, which
> are exactly what you are looking for, and help make `OP_CTV` a reality.
>
> Without `OP_CHECKTEMPLATEVERIFY` it is possible to use presigned transactions
> in a tree structure to do this same construction.
> Presigned transactions are known to be larger than `OP_CHECKTEMPLATEVERIFY`
> --- signatures on taproot are 64 bytes of witness, but an
> `OP_CHECKTEMPLATEVERIFY` in a P2WSH reveals just 32 bytes of witness plus the
> `OP_CHECKTEMPLATEVERIFY` opcode.
>
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
