<blockquote>
<ol>
<li>it is not mentioned anywhere what is the value of that byte when the full pubK is used.</li>
</ol>
</blockquote>
<p>There is none. The WIF format for uncompressed private keys is just base58check encoding of version byte + 32-byte private key. For compressed private keys (as in: the corresponding public key is to be in compressed format) the WIF format is base58check encoding of version byte + 32-byte private key + 0x01.</p>
<blockquote>
<ol start="2">
<li>ultimately a private key is just a 256-bit number, there should be a unique way to derive an address from there.</li>
</ol>
</blockquote>
<p>Cryptographically speaking, yes, a private key is just a 256-bit number. But from Bitcoin's perspective, because the encoding of the public key matters, private-keys-whose-pubkey-is-compressed vs. private-keys-whose-pubkey-is-uncompressed are distinct keys.</p>
<blockquote>
<p>Are there actually two addresses for each private key in the bitcoin-core implementation?</p>
</blockquote>
<p>Specifically for P2PKH addresses, if you think of private keys as just the 256-bit discrete logarithm, yes. If you also include P2WPKH, P2SH-P2WPKH, P2TR addresses there are even more.</p>
<p>But as said, it's easier to think of it being two separate private keys, and then each has exactly 1 corresponding public key, and those on their turn have exactly one corresponding P2PKH address.</p>
<blockquote>
<p>Isn't there like a standard way of getting the address?</p>
</blockquote>
<p>It's hard to call anything standard as all of this predates the introduction of the BIP standardization process in which protocol changes and wallet standards are specified (compressed public keys were introduced in 2011).</p>
<p>But if we're talking about best practices, by all means, just use compressed public keys. There is no point wasting an additional 32 bytes on chain just because historically Bitcoin's creator likely just didn't know about compressed keys.</p>
<p>Or even better, use P2WPKH or P2TR for single-key addresses. They're even cheaper to spend.</p>

CC BY-SA 4.0
2023-02-18T19:59:45.577Z
2023-02-18T22:35:51.750Z
2023-02-18T22:35:51.750Z
Pieter Wuille
<p>I was implementing a small application that computes the bitcoin address starting from a private key (256-bit number). I am surprised about the lack of a single trustworthy reference to this, unlike the case of the BIPs.</p>
<p>The book of Antonopoulos and the <a href="https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses" rel="nofollow noreferrer">bitcoin wiki</a> indicate that the public key (pubK) must go through sha256 and ripemd160 hashes before base58check encoding that results in the final bitcoin address; there are also details about the version byte. But the pubK could be serialized in at least two forms, either the full 65-bytes <code>0x04&lt;xcoord&gt;&lt;ycoord&gt;</code> or the compressed 33-bytes <code>0x02/0x03 &lt;xcoord&gt;</code> representation. Both lead to different bitcoin addresses. The wiki explains step by step how to obtain an address from the compressed pubK, but the image in the page shows a diagram that uses the full pubK representation instead. The <a href="http://gobittest.appspot.com/" rel="nofollow noreferrer">http://gobittest.appspot.com/</a> website, referenced in the bitcoin wiki for testing the WIF format, computes the addresses using the full pubK.</p>
<p>Alright, I know that the private key WIF serialization format has a byte to indicate whether the pubK addresses are computed using the the compressed or full representation (see <a href="https://en.bitcoin.it/wiki/Wallet_import_format" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Wallet_import_format</a>).</p>
<blockquote>
<p>Also add a 0x01 byte at the end if the private key will correspond to a compressed public key.</p>
</blockquote>
<p>However,</p>
<ol>
<li>it is not mentioned anywhere what is the value of that byte when the full pubK is used.</li>
<li>ultimately a private key is just a 256-bit number, there should be a unique way to derive an address from there.</li>
</ol>
<p>Are there actually two addresses for each private key in the bitcoin-core implementation? Isn't there like a standard way of getting the address?</p>

