Peter Todd [ARCHIVE] on Nostr: š Original date posted:2023-02-03 šļø Summary of this message: Using OP_TRUE ...
š
Original date posted:2023-02-03
šļø Summary of this message: Using OP_TRUE as the canonical anyone-can-spend output is recommended to avoid malleability issues and ensure standardness rules are followed.
š Original message:On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> stack,
> which plays better with other standardness rules.
>
> What other standardness rules? MINAMALIF? How does that interact with the
> proposal?
It makes sense to require scripts to leave just a single OP_TRUE on the stack
at the end of execution, as otherwise that can be a source of malleability in
certain circumstances where the scriptSig ends up providing the OP_TRUE. I
don't believe we actually implement this as a rule right now. But you could
easily imagine that happening in a future upgrade.
Leaving an OP_2 on the stack doesn't achieve that and would require a
special-cased workaround. Spending the time now to do the obvious thing - use
OP_TRUE as the canonical anyone-can-spend output - avoids this issue.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230203/e563fd6c/attachment.sig>
šļø Summary of this message: Using OP_TRUE as the canonical anyone-can-spend output is recommended to avoid malleability issues and ensure standardness rules are followed.
š Original message:On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> stack,
> which plays better with other standardness rules.
>
> What other standardness rules? MINAMALIF? How does that interact with the
> proposal?
It makes sense to require scripts to leave just a single OP_TRUE on the stack
at the end of execution, as otherwise that can be a source of malleability in
certain circumstances where the scriptSig ends up providing the OP_TRUE. I
don't believe we actually implement this as a rule right now. But you could
easily imagine that happening in a future upgrade.
Leaving an OP_2 on the stack doesn't achieve that and would require a
special-cased workaround. Spending the time now to do the obvious thing - use
OP_TRUE as the canonical anyone-can-spend output - avoids this issue.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230203/e563fd6c/attachment.sig>