What is Nostr?
Greg Sanders [ARCHIVE] /
npub1jdl…gh0m
2023-06-07 23:19:19
in reply to nevent1q…yahk

Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-04 🗒️ Summary of this message: Proposal to use ...

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Proposal to use OP_TRUE as the canonical anyone-can-spend output to avoid malleability issues and ensure standardness rules are met.
📝 Original message:I'm not particularly persuaded, but also not wedded to either idea.

Fixed up tests for the OP_TRUE case here:
https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true

On Fri, Feb 3, 2023 at 5:10 PM Peter Todd <pete at petertodd.org> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230203/f6d3bb53/attachment-0001.html>;
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0m