<p>The author of wxBitcoin was most likely unaware of the ability to do this, there's other inefficiencies like the original use of uncompressed points and BER encoding for signatures which also would have been good to eliminate. </p>

CC BY-SA 3.0
2015-12-02T21:07:32.487Z
But why not to implement it now? Compressed addresses were also introduced later
Jan Moritz
CC BY-SA 3.0
2015-12-02T21:05:41.663Z
2015-12-02T21:16:24.050Z
2015-12-02T21:16:24.050Z
Claris
<p>Why doesn't Bitcoin use public key recovering from the signature in order to reduce the Blockchain size? This would save 32 bytes per transaction input.</p>

CC BY-SA 3.0
2015-12-04T20:49:36.957Z
Does it guarantee you'll extract precisely the same public key used to generate the signature? If not, then the hash check will fail.
David Schwartz
CC BY-SA 3.0
2015-12-04T21:07:34.897Z
No it won't. see http://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work There will be two possible public keys. In addition you don't know if you have to use the compressed or the uncompressed representation of the the pubkey. So 4 possibilities. However this could be easily solved by setting a 2 bit flag to the signature. Something I haven't specified but is very important is that the Bitcoin client is already using such a technique for message signatures
Jan Moritz
CC BY-SA 3.0
2015-12-04T21:13:17.527Z
Actually, other answers on that same page explain that it's not guaranteed that either of those two possible public keys are the right one.
David Schwartz
CC BY-SA 3.0
2015-12-04T21:47:40.637Z
Read the comments. If there is a failure (low probability and I believe it can not happen with secp256k1) the signer can still retry using another k seed.
By the way the given example is not secp256k1 as he used other a, b values ...
Jan Moritz
CC BY-SA 3.0
2015-12-04T22:03:45.297Z
I've calculated the probability that n≤(kG)x<p, it is about 1/1.39+42 :-D
Jan Moritz
CC BY-SA 3.0
2015-12-04T22:30:34.590Z
So you're saying there's a chance. :)
David Schwartz
CC BY-SA 3.0
2015-12-04T23:51:14.083Z
1.39+42 is as likely as winning successively six times the UK national lottery! But whatever I took a look and it appears that many libraries such as OpenSSL are already filtering out k/privkeys that have such edge case values. So if this can really happen or not depends on the the cryptographic library that is used.
Jan Moritz
<transactions><ecdsa>
Why isn't Bitcoin using public key extraction from signature to reduce the blockchain size?
Jan Moritz
# Why isn't Bitcoin using public key extraction from signature to reduce the blockchain size?

(Asked by: username_0 on 2015-12-02)

Why doesn't Bitcoin use public key recovering from the signature in order to reduce the Blockchain size? This would save 32 bytes per transaction input.

**Tags:** transactions, ecdsa

> **Comments:**
> **username_1**: Does it guarantee you'll extract precisely the same public key used to generate the signature? If not, then the hash check will fail.  
> **username_0**: No it won't. see http://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work There will be two possible public keys. In addition you don't know if you have to use the compressed or the uncompressed representation of the the pubkey. So 4 possibilities. However this could be easily solved by setting a 2 bit flag to the signature. Something I haven't specified but is very important is that the Bitcoin client is already using such a technique for message signatures  
> **username_1**: Actually, other answers on that same page explain that it's not guaranteed that either of those two possible public keys are the right one.  
> **username_0**: Read the comments. If there is a failure (low probability and I believe it can not happen with secp256k1) the signer can still retry using another k seed. By the way the given example is not secp256k1 as he used other a, b values ...  
> **username_0**: I've calculated the probability that n≤(kG)x<p, it is about 1/1.39+42 :-D  
> **username_1**: So you're saying there's a chance. :)  
> **username_0**: 1.39+42 is as likely as winning successively six times the UK national lottery! But whatever I took a look and it appears that many libraries such as OpenSSL are already filtering out k/privkeys that have such edge case values. So if this can really happen or not depends on the the cryptographic library that is used.  

---

## 1 answers

### Answer by username_2 on 2015-12-02. Score: 2 | Accepted answer

The author of wxBitcoin was most likely unaware of the ability to do this, there's other inefficiencies like the original use of uncompressed points and BER encoding for signatures which also would have been good to eliminate.

> **Comments:**
> **username_0**: But why not to implement it now? Compressed addresses were also introduced later  

---

