Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-25 📝 Original message:On Sun, Apr 24, 2022 at ...
📅 Original date posted:2022-04-25
📝 Original message: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/20220425/99e1a76f/attachment.html>;
📝 Original message: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/20220425/99e1a76f/attachment.html>;