📅 Original date posted:2023-02-02
🗒️ Summary of this message: The proposal to use OP_TRUE instead of OP_2 is more standard and avoids the need for special cases in other standardness rules.
📝 Original message:> 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?
On Thu, Feb 2, 2023 at 3:22 PM Peter Todd <pete at petertodd.org> wrote:
> On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote:
> > Quickly checked, it fails a number of standardness tests in
> unit/functional
> > tests in Bitcoin Core, at least.
> >
> > OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
> > just independently arrived at the same conclusion.
>
> Well, frankly I really don't like the idea of using OP_2 just to avoid
> changing
> some unit tests. We're doing something that many people will use for years
> to
> come, that's unnecessarily obscure just because we don't want to spend a
> bit of
> some modifying some tests to pass.
>
> 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. OP_2 means we *also* may
> need
> to special case having a 2 on the stack in certain implementations of other
> standardness rules.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/b4d28f33/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-07 23:19:18
in reply to nevent1q…pt9h
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 23:19:18Event JSON
{
"id": "40f542fc5f42e7d15cf92066115409b010c137525ecdc6072cb259dd1160f00a",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686179958,
"kind": 1,
"tags": [
[
"e",
"143dbfe19a8d8d54226104036fa4a08fd39aa80019fe1af67513152c53af0150",
"",
"root"
],
[
"e",
"001373ca1b28f0f6658f4b239049e126d393a8b1aeeff2711174f3acf06d3a3c",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2023-02-02\n🗒️ Summary of this message: The proposal to use OP_TRUE instead of OP_2 is more standard and avoids the need for special cases in other standardness rules.\n📝 Original message:\u003e OP_TRUE is the obvious way to do this, and it results with a 1 on the\nstack,\nwhich plays better with other standardness rules.\n\nWhat other standardness rules? MINAMALIF? How does that interact with the\nproposal?\n\nOn Thu, Feb 2, 2023 at 3:22 PM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote:\n\u003e \u003e Quickly checked, it fails a number of standardness tests in\n\u003e unit/functional\n\u003e \u003e tests in Bitcoin Core, at least.\n\u003e \u003e\n\u003e \u003e OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I\n\u003e \u003e just independently arrived at the same conclusion.\n\u003e\n\u003e Well, frankly I really don't like the idea of using OP_2 just to avoid\n\u003e changing\n\u003e some unit tests. We're doing something that many people will use for years\n\u003e to\n\u003e come, that's unnecessarily obscure just because we don't want to spend a\n\u003e bit of\n\u003e some modifying some tests to pass.\n\u003e\n\u003e OP_TRUE is the obvious way to do this, and it results with a 1 on the\n\u003e stack,\n\u003e which plays better with other standardness rules. OP_2 means we *also* may\n\u003e need\n\u003e to special case having a 2 on the stack in certain implementations of other\n\u003e standardness rules.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/b4d28f33/attachment.html\u003e",
"sig": "537380d874cc274a8a2abe6e5cff3a2cb9b71b7bb18a40bf28cecc3b518dcb4c4e1d7b8dced4830469755ec3e35f6e3bfffae9bafacef9d7d31661bc12a9dfb9"
}