This is a great idea! Though of course, whether it comes in November will depend a lot if there is the dev bandwidth to actually make this consensus change. (Though the change itself is almost trivial, it requires activation logic + lots of testing.)

Why doesn't SLP use little endian instead?

I posted off-github:

Can you emphasize more on this point — "Further, there's likely many additional use cases beside encoding SLP values, as many protocols outside of Bitcoin use big endian numbers, and all of them would benefit from this opcode.".
Complex SLP covenants on their own don't seem like sufficient justification and the way you write the document seems very single-purpose to that one goal."

Specifically: why wouldn't the big-endian to little-endian conversion when interacting with "protocols outside of Bitcoin" happen off-chain?

I posted off-github:

Can you emphasize more on this point — "Further, there's likely many additional use cases beside encoding SLP values, as many protocols outside of Bitcoin use big endian numbers, and all of them would benefit from this opcode.".
Complex SLP covenants on their own don't seem like sufficient justification and the way you write the document seems very single-purpose to that one goal."

I've rewritten the rationale to be non-SLP specific. It now focuses mostly on why encoding numbers in big-endian is desireable.

@markblundeberg Thoughts on the updated version? c26607c

Hmm interesting, though it still feels like most protocols can just adapt and provide little endian numbers. Do you see any use case besides endianness conversions?

Do you see any use case besides endianness conversions?

There aren't many; but given the crazy things some C developers came up with for optimizing their code (like fast inverse square root), there's probably some real-life function that corresponds to reversing the bytes of an integer.

Otherwise, on the top of my head, I came up with these additional use cases, which are just versions of already possible things, but requiring less fewer bytes:

Simple proof-of-work check:

Without OP_REVERSE:

<proof-of-work>
<target bytes>
OP_SPLIT
0
<target bytes>
OP_NUM2BIN
OP_EQUALVERIFY

6 bytes, checks number of leading zeros.

With OP_REVERSE:

<proof-of-work>
<target bytes>
OP_SPLIT
OP_DUP
OP_REVERSE
OP_EQUALVERIFY

5 bytes, checks whether the N leading bytes are a palindrome (<target bytes> must be twice as large as in the previous script for the same difficulty).

Pushing a large number (only relevant once we've got 64-bit or higher numbers):

Without OP_REVERSE:

0x00 00 00 00  00 00 00 01 (=72057594037927936)

8 bytes

With OP_REVERSE:

1
8
OP_NUM2BIN
OP_REVERSE

4 bytes

With 256-bit numbers, the first one would take 32 bytes whereas the second one would take 5 bytes.

I know, the benefit is either niche or not really significant, but it is a possible use case.

most protocols can just adapt and provide little endian numbers

That's true, but not all protocols can just adapt, which is not possible for SLP tokens.

One more point on endianness:

Most services (explorer.bitcoin.com/rest.bitcoin.com, Bitdb, etc.) and protocols (most notably, SLP tokens) encode hashes (e.g. transaction hashes) in big endian. However, OP_SHA256 and OP_HASH256 encode hashes in little endian. If a script would calculate the hash of some external transaction and compare it to an input, or match the input against the outpoint, that input would have to be encoded in a little endian hash, making interaction with e.g. bitcoin.com's REST API and Bitdb very cumbersome.

Of course, it's possible to add a switch/function to those services, but that will make interaction unnecessarily confusing and increase the congnitive load needlessly.

At the end, it's mostly a question of goals: Should things be easy to do or is it already sufficient if they're just possible? For example, should we re-enable OP_MUL? As far as I'm able to tell, developers can just rearrange the terms of the formula and push products as inputs instead of factors.

Similar with the already re-enabled OP_NUM2BIN and OP_BIN2NUM: developers could just push numbers in the required format (minimal encoding/N-byte encoding), and if conversion is necessary, they could just use OP_SPLIT and OP_CAT.

However, it seems many would eventually like to see OP_MUL re-enabled, and OP_NUM2BIN and OP_BIN2NUM already has been, not because it offers new functionality, but because it makes interaction with Bitcoin Cash and Script easier, more approachable and, especially, safer. The same holds for OP_REVERSE: While technically many protocols can adapt (even the SLP protocol could be changed to support both big-endian and little-endian), it would require, at best (e.g. for a price oracle), just switching out a function call, worse (e.g. for interacting with Bitdb/rest.bitcoin.com) complicated switches/functions, or at worst (like for the SLP token) an immense effort to upgrade all participants to a new protocol.

I think there's better ways to do something like OP_REVERSE, so I'm closing the PR.

Amaury (@deadalnix ) has suggested changing the name to "BSWAP", to match the similar instruction in other languages:

https://docs.rs/bswap/1.0.0/bswap/

https://www.npmjs.com/package/bswap

I agree with the renaming of OP_REVERSE -> OP_BSWAP

BSWAP is a x86 instruction so is a common name.
Another name could be OP_ENDIAN_REVERSE, as in Boost: https://www.boost.org/doc/libs/1_63_0/libs/endian/doc/conversion.html#endian_reverse

Sorry to crash the renaming party, but I'd like to propose OP_REVERSEENDIAN, based on current naming conventions.

1. No existing opcode name contains any underscore, dash, or space after the initial OP_, only letters and digits, not even when the name is composed from multiple words (e.g. OP_GREATERTHANOREQUAL), not even when the opcode is a contracted shorthand of two opcodes (e.g. OP_EQUALVERIFY, OP_1NEGATE).
2. Existing opcodes place the verb before the noun (e.g. it's OP_CHECKSIG, OP_PUSHDATAn). While the full noun is 'endianness', abbreviating this to 'endian' seems acceptable, as existing opcode names also contain many abbreviations (e.g. 'sig' for 'signature', 'num' for 'number').

I agree with @BigBlockIfTrue . BSWAP's meaning is domain-knowledge dependent (if you're unfamiliar with x86 assembly then its name means nothing to you). There is little question about what OP_REVERSEENDIAN does. Furthermore, its naming convention is consistent to the other OP codes.

(That being said, the name of the opcode is fairly unimportant in the grand scheme of things, so hopefully not too much time will be invested in deciding its name.)

oh true

Sorry to prolong this bikeshedding, but I'll repeat what I said in the review of the ABC Diff for the implementation of this (https://reviews.bitcoinabc.org/D4871).

I'm not a fan of using the term "Endian" to me seems hardware specific, and usually implies some power-of-2 number of bytes. This opcode will be able to reverse bytes in strings of any length. "Endian" is a technical jargon term, and to me seems confusing.

I also think it's possible people may use this opcode for things other than endian conversion, since it can reverse the byte order for any arbitrary-length string.

I would suggest "OP_REVERSEBYTES". It fits with the criteria @BigBlockIfTrue mentioned, and it seems like just a straight description of what it does, without any jargon.

Thanks everyone for the valuable feedback. As someone who writes Script by hand, having nice opcode names is not unimportant.

To put an end to the bikeshed, I‘ll use the opcode name OP_REVERSEBYTES now and if anyone wants to have a different name they‘re free to fork the code.