<p>Most bitcoin nodes only allow a few specific types of scriptPubKey, including P2PK, P2PKH, OP_RETURN, P2SH, native witness and multisig. Those are the 'standard types', others are not related by default (initially for security reasons due to bugs).</p>

<p>So addresses with non-standard pubKeyScripts would be basically unusable on the network as it is, and there is no need to include the full pubKeyScript in that case - it's space saving and safer to just use the template.</p>

<p>Addresses have version byte at the start to differentiate between types.</p>

<p>It is possible to create scripts which do whatever you want, in a similar way to what you are asking, using P2SH. Still P2SH addresses have a specific scriptPubKey format which is always used, but then when spending you can provide the redeem script </p>

CC BY-SA 3.0
2017-12-05T22:46:48.327Z
Yeah, I'm aware of that. I understand it is shorter and faster. It just seems that a full scriptPubKey including Script code would allow really easy implementation on the wallet side, which wouldn't have to know what P2PK, P2PKH, P2SH etc. are. I'm not sure the benefits you mention are larger over this one
tsusanka
CC BY-SA 3.0
2017-12-05T22:48:35.523Z
@tsusanka it's not about benefits, read the first two paragraphs :)
meshcollider
CC BY-SA 3.0
2017-12-05T22:51:31.187Z
I'm trying to, sorry if I'm being stubborn :). Let's suppose the scriptPubKey is a full Script code. You can still easily check if it is one of the standard transactions and the restrictions you mention would remain.
tsusanka
CC BY-SA 3.0
2017-12-05T22:53:15.093Z
Then what is the point of allowing it? You can always give someone a scriptPubKey anyway, there is no reason you have to give them an address
meshcollider
CC BY-SA 3.0
2017-12-05T22:59:34.843Z
The use of standard address types also helps to move the cost of sending to that address from the sender to the receiver. If you tell the sender to send to some stupidly large scriptPubKey, the sender is going to be the person who has to pay the fee for that to work. However if you use P2SH and use the script as the redeemScript, the burden of paying the fee moves from the sender to the receiver; now if the receiver wants to spend the coins, he has to pay the fee.
Ava Chow
CC BY-SA 3.0
2017-12-06T11:29:43.653Z
@MeshCollider the address and the scriptPubKey would be the very same thing
tsusanka
CC BY-SA 3.0
2017-12-06T11:56:12.610Z
@tsusanka you are just playing pointlessly with terminology now... please start a chatroom if you want to continue this conversation, comments are not for extended discussion :)
meshcollider
CC BY-SA 3.0
2017-12-05T22:36:31.183Z
2017-12-05T22:36:31.183Z
meshcollider
<p>Is there maybe a mixture of two things in your assumption?</p>

<blockquote>
  <p>Why does an address contain only the PublicKeyHash ...</p>
</blockquote>

<p>Addresses do not contain hashes. Addresses are derived from the (hexadecimal) pubkeys, which are sha256&amp;ripemd160'ed, added with a network byte, and some checksumming, and then base58encoded. </p>

<p>The script you show us here for P2PKH is the spending condition. When a funding transaction is created, this condition is in the output, so that only the person, that can create the pubkeyhash is allowed to spend the funds. To create the pubkey hash, you need the hexadecimal pubkey, and sha256/ripemd it... </p>

<p>Now why is a combination of OpCodes and Hash not used as address? 
I give it a speculative try. I am asking myself, what is the gain? The wallet to surround the keyhash with 5 OpCodes (incl. length) is not much of an effort. The keyhash is anyhow calculated (fairly easy add/multiply with integers and no floating point arithmetics), to be used later on in base58encoding. All calculation costs are at the user's machine(s), not the bitcoin network machines. So not a big cost for the wallet machinery. </p>

<p>Limiting an address to one specific use case would require to have many address "types" in a wallet (a bunch for P2PK, P2PKH, P2SH, OP_Return... and what else). I think at this time you had just a bunch of keys in the wallet. And the wallet pre-generated addresses (no address re-usage), that needed to be properly back'ed up after every use. Adding different address types for limited use case would only complicate wallet handling?</p>

