I'm writing a blockchain parser and I keep running into this type of scriptPubKey in the Litecoin blockchain:


The length suggests they might be compressed public keys but there is no parity byte. I can look at a few dozens of these and all bytes vary, except for the prefix 20 which is the length.

Blockchair seems to parse these as 's-something' addresses, like this:



What are these addresses, and how is it doing that? I assume they artificially add the s- because dash in not in base58, but I can't get anything to match the address to the right of it either.

I've tried the regular way of compressing other formats like this:

temp = prefix + hash160(scriptPubKey)
address = base58Check(temp + checksum(temp))

With and without checksum, with and without hash160. Even scanning for all possible prefix bytes I can't get the address to the right of the dash.

I've discovered that I have to base58 something with 23 bytes to get the target length, but that's about it.

Other parsers can't seem to decode this address (see links on blockchair page itself), only blockchair.

2 Answers 2


These are not public keys. Not everything that is 33 bytes is a public key. In this case, it is a 32 byte hash. The first byte indicates that the next 32 bytes are to be pushed to the stack. So the result is that the actual data in this scriptPubKey is a 32 byte string.

In this case, this particular transaction is a coinbase transaction in a block mined by p2pool. This particular script is some p2pool specific data and is a hash, not a public key.


These are not public keys, they are data or bitcoin script fragments.

For example, the address s-38f26094a4e3514933fc2bf56a1f2f26 is actually the bitcoin script:


Addresses are a human construct, and only certain well defined bitcoin scripts (p2pk, p2pkh, p2sh, p2wpkh, p2wsh) are convertable to addresses. All other scriptPubKeys (or locking scripts, if you prefer to call them that) are non-standard outputs, and are interpreted by different explorers in different ways. Blockchair seems to prefer a s- prefix followed by some kind of hash of the raw script.

  • That is a known case, and I'm getting those too. That is a bug, and those op codes translate to the ascii word "script" according to this article: medium.com/@alcio/…. This is a different situation though, as the pubkey is clearly hashed, and there are hundreds and thousands of those constantly. It must be some kind of standard format, and even its a script, it must be decodable so that it can be verified in some way. I'd be ok with having just the plaintext script
    – Daniel
    Jul 6, 2019 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.