CC BY-SA 4.0
2023-02-19T02:52:37.703Z
The representation of the bytes for the full 65 or compressed 33 bytes does change the public key but that cannot change the owners ability to sign for said public key. When you sign for the p2pkh transaction you provide this public key and therefore if you used the 65 byte one you would have to provide that and if you used the 33 byte version you would provide that. Saving 1/2 the byte size is probably the logical choice.
Poseidon
CC BY-SA 4.0
2023-02-19T02:55:06.327Z
I do not know however if there is a restriction on which one you can use because of how the opcodes behave, I would imagine not but it would be interesting to know if so.
Poseidon
<p2pkh>
Is there a standard P2PKH?
Lepus Cyberneticus
# Is there a standard P2PKH?

(Asked by: username_0 on 2023-02-18)

I was implementing a small application that computes the bitcoin address starting from a private key (256-bit number). I am surprised about the lack of a single trustworthy reference to this, unlike the case of the BIPs.

The book of Antonopoulos and the [bitcoin wiki](https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses) indicate that the public key (pubK) must go through sha256 and ripemd160 hashes before base58check encoding that results in the final bitcoin address; there are also details about the version byte. But the pubK could be serialized in at least two forms, either the full 65-bytes `0x04<xcoord><ycoord>` or the compressed 33-bytes `0x02/0x03 <xcoord>` representation. Both lead to different bitcoin addresses. The wiki explains step by step how to obtain an address from the compressed pubK, but the image in the page shows a diagram that uses the full pubK representation instead. The <http://gobittest.appspot.com/> website, referenced in the bitcoin wiki for testing the WIF format, computes the addresses using the full pubK.

Alright, I know that the private key WIF serialization format has a byte to indicate whether the pubK addresses are computed using the the compressed or full representation (see <https://en.bitcoin.it/wiki/Wallet_import_format>).

> Also add a 0x01 byte at the end if the private key will correspond to a compressed public key.

However,

1. it is not mentioned anywhere what is the value of that byte when the full pubK is used.
2. ultimately a private key is just a 256-bit number, there should be a unique way to derive an address from there.

Are there actually two addresses for each private key in the bitcoin-core implementation? Isn't there like a standard way of getting the address?

**Tags:** p2pkh

> **Comments:**
> **username_1**: The representation of the bytes for the full 65 or compressed 33 bytes does change the public key but that cannot change the owners ability to sign for said public key. When you sign for the p2pkh transaction you provide this public key and therefore if you used the 65 byte one you would have to provide that and if you used the 33 byte version you would provide that. Saving 1/2 the byte size is probably the logical choice.  
> **username_1**: I do not know however if there is a restriction on which one you can use because of how the opcodes behave, I would imagine not but it would be interesting to know if so.  

---

## 1 answers

### Answer by username_2 on 2023-02-18. Score: 4 | Accepted answer

> 1. it is not mentioned anywhere what is the value of that byte when the full pubK is used.

There is none. The WIF format for uncompressed private keys is just base58check encoding of version byte + 32-byte private key. For compressed private keys (as in: the corresponding public key is to be in compressed format) the WIF format is base58check encoding of version byte + 32-byte private key + 0x01.

> 2. ultimately a private key is just a 256-bit number, there should be a unique way to derive an address from there.

Cryptographically speaking, yes, a private key is just a 256-bit number. But from Bitcoin's perspective, because the encoding of the public key matters, private-keys-whose-pubkey-is-compressed vs. private-keys-whose-pubkey-is-uncompressed are distinct keys.

> Are there actually two addresses for each private key in the bitcoin-core implementation?

Specifically for P2PKH addresses, if you think of private keys as just the 256-bit discrete logarithm, yes. If you also include P2WPKH, P2SH-P2WPKH, P2TR addresses there are even more.

But as said, it's easier to think of it being two separate private keys, and then each has exactly 1 corresponding public key, and those on their turn have exactly one corresponding P2PKH address.

> Isn't there like a standard way of getting the address?

It's hard to call anything standard as all of this predates the introduction of the BIP standardization process in which protocol changes and wallet standards are specified (compressed public keys were introduced in 2011).

But if we're talking about best practices, by all means, just use compressed public keys. There is no point wasting an additional 32 bytes on chain just because historically Bitcoin's creator likely just didn't know about compressed keys.

Or even better, use P2WPKH or P2TR for single-key addresses. They're even cheaper to spend.


---

