Why doesn't address contain a full scriptPubKey?

Question

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.

Answer 1

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 scriptPubKeys. 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.

Answer 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

Answer 3

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.

Answer 4

If you did as you propose then the 'address' would be less 'address' like, and more a combination of both 'address' type information and 'spending mechanism' type information, the latter being the locking script code.

'Address' means 'location' of some kind, whether it be Bitcoin address, memory address, IP address, or a person's home address. In Bitcoin this location is the source or destination of funds, and it is convenient to have a notion of 'address' in this manner, and it helps non-technical people to grasp the basic concept of Bitcoin I think.

When we started out with P2PK type outputs the 'address' just encapsulated the public key, which 'locates' the person (or group of persons or machine etc) with the unique corresponding private key.

Then with P2PKH came a level of indirection with a hash of the public key now being used, but again the 'address' thus formed was very 'location' like, and uniquely identified 'someone' (or some other entity which can hold funds).

However when it came to P2SH, 'spending mechanism' type information entered the 'address' because the address then contained a hash of the required locking script. It's yet another level of indirection - the 'location' of funds, ie public key hash, is now stored in that implied locking script. The address thus now includes both 'address' type information and 'spending mechanism' type information, as in your proposal. Thus you are right - a Bitcoin address can ALREADY include scripting type information that pertains to 'spending mechanism', as well as containing 'location' type information. Thus the 'orthogonality' of these two types of information has been lost to some extent with P2SH.

Furthermore some 'orthogonality' is lost by P2SH in that there is no longer the clear distinction of the scriptPubKey containing only locking script, and the scriptSig containing only unlocking script. The scriptSig now takes the form of the unlocking script FOLLOWED BY the serialized locking script. And 'spending mechanism' is changed to a 2 stage process consisting of first checking the locking script has the correct hash, then subsequently executing the unlocking script concatenated with the deserialized locking script.

BUT in the case of P2SH this is a worthwhile compromise because P2SH is a powerful mechanism of great convenience which allows anyone to easily send to such a 'location' which uses a complex locking script, using only a standard sized Bitcoin address starting with a '3' and to not have to include that long locking script in the transaction (which would increase the fee).

So P2SH bends the orthogonal angles down a bit somewhat - though for a worthwhile reason. In all designs there is trade-off and compromise - losing some desirable property in one sense may be worthwhile for a powerful benefit.

In your proposal the orthogonal angle is being bent down quite severely - 'addresses' which are encapsulations of 'location', and which are used not just within Bitcoin itself, but everywhere where Bitcoin transactions are taking place, now carry along with them this additional scripting code, which is the detail of 'spending mechanism' rather than 'location'.

This is not a water-tight logical argument - but to me it seems the more 'elegant solution' to keep Bitcoin addresses storing the smallest amount of 'location' information and let the transaction creators deal with the actual scripting code details.