<p>Length of tx was already mentioned by MeshCollider. 
Astoundingly a P2PK is shorter with compressed keys, than P2PKH (but not as anonymous as a P2PKH). The lock script is only  OP_CHECKSIG. Here the address would be the pubkey + 1 OpCode.</p>

<p>I come to this conclusion: hen creatig a software to transfer values, I need targets (aka addresses) and logic. The targets would be "stable", and the logic gives me all the flexibility. It could be done linking the target to the logic, but can't see the immedeate benefit from it. </p>

CC BY-SA 3.0
2017-12-06T00:19:21.110Z
"Addresses do not contain hashes." ... "which are sha256&ripemd160'ed". You're very much contradicting yourself.
Pieter Wuille
CC BY-SA 3.0
2017-12-05T23:46:48.430Z
2017-12-05T23:46:48.430Z
pebwindkraft
<p>There are several reasons for this, some historical and some more recently:</p>

<ul>
<li>At first, addresses were probably not intended to cover everything Bitcoin Script could do. They were a fallback for the case where the recipient was not online (we're calling addresses still addresses because they were originally IP addresses you'd connect to to request a <code>scriptPubKey</code>). So at the time they were introduced, a focus on size was probably far more relevant than considerations about flexibility. Note that addresses have a 'version byte' (which was intended for upgrading the format, not for identifying altcoins).</li>
<li>Later, when P2SH was introduced the concern about flexibility went away entirely: P2SH permitted conveying <em>any</em> spendability concern in a constant-size address. Furthermore, it removed the concern of senders needing to create larger outputs. The fact that I am using a multisig wallet shouldn't mean you have to pay a higher fee when sending to me.</li>
<li>When SegWit was introduced, P2SH was no longer sufficient to encode any output, for reasons of efficiency and security. Despite the need for a new format anyway, we still chose not to propose something that could encode arbitrary <code>scriptPubKey</code>s. The reasoning given in BIP173: 

<ul>
<li><strong>Why not make an address format that is generic for all scriptPubKeys?</strong> That would lead to confusion about addresses for existing scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based addresses) are ever introduced, having a fully generic old address type available would permit reinterpreting the resulting scriptPubKeys using the old address format, with lost funds as a result if bitcoins are sent to them.</li>
</ul></li>
</ul>

CC BY-SA 3.0
2017-12-06T11:15:36.483Z
Thank you. So if we would hypothetically invent Bitcoin again, we would still probably not opt for a generic addresses that contain a full scriptPubKey because in the case of ECDH-based addresses (such as CryptoNote uses?) got introduced it would represent a security risk, because the older wallet might simply copy and paste instead of deriving a secret value. Is that about right?
tsusanka
CC BY-SA 3.0
2017-12-06T18:25:39.917Z
That last point is my own opinion, and I don't expect everyone agrees with its importance. However, given the flexibility of P2SH and other scripthash based outputs (second point) it doesn't matter all that much.
Pieter Wuille
CC BY-SA 3.0
2017-12-06T00:38:51.290Z
2017-12-06T00:38:51.290Z
Pieter Wuille
<p>This is a general question, but let's suppose a P2PKH transaction. P2PKH address starts with "1" and the sender incorporates it into the scriptPubKey as:</p>

<p><code>OP_DUP OP_HASH160 &lt;PublicKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG</code></p>

<p>Why does an address contain only the <code>&lt;PublicKeyHash&gt;</code> instead of the full scriptPubKey including the Script commands? At the current scenario the wallet software needs to recognize the address and assemble the scriptPubKey itself.</p>

<p>If the full Script code would be incorporated in the address, the wallet software would not have to understand it and would simply set the scriptPubKey equal to whatever the address contains.</p>

<p>This seems to me as very useful in terms of forward-compatibility for future types, where the wallet software doesn't have to be upgraded to understand some new forms of transaction.</p>

