Quote from: jratcliff63367 on December 30, 2014, 12:11:40 AM

I guess I have a similar question. I'm encountering a number of output scripts which have non-standard lengths for the public key.

Here is one where the public key is 37 bytes long:

https://blockchain.info/tx/49c22f63beb61811ab87b6bfd0b04335e5684bea89d2760213e1f650853cb6f1

The data for the key is:

Code:

4d 65 73 73 61 67 65 3a 20 68 74 74 70 3a 2f 2f
69 2e 69 6d 67 75 72 2e 63 6f 6d 2f 73 5a 38 64
30 2e 6a 70 67

The first byte is '0x4d'

Here is one where the public key is 58 bytes long:

https://blockchain.info/tx/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075

The data for the key is:

Code:

4d 65 73 73 61 67 65 3a 20 42 69 74 63 6f 69 6e
50 61 72 61 2e 64 65 20 44 69 76 69 64 65 6e 64
65 6e 7a 61 68 6c 75 6e 67 20 31 20 76 6f 6d 20
30 37 2e 30 39 2e 32 30 31 32

The first byte is 0x4d as well.

I'm not used to seeing public keys in the output scripts of such odd sizes. Why do they appear, and what is the proper rule to convert them into a bitcoin address? Is there a place that documents all of the way these signatures can be encoded (and converted to RIPEMD160 format) from a purely hex-dump perspective?

Thanks,

John

According to this post by DeathAndTaxes:
https://bitcointalk.org/index.php?topic=675321.0

There are 17112 unspent outputs that are permanently unspendable due to having an invalid public key. I suspect that these are two of those.

If you want to create a bitcoin address representation of an invalid public key that matches the representation that blockchain.info has decided to use, you can probably just calculate the address by hashing the invalid key. As such, your bitcoinPublicKeyToAddress script could be made more generic by counting up the number of bytes in the public key and then hashing it, regardless of whether there are 33 bytes, 65 bytes, or some other value entirely.