<p>Scripts can be used to do a lot more thing than just pubkeys and signatures. There is an entire Bitcoin script language that can be used to specify things like multisigs, hashlocks, timelocks, conditionals, etc. It's pretty extensive, just hard to grasp and reason about. Such scripts do not map to addresses (before P2SH) so without having scripts in outputs, you would be locked into using only single pubkeys and signatures.</p>

CC BY-SA 4.0
2020-05-13T01:49:52.403Z
2020-05-13T01:49:52.403Z
Ava Chow
<p>First of all, Script is a stacking programming language in which Bitcoin works. Script is pretty basic and limited for security reasons. For this same reason, Script is not Turing complete. </p>

<blockquote>
  <p>Why does the bitcoin protocol opt for the use of this script-derivative in the transaction instead of just using the output address plainly?</p>
</blockquote>

<p>This is because locking bitcoins up with a script (also known as a smart contract) allows a wide variety of conditions in which specific Bitcoins would be spendable (multi-signature, a date in the future, a simple mathematical puzzle, etc). </p>

<p>There are some standard transactions in Bitcoin:</p>

<p><strong>P2PKH</strong> (Pay to Public Key Hash)<br>
<strong>P2SH</strong> (Pay to Script Hash)<br>
<strong>P2WPKH</strong> (Pay to Witness Public Key Hash)<br>
<strong>P2SH_P2WPKH</strong> (This is done to make P2WPKH backward compatible.)<br>
<strong>P2WSH</strong> (Pay to Witness Script Hash)<br>
<strong>P2SH_P2WSH</strong> (This is done to make P2WSH backward compatible.)<br></p>

<p>The script allows to tell the network how those bitcoins can be spent.</p>

<p>So, in the case of a <em>P2PKH</em> transaction, you are locking the Bitcoins to a certain public key which is represented by the address. The address is the base58 representation of the hash of the public key, and only the person who possesses the <em>private</em> key of that public key can spend those Bitcoins.</p>

<p>However, what really exploits the potential of the Script language in Bitcoin, is the standard <em>P2SH</em>. Here, you are locking the funds to a Script program (or smart contract) instead of a public key. So whoever can satisfy the problem in that program can unlock the funds and spend them. It is worth to note that there is a standard inside this standard. A P2SH can be standard or nonstandard depending on certain conditions. The major cases of use for P2SH transactions, however, are multi-signature transactions, and SegWit backward compatibility transactions (<em>P2SH_P2WPKH, P2SH-P2WSH</em>). </p>

<p><em>P2WPKH</em> and <em>P2WSH</em> are SegWit standards which aim to reduce the fees in transactions, but the principles from above remain (<em>P2PKH, P2SH</em>). </p>

CC BY-SA 4.0
2020-05-13T02:24:22.633Z
P2PKH addresses existed in Bitcoin v0.1 (along with pay-to-IP addresses, which would fetch a P2PK script from an IP to pay to).
Pieter Wuille
CC BY-SA 4.0
2020-05-13T02:33:58.043Z
There is also no privacy difference between P2PK and P2PKH (either is equally bad as an identifier). Revealing your public key is not a reason not to reuse P2PKH (reuse is bad for privacy regardless, but it revealing your public key is not an issue).
Pieter Wuille
CC BY-SA 4.0
2020-05-13T02:37:16.770Z
What is the point of the hash in p2pkh then?
Oscar Serna
CC BY-SA 4.0
2020-05-13T02:40:42.090Z
The original reason was likely simply to reduce the size of addresses. Satoshi didn't know about compressed pubkeys, and putting uncompressed pubkeys in there would take 95 base58 characters. A later reason for not reintroducing P2PK is reducing the size of the UTXO set (outputs go in the UTXO set, inputs don't; as hashes are smaller than public keys, this has a slight advantage in that regard).
Pieter Wuille
CC BY-SA 4.0
2020-05-13T02:41:27.907Z
Also the primary use of P2SH today is not multisig, but backward compatible segwit outputs
Pieter Wuille
CC BY-SA 4.0
2020-05-13T02:21:05.840Z
2020-05-13T03:04:05.797Z
2020-05-13T03:04:05.797Z
Oscar Serna
<p>I see transactions contain <code>script</code> for each output, but this "script" seems to be deterministically derived from the address associated with the output.</p>

