Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-26 📝 Original message:@Russell > OP_PUBKEY, and ...
📅 Original date posted:2022-04-26
📝 Original message:@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 <roconnor at blockstream.com>
wrote:
> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/3a386891/attachment-0001.html>;
📝 Original message:@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 <roconnor at blockstream.com>
wrote:
> On Sun, Apr 24, 2022 at 7:04 PM Billy Tetrud <billy.tetrud at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/3a386891/attachment-0001.html>;