Topic: Bad Public Keys in Transaction Outputs (Read 1267 times)

Thank you for the reply and the data. I've been spending some time the past week or so reading through the Spin-offs thread. I know you built a parser for the utxo database to get your results. Is that code available?

When I have some more data, I will likely revive the Spin-offs thread with the results. I also have a few questions that would fit better in that thread.

Yes there are a number of outputs which are unspendable due to various errors when the transaction was created.  Some of the unspenable outputs are not provably unspendable but many are as there is no possible ScriptSig (input script) which could meet the impossible conditions set by the PkScript (output script).

bc.i routinely handles unusual cases badly.  It would be better for it to just say "malformed output unable to decode" instead of trying to guess but that is what they do.

This thread is on an unrelated topic but in writing a utxo parser I came across a number of badly formed transactions so you might find it interesting.
https://bitcointalk.org/index.php?topic=563972.340


Unless I made an error there are at least 16,000 outputs which can be provably classified as unspendable (not including OP_RETURN).  This shouldn't be considered exhaustive.  I only checked for gross errors (incorrectly sized pubkeys and missing or invalid prefixes were the most common).  I can check the code but I am not sure I even validated that all uncompressed pubkeys were on the curve. Note: I included zero value outputs because the purpose of the analysis was a distribution of value.  Zero value outputs are valid and spendable on the bitcoin network.

I am trying to parse the block chain and have come across some unusual transaction outputs. Maybe someone could enlighten me.

The first one is output 1 of tx b728387a3cf1dfcff1eef13706816327907f79f9366a7098ee48fc0c00ad2726.
https://blockchain.info/tx/b728387a3cf1dfcff1eef13706816327907f79f9366a7098ee48fc0c00ad2726?show_adv=true
The script is 64 <64 bytes> 172. It looks like the <64 bytes> should be the public key with the prefix missing. This seems like "Format 2" described by John Ratcliff, but it's the prefix that's missing, not the length. http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html The important thing is the (x,y) value I get from these 64 bytes is not on the curve, so it can't be a public key.

A bit later there is output 1 of tx 7729045ec9b7cfe62811c7fee5b9b2839a1e45f3827867776b6671cabae84462.
https://blockchain.info/tx/7729045ec9b7cfe62811c7fee5b9b2839a1e45f3827867776b6671cabae84462
Here the format is like a standard pubkey output script: 65 04 <64 bytes> 172, but the 64 bytes are actually the same as the previous example, which does not give a point on the curve.

In spite of the (x,y) not being on the curve, I can form a bitcoin address starting from 04 x y in the usual way and get the address 1HSrPfMA5joCS5vTnRWQF7GyeodLQZHu6e. This is the address shown by both blockchain.info and the Satoshi client for the second example. However, for the first example, blockchain.info reports the address 18EC4j7GGUenVxtxQ8xtgLm1oefxbki8ne while the Satoshi client reports the address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E. How are these other addresses calculated?

Are both of these outputs are provably unspendable?

Searching the forum for these txids and addresses, the only one I found was 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E (the one reported by the Satoshi client in the first example). It seems to be an address people have erroneously spent coins to before.

Explanations or links to explanations would be appreciated.