<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2019-07-06T16:48:02.150Z
2019-07-06T16:48:02.150Z
Ava Chow
<p>These are not public keys, they are data or bitcoin script fragments.</p>

<p>For example, the address <a href="https://blockchair.com/litecoin/address/s-38f26094a4e3514933fc2bf56a1f2f26" rel="nofollow noreferrer">s-38f26094a4e3514933fc2bf56a1f2f26</a> is actually the bitcoin script:</p>

<pre><code>OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH
</code></pre>

<p>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 <code>s-</code> prefix followed by some kind of hash of the raw script.</p>

CC BY-SA 4.0
2019-07-06T16:14:40.743Z
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: https://medium.com/@alcio/a-look-at-bitcoin-non-standard-outputs-c97f65cccbb6. 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
CC BY-SA 4.0
2019-07-06T16:04:31.883Z
2019-07-06T16:04:31.883Z
Raghav Sood
<p>I'm writing a blockchain parser and I keep running into this type of scriptPubKey in the Litecoin blockchain:</p>

<pre><code>20a75ca72ffd994d2004d67b0e89015913f7352455d0111ede590430037c9fe2ac
20e664c3f6909687499d9bf13108e35306477a8d71b20655a75cbc64270416a9f2
20651b85139631645bfd68327d85af913a7e33e74433848c5facfe48368c7d1504
20604f5ced8c595af687a0e8718098c4818b7d51f2ba79cca931dc74d6cdb8c021
</code></pre>

<p>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.</p>

<p>Blockchair seems to parse these as 's-something' addresses, like this:</p>

<p><a href="https://blockchair.com/litecoin/address/s-31fa6bd469e97be4fe639911ca60bddf" rel="nofollow noreferrer">https://blockchair.com/litecoin/address/s-31fa6bd469e97be4fe639911ca60bddf</a></p>

<p><a href="https://blockchair.com/litecoin/address/s-4e7d283f055044b547f571bfdbbdb291" rel="nofollow noreferrer">https://blockchair.com/litecoin/address/s-4e7d283f055044b547f571bfdbbdb291</a></p>

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

<p>I've tried the regular way of compressing other formats like this:</p>

<pre><code>temp = prefix + hash160(scriptPubKey)
address = base58Check(temp + checksum(temp))
</code></pre>

<p>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.</p>

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

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

<blockchain><address><litecoin>
Convert 33-byte public key with no parity prefix to address
Daniel
# Convert 33-byte public key with no parity prefix to address

(Asked by: username_0 on 2019-07-06)

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.

**Tags:** blockchain, address, litecoin


---

## 2 answers

### Answer by username_1 on 2019-07-06. Score: 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.


---

### Answer by username_2 on 2019-07-06. Score: 1

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

For example, the address [s-38f26094a4e3514933fc2bf56a1f2f26](https://blockchair.com/litecoin/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.

> **Comments:**
> **username_0**: 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: https://medium.com/@alcio/a-look-at-bitcoin-non-standard-outputs-c97f65cccbb6. 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  

---