CC BY-SA 3.0
2017-12-05T13:29:46.923Z
I believe it  partly done due to security reasons? It is much easier to bruteforce something XY if you already have X, (which would be the case by already adding the public key to your adress by default). Instead of a hashed variable where you will only get the pubkey if a spent is made, rendering it useless ( bitcoins will be gone by the time you are able to bruteforce it). ( Note that it is currently ( even with the pubkey) practically impossible to bruteforce any adress, but this might not be the case in the future.) - Someone else might be able to give a more detailed answer.
Jan Janssen
CC BY-SA 3.0
2017-12-05T17:51:56.297Z
That is not what the question is asking (I misread it first time too). It does not ask why is hash there; it asks why is not the full scriptpubkey there, only the hash.
Karel Bílek
CC BY-SA 3.0
2017-12-05T17:54:39.407Z
I've modified the question a little bit to make it clearer.
tsusanka
<transactions><script><p2pkh>
Why doesn't address contain a full scriptPubKey?
tsusanka
# Why doesn't address contain a full scriptPubKey?

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

This is a general question, but let's suppose a P2PKH transaction. P2PKH address starts with "1" and the sender incorporates it into the scriptPubKey as:

`OP_DUP OP_HASH160 <PublicKeyHash> OP_EQUALVERIFY OP_CHECKSIG`

Why does an address contain only the `<PublicKeyHash>` instead of the full scriptPubKey including the Script commands? At the current scenario the wallet software needs to recognize the address and assemble the scriptPubKey itself.

If the full Script code would be incorporated in the address, the wallet software would not have to understand it and would simply set the scriptPubKey equal to whatever the address contains.

This seems to me as very useful in terms of forward-compatibility for future types, where the wallet software doesn't have to be upgraded to understand some new forms of transaction.

**Tags:** transactions, script, p2pkh

> **Comments:**
> **username_1**: I believe it  partly done due to security reasons? It is much easier to bruteforce something XY if you already have X, (which would be the case by already adding the public key to your adress by default). Instead of a hashed variable where you will only get the pubkey if a spent is made, rendering it useless ( bitcoins will be gone by the time you are able to bruteforce it). ( Note that it is currently ( even with the pubkey) practically impossible to bruteforce any adress, but this might not be the case in the future.) - Someone else might be able to give a more detailed answer.  
> **username_2**: That is not what the question is asking (I misread it first time too). It does not ask why is hash there; it asks why is not the full scriptpubkey there, only the hash.  
> **username_0**: I've modified the question a little bit to make it clearer.  

---

## 3 answers

### Answer by username_6 on 2017-12-06. Score: 5 | Accepted answer

There are several reasons for this, some historical and some more recently:

* At first, addresses were probably not intended to cover everything Bitcoin Script could do. They were a fallback for the case where the recipient was not online (we're calling addresses still addresses because they were originally IP addresses you'd connect to to request a `scriptPubKey`). So at the time they were introduced, a focus on size was probably far more relevant than considerations about flexibility. Note that addresses have a 'version byte' (which was intended for upgrading the format, not for identifying altcoins).
* Later, when P2SH was introduced the concern about flexibility went away entirely: P2SH permitted conveying *any* spendability concern in a constant-size address. Furthermore, it removed the concern of senders needing to create larger outputs. The fact that I am using a multisig wallet shouldn't mean you have to pay a higher fee when sending to me.
* When SegWit was introduced, P2SH was no longer sufficient to encode any output, for reasons of efficiency and security. Despite the need for a new format anyway, we still chose not to propose something that could encode arbitrary `scriptPubKey`s. The reasoning given in BIP173:
  + **Why not make an address format that is generic for all scriptPubKeys?** That would lead to confusion about addresses for existing scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based addresses) are ever introduced, having a fully generic old address type available would permit reinterpreting the resulting scriptPubKeys using the old address format, with lost funds as a result if bitcoins are sent to them.

> **Comments:**
> **username_0**: Thank you. So if we would hypothetically invent Bitcoin again, we would still probably not opt for a generic addresses that contain a full scriptPubKey because in the case of ECDH-based addresses (such as CryptoNote uses?) got introduced it would represent a security risk, because the older wallet might simply copy and paste instead of deriving a secret value. Is that about right?  
> **username_6**: That last point is my own opinion, and I don't expect everyone agrees with its importance. However, given the flexibility of P2SH and other scripthash based outputs (second point) it doesn't matter all that much.  

