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
