[GUIDE] List of scripts and which one is used in each address prefix.

[NotATether]

List of script types

You are most likely aware of the different address prefixes bitcoin can take on, ones beginning with "1", "3", and "bc1", but did you know under each of these are different scripts responsible for locking and unlocking outputs in those addresses? In this topic I hope to help you understand the four different script types, P2PKH, P2SH, P2WSH and P2WPKH and which ones are used for each address.

Scriptsig, Scriptpub, and redeem scripts
Credits to pooya87 for some of the information here.

But before I cover the script types I want to explain how scripts move around bitcoins. For each transaction, there is a script that unlocks the outputs of previous transactions which we call the signature script or scriptsig, and there is also another script that locks the inputs of the current transaction, called public script or scriptpub. So again, scriptsigs unlock outputs, and scriptpubs lock inputs. Some types of scriptpubs have the hash of a redeem script inside them and that redeem script is responsible for locking the coins in the inputs, hence the name redeem script (this script locks inputs, for which a signature is required to redeem them). Inside code you will see scriptpub and scriptsig referred to as scriptPubKey and scriptSig.

Originally in this thread I referred to them as locking and unlocking scripts, but now that this section is here I think it's better I refer them by their actual names

P2PKH - Pay to Public Key Hash
This has been around since Bitcoin's beginnings. It is used in addresses beginning with "1", legacy addresses. The scriptpub for P2PKH is

Code:

OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG

The scriptsig for this is simply the transaction signature and then the public key of the address.

Code:

<signature> <public key>

What the opcodes do
Good question. It's always handy to know how your transactions work. You can skip this if you're new or don't want to learn the opcodes.

- OP_DUP duplicates the public key.
- OP_HASH160 hashes the duplicated public key with SHA256 then RIPEMD160.
- OP_EQUALVERIFY compares the result of OP_HASH160 and the public key hash given before the opcode. If they aren't equal, the transaction is marked as invalid.
- OP_CHECKSIG generates a hash from the inputs, outputs and script and compares it to the signature and public key in the unlocking script for verification. If it doesn't verify then the transaction is invalid.

P2PK - Pay to Public Key
The oldest, and also an uncommon, bitcoin script. It was used to make transactions with the public keys themselves instead of their hashes. Because the public keys are not hashed, transactions done with this script have no associated address, only a public key. This resulted in transactions being unnecessarily large. P2PK scriptpubs and scriptsigs look like this:

Code:

<public key> OP_CHECKSIG

Code:

<signature>

It only verifies the signature, without doing any hashing.

P2SH - Pay to Script Hash

This script was introduced in 2012 with BIP16. It enables you to create locking scripts that can be unlocked with a condition other than signature verification. OP_CHECKSIG is not used in P2SH addresses. P2SH scripts are used in bitcoin addresses beginning with a "3".

Here are the scriptpubs and scriptsigs for P2SH:

Code:

OP_HASH160 <redeem script hash> OP_EQUAL

Code:

<signature> <redeem script signature>

This script doesn't look interesting by itself and that's because all of the locking is done inside the redeem script. The redeem script can have anything inside.

Custom scripts are beyond the scope of this guide so let's look at one of the standard scripts that can be wrapped inside a P2SH script.

P2MS - Pay to Multisig

This script makes an M-of-N transaction, that has N public keys of with M of those must sign the transaction to be valid. It was introduced in 2011 with BIP11. This script can be used by itself but it's usually wrapped inside P2SH scripts.

These are its scriptpubs and scriptsigs. They correspond to the redeem script hash and signature I mentioned above, though by no means is the redeem script required to be P2MS, it can be any custom script.

Suppose you want a 1-of-2 multisig with 2 public keys that 1 of them is required to sign. Then M=1 and N=2.

Code:

OP_1 <two public keys> OP_2 OP_CHECKMULTISIG

Code:

OP_0 <one signature>

The first opcode in the scriptpub is M, the second opcode is for N, and OP_CHECKMULTISIG attempts to verify each signature, one at a time, with the N public keys and the script hash. If one signature doesn't verify against the public key the next public key is tried. As soon as a signature is verified it begins verifying the next one. In the scriptsig there should be M signatures.

In the scriptsig there is OP_0. We need it because OP_CHECKMULTISIG has a bug that makes it pop an extra value from the stack, so there needs to be a dummy value at the top of the scriptsig so that it gets popped.

P2WSH - Pay to Witness Script Hash

This script type is almost similar to P2SH. The only difference between the two is that P2WSH transactions use SegWit, which stands for Segregated Witness. The reason it's named that is because Segwit removes the scriptsig from the transaction and stores the hash of the redeem script in the scriptpub area instead of storing the entire redeem script. This makes the scriptpub more compact. You can see an example of a P2WSH having no scriptsig at Bitcoin Programming's azure page.

So the scriptpub changes from

