3

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.

  • 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. – Rutger Versteegden Dec 5 '17 at 13:29
  • 1
    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 Dec 5 '17 at 17:51
  • I've modified the question a little bit to make it clearer. – tsusanka Dec 5 '17 at 17:54
3

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.
  • 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 Dec 6 '17 at 11:15
  • 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 Dec 6 '17 at 18:25
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

  • 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 Dec 5 '17 at 22:46
  • @tsusanka it's not about benefits, read the first two paragraphs :) – MeshCollider Dec 5 '17 at 22:48
  • 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 Dec 5 '17 at 22:51
  • 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 Dec 5 '17 at 22:53
  • 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. – Andrew Chow Dec 5 '17 at 22:59
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.

  • 2
    "Addresses do not contain hashes." ... "which are sha256&ripemd160'ed". You're very much contradicting yourself. – Pieter Wuille Dec 6 '17 at 0:19
0

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 just my rumination on the matter - not a water-tight logical argument - to me it seems 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.

However your question is a good one because it gets people thinking further about the details of how Bitcoin works, and increases our understanding because of that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.