To understand how Bitcoin transactions work and what are their types, we have to start from the beginning and explain what Bitcoin address, transaction, and scripts are and how they work?
Bitcoin address - is a string of alphanumerical characters that a user can distribute to anyone who wishes to send them money. Bitcoin addresses can come in different formats, with common ones being: Pay-to-PubKeyHash (P2PKH) and Pay-to-ScriptHash (P2SH). Although anyone can send bitcoins to any given Bitcoin address, those funds can only be spent if they fulfill certain requirements laid out by Bitcoin’s scripting system.
Script - is effectively a list of recorded instructions that accompany each executed transaction; the script governs how the next person wanting to spend the sent bitcoins can gain access to them.
Scripts accompanying outputs in transactions are called PubKey Scripts (they are also known as locking scripts), which are known in code as scriptPubKey. Recipients of the sent bitcoins will then generate a signature script (also known as an unlocking script), which is a collection of data parameters that are generated by the spender which is used to satisfy a PubKey Script. Signature scripts are called scriptSig in code.
Example: when Alice decides to initiate a transaction with Bob, the output contains bitcoins that are spendable on condition that the instructions laid out by the attached PubKey Script are satisfied. Once this transaction is broadcasted and added to the blockchain, the network will categorize the transaction as an Unspent Transaction Output (UTXO), and Bob’s wallet software will recognize it as being a spendable balance. When Bob decides to spend this UTXO he will create an input that includes a signature script that must satisfy the conditions that Alice placed in the previous output’s PubKey Script.
Bitcoin transaction - is a transfer of value between Bitcoin wallets that gets included in the blockchain. Bitcoin wallets keep a secret piece of data called a private key or seed, which is used to sign transactions, providing a mathematical proof that they have come from the owner of the wallet. The signature also prevents the transaction from being altered by anybody once it has been issued. All transactions are broadcast to the network and usually begin to be confirmed within 10-20 minutes, through a process called mining. All transactions are visible in the blockchain and can be viewed with an explorer. A blockchain explorer is a site where every transaction included within the blockchain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.
What are the Bitcoin Transaction types?
There a few standard Bitcoin transaction types at the time of writing. The developers behind Bitcoin have been continuously evolving the types of transactions to allow more functionality – the present list may change in the future. There are standard transactions which are accepted by the standard client – although some miners will accept the last type, which is a non-standard transaction but for a price.
Script > P2PK, P2PKH, P2MS, P2SH, P2WPKH, NULL DATA, NON-STANDARD
Standard types of transaction scripts: pay-to-public-key-hash (P2PKH), public-key (P2PK), multi-signature (P2MS) limited to 15 keys, pay-to-script-hash (P2SH), pay-to-witness-public-key-hash (P2WPKH) - This was a feature of Segwit which stands for Segregated Witness and data output Null Data (OP_RETURN), which are described in more detail in the following sections.
The last type is special and we call it a non-standard transaction.
Simplified explanation of transaction types for beginners.
P2PKH: "Pay To Public Key Hash" - This is how a big percentage of transactions are made. You are requiring the sender to supply a valid signature (from the private key) and public key. The transaction output script will use the signature and public key after checking the hash of the provided public key with previous output, and through some cryptographic functions will check if the signature is valid, if it was, then the funds will be spendable. This method conceals your public key in the form of a hash for extra security. If the spending condition is set to present a public key hash, then it is a P2PKH TX, and you have the std Op_Dup, Op_Hash160,... structure.
P2PK: "Pay To Public Key" - Unlike P2PKH that contained the hash of public key; this script contains the public key itself. Anyone using this method to send funds over the P2P network is showing people their public key in the transaction details. The spending condition only requires you to present your public key and signature. The public key would be recognized by your wallet (following the above mentioned coding scheme) as „type 1“ address.
P2SH: "Pay To Script Hash" - became a standard script in April 2012. The outputs of a transaction are just hash of scripts known as redeemscript that, if are executed with specific parameters, will result in a boolean of true or false. If a miner runs the output script with the supplied parameters and results in true, the money will be sent to your desired output. P2SH is used for multi-signature wallets making the output scripts logic that checks for multiple signatures before accepting the transaction. P2SH can also be used to allow anyone, or no one, to spend the funds. If the output script of a P2SH transaction is just 1 for true, then attempting to spend the output without supplying parameters will just result in 1 making the money spendable by anyone who tries. This also applies to scripts that return 0, making the output spendable by no one.
P2WPKH: "Pay To Witness Public Key Hash" - This was a feature of segwit which stands for Segregated Witness. Instead of using scriptSig parameters to check the transaction validity, there is a new part of the transaction called witness where the validity occurs. In 2015, Pieter Wuille introduced a new feature to bitcoin called Segregated Witness, also known by its abbreviated name, Segwit. Basically, Segregated Witness moves the proof of ownership from the scriptSig part of the transaction to a new part called the witness of the input.
P2MS: "MultiSignature" - (multisig) refers to requiring more than one key to authorize a Bitcoin transaction and was first applied to Bitcoin addresses in 2013. Generally used to divide up responsibility for possession of bitcoins. Standard transactions on the Bitcoin network could be called “single-signature transactions,” because transfers require only one signature — from the owner of the private key associated with the Bitcoin address. However, the Bitcoin network supports much more complicated transactions that require the signatures of multiple people before the funds can be transferred. These are often referred to as M-of-N transactions. The idea is that Bitcoins become “encumbered” by providing addresses of multiple parties, thus requiring cooperation of those parties in order to do anything with them. These parties can be people, institutions or programmed scripts. Became a standard script in January 2012.
NULL DATA: (OP_RETURN) - transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. Anyone can use a NULL DATA script to add some arbitrary data to a transaction, so you can find them scattered around the blockchain. We have to remember that not all miners accept transactions with null-data and not all nodes relay them. (OP_RETURN) outputsLook for empty outputs when browsing the blockchain, as NULL DATA scripts are almost always placed on empty outputs (because the outputs are made unspendable by the lock).
Here is a web page with a list of metadata recently embedded in the bitcoin blockchain using OP_RETURN outputs: http://coinsecrets.org/
Non-Standart - to include this type of transaction to the Bitcoin Blockchain, an agreement has to be reached with a miner: the non-standard transaction will be then included in the blockchain when the miner resolves the block. Depends on the hash rate from the miner it can be quite a while taking into consideration very high actual difficulty which is rising constantly from the start of Bitcoin. Of course, miner will take a proper fee for the non-standard transaction.
The addresses are generated from the hex pubkey a cool playground here: http://gobittest.appspot.com/Address
Extended explanation of Bitcoin transaction types for more advanced users.
Pay-to-PubKey - (P2PK) is a simpler form of a bitcoin payment than pay-to-public-key-hash. With this script form, the public key itself is stored in the locking script, rather than a public-key-hash as with P2PKH earlier, which is much shorter. P2PK is a script pattern that locks an output to a public key. Despite being the simplest script for locking bitcoins to someone's public key, P2PK is not used as much as the similar (yet more complex) P2PKH script. This is because the original Bitcoin Core miner would use P2PK for the block reward when constructing a candidate block. You'll most commonly find P2PK in coinbase transactions in the earlier blocks in the blockchain.
Pay-to-Public-Key-Hash - (P2PKH) The vast majority of transactions processed on the bitcoin network were P2PKH transactions. These contain a locking script that encumbers the output with a public key hash, more commonly known as a bitcoin address. Transactions that pay a bitcoin address contain P2PKH scripts. An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.
P2PKH is the default script used by wallets when you want to "send" someone bitcoins, so you can find it in most blocks in the blockchain. This script pattern is used to "send" someone bitcoins. It's the most common script used for locking an output to someone's public key. It is similar to P2PK, but the lock contains the hash of a public key instead (and not the public key itself). Every time you send bitcoins to an address that starts with a 1 you are creating a P2PKH locking script.
Pay-to-ScriptHash - (P2SH) was introduced in Bitcoin Improvement Proposal 16 (BIP 16) by Gavin Andresen, and it resulted in a new ‘standard’ transaction type for the Bitcoin scripting system. The purpose of P2SH, according to Andresen: ‘Is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer’.
In the example above, Bob generates a redeem script, hashes the redeem script to produce the redeem script hash and provides the hash to Alice. Alice can now then create a P2SH-style output containing Bob’s redeem script hash.
P2SH transaction type produces a number of advantages, such as:
The sender can fund any arbitrary redeem script without knowing what the spending conditions attached to the script are. This is an appropriate result because the sender of the transaction does not care how sent funds will be spent in the future. This is an issue for the recipient, who does care about conditions for further spending. The reduced transaction fee for the sender of the funds. Transaction fees are directly proportional to the size of a transaction, and a cryptographic hash of a fixed length allows the sender to send funds to any arbitrary redeem script without worrying about paying higher fees. It is the recipient’s responsibility to determine how large their spending transaction will be and how much it will cost, as they have to include the redeem script in order to spend funds. In other words, the burden of constructing the script and bearing the transaction fee of a long script is shifted to the recipient.
A common implementation of the P2SH function is the multi-signature address script. This script requires that a transaction possess more than one digital signature in order to prove ownership, and by extension spend funds. With P2SH transactions, the locking script is replaced with a redeem script hash. This hash derives from a redeem script, which functions similarly to the PubKey Script in that it too also contains conditions that must be satisfied before the output can be spent. When a transaction attempting to spend the UTXO is later initiated, the input must contain the PubKey Script (that contains the redeem script hash) and the unlocking script. In P2SH transactions, the script that houses the conditions for spending the output, which is the redeem script, is not presented in the locking script. Instead, only the hash (the redeem script hash) is included in the locking script, the redeem script itself is presented as part of the unlocking script when the output is spent. This has the effect of, as Andresen noted in BIP 16, of moving the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.
Benefits of pay-to-script-hash:
The pay-to-script-hash feature offers the following benefits compared to the direct use of complex scripts in locking outputs:
- Complex scripts are replaced by shorter fingerprints in the transaction output, making the transaction smaller.
- Scripts can be coded as an address, so the sender and the sender’s wallet don’t need complex engineering to implement P2SH.
- P2SH shifts the burden of constructing the script to the recipient, not the sender.
- P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set and therefore affect memory) to the input (only stored on the blockchain).
- P2SH shifts the burden in data storage for the long script from the present time (payment) to a future time (when it is spent).
- P2SH shifts the transaction fee cost of a long script from the sender to the recipient, who has to include the long redeem script to spend it.
- P2WSH similar to P2SH but the hash of the script is different and the redeemscript itself goes in witness.
- P2SH-P2WPKH nested SegWit (workarounds) where it is similar to P2WPKH but the whole thing is put inside of a redeem script and hashed.
- P2SH-P2WSH same as previous one but for P2WSH.
Multi-Signature - (P2MS) scripts set a condition where N public keys are recorded in the script and at least M of those must provide signatures to release the encumbrance. This is also known as an M-of-N scheme, where N is the total number of keys and M is the threshold of signatures required for validation. For example, a 2-of-3 multi-signature is one where three public keys are listed as potential signers and at least two of those must be used to create signatures for a valid transaction to spend the funds.
At this time, standard multi-signature scripts are limited to at most 15 listed public keys, meaning you can do anything from a 1-of-1 to a 15-of-15 multi-signature or any combination within that range. The limitation to 15 listed keys might be lifted by the time this book is published, so check the isStandard() function to see what is currently accepted by the network.
Pay-to-Witness-Public-Key-Hash - (P2WPKH) has the same semantics as P2PKH, except that the signature is not placed at the same location as before. Segregated Witness (SegWit) moves the proof of ownership from the scriptSig part of the transaction to a new part called the witness of the input. Before SegWit the transaction signature was used in the calculation of the transaction id. The signature contains the same information as a P2PKH spend but is located in the witness instead of the scriptSig. The scriptPubKey is modified from.
A native P2WPKH address has prefix bc1q for Bitcoin mainnet. It uses the same public key format as P2PKH, with a very important exception: the public key used in P2WPKH MUST be compressed, i.e. 33 bytes in size, and starting with a 0x02 or 0x03. The P2WPKH scriptPubKey is always 22 bytes. It starts with an OP_0, followed by a canonical push of the keyhash (i.e. 0x0014{20-byte keyhash}).
P2WPKH address should be used when only 1 public key is used to receive payment (like a standard P2PKH address). Because the SegWit signature generating algorithm (described in BIP143) covers the value of the input being spent, a transaction spending a SegWit utxo can be signed securely by an air-gapped light-weight wallet or by a hardware wallet. P2WPKH addresses are Bech32-encoded according to BIP143: they start with bc1q.. for Bitcoin mainnet and are somewhat longer than traditional P2PKH addresses.
NULL DATA - (OP RETURN) is a script opcode which can be used to write arbitrary data on the blockchain and also to mark a transaction output as invalid. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to burn bitcoins. In version 0.9 of the Bitcoin Core client, a compromise was reached with the introduction of the OP_RETURN operator.
OP_RETURN allows developers to add 40 bytes of nonpayment data to a transaction output. However, unlike the use of “fake” UTXO, the OP_RETURN operator creates an explicitly provably unspendable output, which does not need to be stored in the UTXO set. OP_RETURN outputs are recorded on the blockchain, so they consume disk space and contribute to the increase in the blockchain’s size, but they are not stored in the UTXO set and therefore do not bloat the UTXO memory pool and burden full nodes with the cost of more expensive RAM. Keep in mind that there is no “unlocking script” that corresponds to OP_RETURN that could possibly be used to “spend” an OP_RETURN output.
The whole point of OP_RETURN is that you can’t spend the money locked in that output, and therefore it does not need to be held in the UTXO set as potentially spendable—OP_RETURN is provably un-spendable. OP_RETURN is usually an output with a zero bitcoin amount because any bitcoin assigned to such an output is effectively lost forever. If an OP_RETURN is encountered by the script validation software, it results immediately in halting the execution of the validation script and marking the transaction as invalid. Thus, if you accidentally reference an OP_RETURN output as an input in a transaction, that transaction is invalid. A standard transaction (one that conforms to the isStandard() checks) can have only one OP_RETURN output. However, a single OP_RETURN output can be combined in a transaction with outputs of any other type. Stealth addresses offer another example of OP_RETURN in action. This scheme enables payments to be received without publicly revealing the receiver’s public key or address. Data needed to make this system work are encoded within a call to OP_RETURN. In essence, Bitcoin does double duty as a secure messaging protocol.
You can use NULL DATA for data storage, because the standard script allows for a data push at the end.
So if you want to add some arbitrary data to a transaction; include an extra (empty) output, and place a NULL DATA locking script on it:
Non Standart - to include this type of transaction to the Bitcoin Blockchain, an agreement has to be reached with a miner: the non-standard transaction will be then included in the blockchain when the miner resolves the block. Depends on the hash rate from the miner it can be quite a while taking into consideration very high actual difficulty which is rising constantly from the start of Bitcoin. Of course, miner will take a proper fee for the non-standard transaction.
Bitcoin Transaction Types:
Resources
This is a comprehensive explanation on how Bitcoin transactions work. I have benefited from it. Thank you for sharing this information.