1

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

20a75ca72ffd994d2004d67b0e89015913f7352455d0111ede590430037c9fe2ac
20e664c3f6909687499d9bf13108e35306477a8d71b20655a75cbc64270416a9f2
20651b85139631645bfd68327d85af913a7e33e74433848c5facfe48368c7d1504
20604f5ced8c595af687a0e8718098c4818b7d51f2ba79cca931dc74d6cdb8c021

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:

https://blockchair.com/litecoin/address/s-31fa6bd469e97be4fe639911ca60bddf

https://blockchair.com/litecoin/address/s-4e7d283f055044b547f571bfdbbdb291

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

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.

1

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

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

OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH

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.

1
  • 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, privacy policy and cookie policy

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