<p>Why does the bitcoin protocol opt for the use of this script-derivative in the transaction instead of just using the output address plainly?</p>

<raw-transaction><transaction-verification><output>
Why is 'script' used in a transaction instead of the output address?
Albert Renshaw
# Why is 'script' used in a transaction instead of the output address?

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

I see transactions contain `script` for each output, but this "script" seems to be deterministically derived from the address associated with the output.

Why does the bitcoin protocol opt for the use of this script-derivative in the transaction instead of just using the output address plainly?

**Tags:** raw-transaction, transaction-verification, output


---

## 2 answers

### Answer by username_1 on 2020-05-13. Score: 2

Scripts can be used to do a lot more thing than just pubkeys and signatures. There is an entire Bitcoin script language that can be used to specify things like multisigs, hashlocks, timelocks, conditionals, etc. It's pretty extensive, just hard to grasp and reason about. Such scripts do not map to addresses (before P2SH) so without having scripts in outputs, you would be locked into using only single pubkeys and signatures.


---

### Answer by username_2 on 2020-05-13. Score: 1

First of all, Script is a stacking programming language in which Bitcoin works. Script is pretty basic and limited for security reasons. For this same reason, Script is not Turing complete.

> Why does the bitcoin protocol opt for the use of this script-derivative in the transaction instead of just using the output address plainly?

This is because locking bitcoins up with a script (also known as a smart contract) allows a wide variety of conditions in which specific Bitcoins would be spendable (multi-signature, a date in the future, a simple mathematical puzzle, etc).

There are some standard transactions in Bitcoin:

**P2PKH** (Pay to Public Key Hash)  
**P2SH** (Pay to Script Hash)  
**P2WPKH** (Pay to Witness Public Key Hash)  
**P2SH\_P2WPKH** (This is done to make P2WPKH backward compatible.)  
**P2WSH** (Pay to Witness Script Hash)  
**P2SH\_P2WSH** (This is done to make P2WSH backward compatible.)

The script allows to tell the network how those bitcoins can be spent.

So, in the case of a *P2PKH* transaction, you are locking the Bitcoins to a certain public key which is represented by the address. The address is the base58 representation of the hash of the public key, and only the person who possesses the *private* key of that public key can spend those Bitcoins.

However, what really exploits the potential of the Script language in Bitcoin, is the standard *P2SH*. Here, you are locking the funds to a Script program (or smart contract) instead of a public key. So whoever can satisfy the problem in that program can unlock the funds and spend them. It is worth to note that there is a standard inside this standard. A P2SH can be standard or nonstandard depending on certain conditions. The major cases of use for P2SH transactions, however, are multi-signature transactions, and SegWit backward compatibility transactions (*P2SH\_P2WPKH, P2SH-P2WSH*).

*P2WPKH* and *P2WSH* are SegWit standards which aim to reduce the fees in transactions, but the principles from above remain (*P2PKH, P2SH*).

> **Comments:**
> **username_3**: P2PKH addresses existed in Bitcoin v0.1 (along with pay-to-IP addresses, which would fetch a P2PK script from an IP to pay to).  
> **username_3**: There is also no privacy difference between P2PK and P2PKH (either is equally bad as an identifier). Revealing your public key is not a reason not to reuse P2PKH (reuse is bad for privacy regardless, but it revealing your public key is not an issue).  
> **username_2**: What is the point of the hash in p2pkh then?  
> **username_3**: The original reason was likely simply to reduce the size of addresses. Satoshi didn't know about compressed pubkeys, and putting uncompressed pubkeys in there would take 95 base58 characters. A later reason for not reintroducing P2PK is reducing the size of the UTXO set (outputs go in the UTXO set, inputs don't; as hashes are smaller than public keys, this has a slight advantage in that regard).  
> **username_3**: Also the primary use of P2SH today is not multisig, but backward compatible segwit outputs  

---

