From previous questions this bitcoin 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh address had an invalid public key of "00" and was unspendable but the coins are now spent?? The invalid key was generated by a bug in the wallet software the owner was using and should have been "locked" due to the invalid key

see link to the owners original query https://www.reddit.com/r/Bitcoin/comments/2t3vn0/i_cant_send_my_btc_a_triangle_apear_i_use_multibit/

also see link to a paper that lists that this is an invalid key https://www.microsoft.com/en-us/research/wp-content/uploads/2013/11/734.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F204914%2F734.pdf

see page 11

  • "00" is not a private key, so it certainly wasn't the key for that address. – Pieter Wuille Dec 20 '17 at 23:42
  • @PieterWuille: It looks like the paper of Bos et al uses 00 for the "point at infinity" public key (not private key). So there is a valid and interesting question here - either they were mistaken in their claim that it is unspendable (which might have to do with some interesting mathematical property of ECDSA), or else someone has broken ECDSA and/or RIPEMD-160 (which would be interesting for obvious reasons, though pretty unlikely). – Nate Eldredge Dec 21 '17 at 6:40
  • 2
    Oh - the spending transaction is unconfirmed. So another possibility is that it actually isn't a valid transaction, but blockchain.info mistakenly thinks that it is (perhaps because they use some homebrew validation code instead of the consensus algorithm)? – Nate Eldredge Dec 21 '17 at 7:06
  • The point at infinity is not a valid public key. – Pieter Wuille Dec 21 '17 at 7:23
  • @ Nate Eldredge . Oh ok, I see now it says "unconfirmed". How long does it stay in unconfirmed state before being returned or rejected? – MShepstone Dec 22 '17 at 7:05

That address cannot be spent from and any such transaction that spends from it is invalid. However this does not prevent improperly written software from thinking its private key is a valid private and and performing the elliptic curve operations on it. So thus the address was created and a transaction was created that appears valid. But when validating the transaction with proper software, such software rejects it.

This transaction appears on blockchain.info likely because their software is either improperly implemented or simply not validating (or fully validating) transactions. This isn't the first time that's happened though.

  • That is correct. The address was used as an input in an unconfirmed transaction Received Time 2017-05-24 01:24:03 - it will never confirm: blockchain.info/tx/… – Willtech Mar 1 '18 at 8:16

Here is the information on the account you are looking for.


Uncompressed WIF: 5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDU2KYEqetwr388P

Uncompressed public key: EMPTY

Uncompressed address: 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh


Compressed WIF: L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFqRzExJJ

Compressed public key: EMPTY

Compressed address: 1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh


  • This does not answer the question – MeshCollider Dec 31 '17 at 0:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.