Code:

OP_HASH160 <public key> OP_EQUAL

To:

Code:

0 <redeem script hash>

And there is no scriptsig transmitted. 0 refers to the witness version, which is at version 0 right now so that is what should be the first value.

Nodes that don't have Segwit support interpret the above script to be two stack pushes. This has the side effect of them automatically reading them as valid transactions without checking any signatures. You might think this is an issue, because they are interpreting any transaction as valid. Actually it isn't an issue because only the newer nodes can create P2WSH transactions and they validate them in the usual way.

Addresses that use P2WSH have a "3" in front of them.

P2WPKH - Pay to Witness Public Key Hash

Just like P2SH/P2WSH, this script is similar to P2PKH except it uses Segwit as well. It also removes the scriptsig and condenses the scriptpub to a number and a redeem script hash, so scriptpubs for P2WPKH now change from

Code:

OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG

To

Code:

0 <redeem script hash>

Notice this script looks the same as the one for P2WSH, the same notices I mentioned for P2WSH also apply to P2WPKH scripts. Also, only Segwit nodes can make P2WPKH transactions.

Addresses that use P2WPKH have "bc1" in front of them. It is different from P2WSH because bc1 addresses use the bech32 address format which in turn uses P2WPKH scripts.


Material was gathered, and not quoted, from the following sources, in order of their use in this thread:

https://bitcoincore.org/en/segwit_wallet_dev/
https://learnmeabitcoin.com/technical/p2pkh
https://learnmeabitcoin.com/technical/p2pk
https://learnmeabitcoin.com/technical/p2ms
https://learnmeabitcoin.com/technical/p2sh
https://programmingblockchain.gitbook.io/programmingblockchain/other_types_of_ownership/p2wsh_pay_to_witness_script_hash
https://programmingblockchain.gitbook.io/programmingblockchain/other_types_of_ownership/p2wpkh_pay_to_witness_public_key_hash


Changelog:
2020-08-28: Fix incorrect statements and add section about sigscript and scriptpub

[1714928035]

1714928035

[1714928035]

1714928035

[1714928035]

1714928035

[hd49728]

How Bitcoin transactions work and what are their types?

There are some more information, discussion and documents in that thread and you can use them to improve your content.

[pooya87]

P2PK - Pay to Public Key
The oldest (so obviously beginning with "1"), and also an obsolete, bitcoin script.

there is no address for P2PK scripts  and they are not exactly obsolete, they are just not common anymore otherwise it is standard and practically do the same thing without hashing as P2PKH.

Note: to wrap a script inside another script, you put the signature of the inside script after the signature of the outside one, then use the hash of the inside script somewhere in the outer locking script.

i can not for the life of me understand what you are trying to say here.

we have a redeem script, a signature script (scriptsig) and a pubkey script (scriptpub).
the redeem script is the script you use to "lock" the coins up and only reveal its hash which would be placed in the pubkey script of the transaction output.
while spending that redeem script goes into the signature script as a data being pushed to the stack since signature scripts spending a P2SH output must be push-only. then there are optional other data pushes (like signatures in a multi sig scheme) that should be placed before redeem script inside signature script.

P2WPKH - Pay to Witness Private Key Hash

it is hash of "pubkey" not private key.

[NotATether]

Thanks guys for the links and corrections, I really appreciate it. I have fixed the guide correcting the information about P2PK and P2WPKSH and I also added another section about the workings of scriptpub and scriptsig. I admit it took me a while to register in my brain what these terms represent but now that I know, it's simpler to just call scripts by the names scriptpub and scriptsig than locking and unlocking scripts.

I think everything should be correct by now, if not let me know and I'll attend to it.

we have a redeem script, a signature script (scriptsig) and a pubkey script (scriptpub).
the redeem script is the script you use to "lock" the coins up and only reveal its hash which would be placed in the pubkey script of the transaction output.
while spending that redeem script goes into the signature script as a data being pushed to the stack since signature scripts spending a P2SH output must be push-only. then there are optional other data pushes (like signatures in a multi sig scheme) that should be placed before redeem script inside signature script.

Originally I thought that since there is a concept of redeem scripts I thought that we can somehow nest arbitrary levels of scripts in each other, looks like I was wrong.

[pooya87]

~
Originally I thought that since there is a concept of redeem scripts I thought that we can somehow nest arbitrary levels of scripts in each other, looks like I was wrong.

in a way we are doing that but it is not exactly any arbitrary script in any other script. there are certain restrictions that apply. for example you can have any arbitrary redeem script but your signature script has to be push only and the redeem script is pushed as simple bytes.
for example if redeem script is OP_DUP then it is pushed as bytes like this 0x0176 (meaning push one byte=0x76 to stack) then then interpreter knows that the top stack element (which is 0x76) has to be an arbitrary script so it evaluates it as such and comes up with OP_DUP then runs that.