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/49c22f63beb61811ab87b6bfd0b04335e5684bea89d2760213e1f650853cb6f1The data for the key is:
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/d37e9d75ea61dd3f019626f077d74081bca0e80336ae9263cb362c094444c075The data for the key is:
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.0There 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.