<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2018-03-01T08:16:43.323Z
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: https://blockchain.info/tx/ba8a7fb13a507a4987bfa267a6f12defc0d30216fdf6664cdc06cc4c8de71a84
Willtech
CC BY-SA 3.0
2017-12-31T00:29:06.293Z
2017-12-31T00:29:06.293Z
Ava Chow
<p>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</p>

<p>see link to the owners original query
<a href="https://www.reddit.com/r/Bitcoin/comments/2t3vn0/i_cant_send_my_btc_a_triangle_apear_i_use_multibit/" rel="nofollow noreferrer">https://www.reddit.com/r/Bitcoin/comments/2t3vn0/i_cant_send_my_btc_a_triangle_apear_i_use_multibit/</a></p>

<p>also see link to a paper that lists that this is an invalid key
<a href="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" rel="nofollow noreferrer">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</a></p>

<p>see page 11</p>

CC BY-SA 3.0
2017-12-20T23:42:19.100Z
"00" is not a private key, so it certainly wasn't the key for that address.
Pieter Wuille
CC BY-SA 3.0
2017-12-21T06:40:25.410Z
@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
CC BY-SA 3.0
2017-12-21T07:06:50.867Z
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
CC BY-SA 3.0
2017-12-21T07:23:04.150Z
The point at infinity is not a valid public key.
Pieter Wuille
CC BY-SA 3.0
2017-12-22T07:05:44.633Z
@ Nate Eldredge . Oh ok, I see now it says "unconfirmed". How long does it stay in unconfirmed state before being returned or rejected?
MShepstone
CC BY-SA 3.0
2017-12-22T07:06:04.917Z
@MShepstone It can stay unconfirmed forever. Who would reject it? We have no mechanism to agree on anything but confirmed transactions.
David Schwartz
<transactions><private-key><ecdsa>
Invalid public key was spent! How was this possible?
MShepstone
# Invalid public key was spent! How was this possible?

(Asked by: username_0 on 2017-12-20)

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

**Tags:** transactions, private-key, ecdsa

> **Comments:**
> **username_1**: "00" is not a private key, so it certainly wasn't the key for that address.  
> **username_2**: @username_1: 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).  
> **username_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)?  
> **username_1**: The point at infinity is not a valid public key.  
> **username_0**: @ username_2 username_2 . Oh ok, I see now it says "unconfirmed". How long does it stay in unconfirmed state before being returned or rejected?  
> **username_3**: @username_0 It can stay unconfirmed forever. Who would reject it? We have no mechanism to agree on anything but confirmed transactions.  

---

## 1 answers

### Answer by username_4 on 2017-12-31. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_5**: 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: https://blockchain.info/tx/ba8a7fb13a507a4987bfa267a6f12defc0d30216fdf6664cdc06cc4c8de71a84  

---

