Unparsed address [0]

[ByronAP]

After 4 days of syncing my install is finally up to date but most addresses show "Unparsed address [0]"

[gabegattis]

I think that is normal behavior for non-standard outputs, (like OP_RETURN outputs), but it should not show that for most transactions, which have standard outputs. Could you provide an example of a tx where you are seeing this, but you don't think you should be?

[Biersteker]

Having the same issue as ByronAP, For example outputs from: f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

[gabegattis]

@Biersteker Thanks for that txid. That helped a lot.

So the "Unparsed address[0]" part is not a bug.

Transaction f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 redeems the output from transaction 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9.

The output on 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9 is a pay-to-public-key output. In the input section of https://insight.bitpay.com/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16, it shows as unparsed address because that transaction sent to a public key, not an address.

There is a bug in the outputs section though. In https://insight.bitpay.com/tx/0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9, we show the output as a pay-to-public-key-hash output, which is wrong. This should also show up as an unparsed address instead of 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S.

@braydonf I haven't looked at the code yet, but I suspect we might be using the verbose getrawtransaction to fill in output info. When I run:

decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d0134ffffffff0100f2052a0100000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000

I get this

{
  "txid": "0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9",
  "size": 134,
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "04ffff001d0134",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 50.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3 OP_CHECKSIG",
        "hex": "410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac",
        "reqSigs": 1,
        "type": "pubkey",
        "addresses": [
          "12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S"
        ]
      }
    }
  ]
}

which is coercing the pubkey to an address.

[braydonf]

Thanks for digging into this @gabegattis

We should probably check that vout scriptPubKey type equals pubkeyhash at https://github.com/bitpay/bitcore-node/blob/master/lib/services/bitcoind.js#L1919-1922 (or equivalent in bitcoind), especially makes sense that pay-to-publickey isn't indexed (by coercing into an address).

[gabegattis]

@braydonf Agreed. In addition, we may also want to change the code in bitcoind to only show an address if it detects the type as P2PKH or P2SH. That behavior has always bugged me.

[ByronAP]

I don't understand the logic behind not parsing them to an address hash

[braydonf]

Rationale is that the address prefix 00 has the meaning of pay-to-pub-key-hash (p2pkh). And pay-to-pub-key (p2pk) actually doesn't have an address, otherwise it would be p2pkh.

[ByronAP]

yes but you should be able to create a p2pkh from a p2pk right?

[gabegattis]

You can use a pubkey to get a pubkey hash, and then encode that as an actual bitcoin address. However, it would still be incorrect to show the output as going to an address, because that is not actually what happened. The output script is a pay-to-pubkey script, not a pay-to-pubkey-hash script. Likewise, the transaction that redeems that output will have a different input script if it is redeeming a p2pk output instead of a p2pkh output.

For sake of clarity and correctness, we should not show an address in this case. There might be a good argument for displaying the actual pubkey as such, instead of "Unparsed address".

[ByronAP]

it should be made to be able to keep track of p2pk just as if it were p2pkh, however there is the argument that p2pk is rare... "unparsed address" makes it sound like the system is still processing the chain or that there is a problem.

[gabegattis]

Maybe something like "unparseable script" or "non-standard script" or "unsupported script type" would be a better message.

[Biersteker]

I kind of have my reservations about doing p2pub => p2pubhash in indexing.(Because its factual incorrect) But the transaction i linked was the Hall Finney transaction.That is being referenced by pubkeyhash in the wild , which ofc isn't strict behavior . (Because its a pay to pubkey, not pay to pubkey hash.). But still it is one transaction that should be able to be looked up. pay to pubkey is rare, but for archive keeping i would suggest that it should be indexable by pubkeyhash (Even if its just wrong) and report the pubkey aswell. Reporting unparseble script would just be wrong. Because it isn't

[ByronAP]

"it should be indexable by pubkeyhash (Even if its just wrong) and report the pubkey aswel" agree

[gost1402]

Hi everyone , Please I'm new here . Please I need help a friend sent me btc but I didn't get it and when I check on blockchain it show that my wallet is Unparsed address and the payment went to a strange wallet . Please I would appreciate your help .