---

### Answer by username_3 on 2017-12-05. Score: 2

Most bitcoin nodes only allow a few specific types of scriptPubKey, including P2PK, P2PKH, OP\_RETURN, P2SH, native witness and multisig. Those are the 'standard types', others are not related by default (initially for security reasons due to bugs).

So addresses with non-standard pubKeyScripts would be basically unusable on the network as it is, and there is no need to include the full pubKeyScript in that case - it's space saving and safer to just use the template.

Addresses have version byte at the start to differentiate between types.

It is possible to create scripts which do whatever you want, in a similar way to what you are asking, using P2SH. Still P2SH addresses have a specific scriptPubKey format which is always used, but then when spending you can provide the redeem script

> **Comments:**
> **username_0**: Yeah, I'm aware of that. I understand it is shorter and faster. It just seems that a full scriptPubKey including Script code would allow really easy implementation on the wallet side, which wouldn't have to know what P2PK, P2PKH, P2SH etc. are. I'm not sure the benefits you mention are larger over this one  
> **username_3**: @username_0 it's not about benefits, read the first two paragraphs :)  
> **username_0**: I'm trying to, sorry if I'm being stubborn :). Let's suppose the scriptPubKey is a full Script code. You can still easily check if it is one of the standard transactions and the restrictions you mention would remain.  
> **username_3**: Then what is the point of allowing it? You can always give someone a scriptPubKey anyway, there is no reason you have to give them an address  
> **username_4**: The use of standard address types also helps to move the cost of sending to that address from the sender to the receiver. If you tell the sender to send to some stupidly large scriptPubKey, the sender is going to be the person who has to pay the fee for that to work. However if you use P2SH and use the script as the redeemScript, the burden of paying the fee moves from the sender to the receiver; now if the receiver wants to spend the coins, he has to pay the fee.  
> **username_0**: @MeshCollider the address and the scriptPubKey would be the very same thing  
> **username_3**: @username_0 you are just playing pointlessly with terminology now... please start a chatroom if you want to continue this conversation, comments are not for extended discussion :)  

---

### Answer by username_5 on 2017-12-05. Score: 0

Is there maybe a mixture of two things in your assumption?

> Why does an address contain only the PublicKeyHash ...

Addresses do not contain hashes. Addresses are derived from the (hexadecimal) pubkeys, which are sha256&ripemd160'ed, added with a network byte, and some checksumming, and then base58encoded.

The script you show us here for P2PKH is the spending condition. When a funding transaction is created, this condition is in the output, so that only the person, that can create the pubkeyhash is allowed to spend the funds. To create the pubkey hash, you need the hexadecimal pubkey, and sha256/ripemd it...

Now why is a combination of OpCodes and Hash not used as address?
I give it a speculative try. I am asking myself, what is the gain? The wallet to surround the keyhash with 5 OpCodes (incl. length) is not much of an effort. The keyhash is anyhow calculated (fairly easy add/multiply with integers and no floating point arithmetics), to be used later on in base58encoding. All calculation costs are at the user's machine(s), not the bitcoin network machines. So not a big cost for the wallet machinery.

Limiting an address to one specific use case would require to have many address "types" in a wallet (a bunch for P2PK, P2PKH, P2SH, OP\_Return... and what else). I think at this time you had just a bunch of keys in the wallet. And the wallet pre-generated addresses (no address re-usage), that needed to be properly back'ed up after every use. Adding different address types for limited use case would only complicate wallet handling?

Length of tx was already mentioned by MeshCollider.
Astoundingly a P2PK is shorter with compressed keys, than P2PKH (but not as anonymous as a P2PKH). The lock script is only OP\_CHECKSIG. Here the address would be the pubkey + 1 OpCode.

I come to this conclusion: hen creatig a software to transfer values, I need targets (aka addresses) and logic. The targets would be "stable", and the logic gives me all the flexibility. It could be done linking the target to the logic, but can't see the immedeate benefit from it.

> **Comments:**
> **username_6**: "Addresses do not contain hashes." ... "which are sha256&ripemd160'ed". You're very much contradicting yourself.  

---

