prettier is adding this new line on my machine. separate issue that I still haven't clarified which repos prettier is hitting with arc lint.

imo this should always just be '04', since all of the other ways of pushing for this are inefficient (take up more space than necessary to do the same thing).

But this is also true for all the other pushes of the spec (no pushes can be long enough to require 4c, let alone 4d or 4e).

However, now that we have a library which arbitrarily returns any valid OP_RETURN push, enforcing this would require additional logic to check not only the next valid push but also something like isMinimalPush: true. Not sure if this complication is worth it, given that anyone making such weird pushes is probably rare enough...and at any rate they must pay the appropriate fee to get the tx on the network.

If it's a valid tx, should probably take it. It would be nice if there were only one valid way to push a 4 byte protocol identifier at the protocol level but perhaps impractical to adjust there for other reasons.

Note: the logic of parseAliasTx will need to be further adjusted to confirm the version 00 is a one-byte push of OP_0. If we just parse the whole OP_RETURN with consumeNextPush, then 4e0100000000 will also be valid.

...so perhaps there is a case to be made for isMinimalPush to be supported in the op_return library

interesting, TIL.

Yes, the cashaddress library supports the following hash sizes:

// Throw validation error if hash is of invalid size
// Per spec, valid hash sizes in bytes
const VALID_SIZES = [20, 24, 28, 32, 40, 48, 56, 64];

The reason for enforcing minimal push is that you can manage the protocol extension with no risk of overflowing the data carrier max size.
I think you made a very good point that enforcing minimal push is a good move :)

That's great. Sill we should restrict to 20 bytes for now as it will not be interoperable with other tools of the ecosystem

ok -- reverted / updated