Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
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.)
I posted off-github:
I've rewritten the rationale to be non-SLP specific. It now focuses mostly on why encoding numbers in big-endian is desireable.
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
Simple proof-of-work check:
6 bytes, checks number of leading zeros.
5 bytes, checks whether the N leading bytes are a palindrome (
Pushing a large number (only relevant once we've got 64-bit or higher numbers):
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.
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
Similar with the already re-enabled
However, it seems many would eventually like to see