Rijndael [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-25 📝 Original message:Hello Andrew, As ZmnSCPxj ...
📅 Original date posted:2022-11-25
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev