@Russell > OP_PUBKEY, and OP_PUBKEYHASH as wildcards Ah I see. Very interesting. Thanks for clarifying.
@Nadav > You can have a CTV vault where the hot key signer is a multisig to get the advantages of both. Yes, you can create a CTV vault setup where you unvault to a multisig wallet, but you don't get the advantages of both. Rather you get none of the advantages and still have all the downsides you get with a multisig wallet. The whole point of a wallet vault is that you can get the security of a multisig wallet without having to sign using as many keys. On Mon, Apr 25, 2022 at 5:28 PM Russell O'Connor <rocon...@blockstream.com> wrote: > On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tet...@gmail.com> > wrote: > >> @Russel >> > the original MES vault .. commits to the destination address during >> unvaulting >> >> I see. Looking at the MES16 paper, OP_COV isn't described clearly enough >> for me to understand that it does that. However, I can imagine how it >> *might* do that. >> >> One possibility is that the intended destination is predetermined and >> hardcoded. This wouldn't be very useful, and also wouldn't be different >> than how CTV could do it, so I assume that isn't what you envisioned this >> doing. >> >> I can imagine instead that the definition of the pattern could be >> specified as a number indicating the number of stack items in the pattern, >> followed by that number of stack items. If that's how it is done, I can see >> the user inputting an intended destination script (corresponding to the >> intended destination address) which would then be somehow rotated in to the >> right spot within the pattern, allowing the pattern to specify the coins >> eventually reaching an address with that script. However, this could be >> quite cumbersome, and would require fully specifying the scripts along the >> covenant pathways leading to a fair amount of information duplication >> (since scripts must be specified both in the covenant and in spending the >> subsequent output). Both of these things would seem to make OP_COV in >> practice quite an expensive opcode to spend with. It also means that, since >> the transactor must fully specify the script, its not possible to take >> advantage of taproot's script hiding capabilities (were it to send to a >> taproot address). >> > > So my understanding is that the COV proposal in MES lets you check that > the output's scriptPubKey matches the corresponding script item from the > stack, but the script item's value additionally allows some wildcard > values. In particular, it makes use of the otherwise reserved opcodes > OP_PUBKEY, and OP_PUBKEYHASH as wildcards representing any, let's say, > 32-byte or 20-byte push value. > > If you just used COV by itself, then these wildcards would be third-party > malleable, but you also have to sign the transaction with the hot wallet > key, which removes the malleability. > > No need to rotate anything into place. > > I hope this makes sense. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
