A Bitcoin transaction is an attempt at changing the ownership of some number of Bitcoins. The blockchain is a record of all "successful" transactions to date. One of the great features of Bitcoin is the flexibility it allows when expressing this change of ownership. One might reasonably assume that a transaction should contain a simple "pay to" field that holds the address of the recipient. Indeed, there is a field called scriptPubKey which fulfils this role. Each transaction has one or more scriptPubKeys allowing the Bitcoins to be split between multiple recipients. However, instead of storing simple addressees, each scriptPubKey expresses the conditions under which the recipient(s) can change their ownership of the corresponding Bitcoins in the future.
In the simplest case, the scriptPubKey includes the Bitcoin address of the recipient and requires a signature that only the recipient can produce in order to un-encumber the Bitcoins and use them in a future transaction. This allows transactions like "Alice pays Bob 1.5 Bitcoins". Alice creates a transaction that relinquishes ownership of 1.5 Bitcoins and attaches an encumbrance that only Bob can satisfy in the future.
But there are many more cases. Bitcoin uses a scripting language to specify (and satisfy) the encumbrances, thereby allowing a whole host of transaction types. Although many transaction types can be represented in the scripting language, only a limited number of standard transaction types are actually accepted by the network and the miners. These are specified on the Bitcoin Wiki, in the Bitcoin Improvement Proposals (BIPs), and, authoritatively, in the logic of the Bitcoin clients and mining software. The set of standard transactions types has and will continue to change over time.
Interestingly, we can use the blockchain to derive a comprehensive list of transaction types that were accepted in the past. This list includes non-standard transaction types that were accepted by the network at one time but would not be accepted by the network today. The table below lists the transaction types by the number of times they occurred in the blockchain up to and including block 290,000. We strip the data from each script. For example, the OP_HASH160 OP_DATA_20 OP_EQUAL transaction type expects 20 bytes of data to follow the OP_DATA_20 opcode. We also omit the transaction types that occur less than ten times. These include transaction types arising from vulnerabilities and other oddities.
The Most Popular Transaction Types in the Blockchain to Date
|Form of scriptPubKey||# Occurrences|
|1. OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG||86,380,556|
|2. OP_DATA_65 OP_CHECKSIG||886,544|
|3. OP_HASH160 OP_DATA_20 OP_EQUAL||19,451|
|4. OP_DATA_33 OP_CHECKSIG||17,756|
|5. OP_1 OP_DATA_65 OP_DATA_65 OP_DATA_65 OP_3 OP_CHECK_MULTISIG||16,705|
|6. OP_1 OP_DATA_33 OP_DATA_33 OP_2 OP_CHECK_MULTISIG||8,983|
|7. OP_1 OP_DATA_65 OP_DATA_33 OP_2 OP_CHECK_MULTISIG||1,197|
|9. OP_RETURN OP_DATA_40||473|
|11. OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH||182|
|12. OP_RETURN OP_DATA_32||175|
|13. OP_1 OP_DATA_65 OP_DATA_65 OP_2 OP_CHECK_MULTISIG||139|
|14. OP_1 OP_DATA_33 OP_DATA_33 OP_DATA_33 OP_3 OP_CHECK_MULTISIG||78|
|15. OP_RETURN OP_DATA_20||38|
|16. OP_1 OP_DATA_65 OP_DATA_33 OP_DATA_33 OP_3 OP_CHECK_MULTISIG||32|
|17. OP_RETURN OP_DATA_23||31|
|18. OP_2 OP_DATA_65 OP_DATA_65 OP_DATA_65 OP_3 OP_CHECK_MULTISIG||27|
|19. OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG||23|
|20. OP_2 OP_DATA_65 OP_DATA_65 OP_2 OP_CHECK_MULTISIG||22|
|22. OP_DATA_20 OP_NOP2 OP_DROP||15|
|23. OP_RETURN OP_DATA_38||12|
|24. OP_1 OP_DATA_33 OP_1 OP_CHECK_MULTISIG||11|
1. Pay to PubKey Hash
The "OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG" script is the standard way to send Bitcoins to a single address; it is known as a Pay to PubKey Hash transaction. Predictably, it is the most popular transaction type in the blockchain. It first occurred in transaction 6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516.
2, 4. Pay to PubKey
The "OP_DATA_65 OP_CHECKSIG" and "OP_DATA_33 OP_CHECKSIG" scripts are the standard way of assigning newly mined Bitcoins and transaction fees to an address; they are known as Pay to PubKey transactions. Their first occurrences in the blockchain are the 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098 and 0e842d4d66bc1c30a88f17eefa1e3436c6524aca39e9ad358edf380daf7a49ab transactions respectively.
3. Pay to Script Hash
The "OP_HASH160 OP_DATA_20 OP_EQUAL" script is a Pay to Script Hash (P2SH) transaction. It moves the responsibility for supplying the conditions to redeem a transaction from the creator of the transaction to the payee(s). The OP_DATA_20 opcode is followed by a 20 byte hash of the P2SH redeemScript which can be provided by the payee(s) in a future transaction. The transaction type is described in BIP 16. It first occurred in the blockchain in transaction 9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6. We can visualize the usage of this transaction type by plotting the number of transactions that it occurs in over time. The x-axis is the block number. The y-axis is the number of transactions that include at least one transaction output with a P2SH transaction type.
5, 6, 7, 13, 14, 16, 18, 19, 20, 24 Multi-Signature
Although P2SH transactions are now generally used for multi-signature transactions by specifying the multi-signature script in the P2SH redeemScript, they can also be specified directly in the scriptPubKey. The most popular m-of-n transaction type is 1-of-3 with uncompressed public-keys: "OP_1 OP_DATA_65 OP_DATA_65 OP_DATA_65 OP_3 OP_CHECK_MULTISIG". The first instance of this transaction type occurred in transaction 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17. This transaction was also used to upload a Python tool to the blockchain that can itself be used to upload and download data to and from the blockchain. "OP_1 OP_DATA_33 OP_DATA_33 OP_2 OP_CHECK_MULTISIG" is the 1-of-2 transaction type where the hashes of the public keys (or Bitcoin addresses) are stored in a compressed formatis. This is the next most popular form and it first occurred in transaction 274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857. "OP_1 OP_DATA_65 OP_DATA_33 OP_2 OP_CHECK_MULTISIG" is nearly identical but stores the first hash in a non-compressed format and the second hash in a compressed format. It first occurred in transaction 7a02df33eddfb9dbcc7988f980630297089454f13a8bd059ada4b7842e2d1615 and, as of block 290,000, remains unspent.
There are many other variations of the multi-signature transaction type that feature in the table above. You can inspect their first occurences in the blockchain in the transactions below:
- OP_1 OP_DATA_65 OP_DATA_65 OP_2 OP_CHECK_MULTISIG: 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1
- OP_1 OP_DATA_33 OP_DATA_33 OP_DATA_33 OP_3 OP_CHECK_MULTISIG: 0109e3f8d2d324b8d0c0fdd34d369ebcc69fbcc5a0cabe781f69867a0ba1dd74
- OP_1 OP_DATA_65 OP_DATA_33 OP_DATA_33 OP_3 OP_CHECK_MULTISIG: 14015bd586c0c7a28979ca294b114441f23bfc97be17cd6077b9e12e2709fec3
- OP_2 OP_DATA_65 OP_DATA_65 OP_DATA_65 OP_3 OP_CHECK_MULTISIG: 14237b92d26850730ffab1bfb138121e487ddde444734ef195eb7928102bc939
- OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG: 6d5088c138e2fbf4ea7a8c2cb1b57a76c4b0a5fab5f4c188696aad807a5ba6d8
- OP_2 OP_DATA_65 OP_DATA_65 OP_2 OP_CHECK_MULTISIG: 947539645c59e6ab0cda61826cbacb55ef97a8178f012f8c18abe504bf66d4ce
- OP_1 OP_DATA_33 OP_1 OP_CHECK_MULTISIG: b96af3b69b48a82c5eae3e44ebb6ef93f30d7764b1d5b40243e11b0d374ac1b7
The "OP_DATA_32" and "OP_DATA_36" transaction types are unusual. They comprise a single data opcode followed by data. They are non-standard transaction types. They can be observed in the outputs of transactions d65bb24f6289dad27f0f7e75e80e187d9b189a82dcf5a86fb1c6f8ff2b2c190f and 12075ceb94272b8bfbd698fc5528588dc997d64cf2940347eae7d8a136c3fd96. Both outputs are unspendable.
9, 12, 15, 17, 21, 23 Null Data
The null data scripts begin with the OP_RETURN opcode. They allow the creator of the transaction to include some arbitrary data in the blockchain in exchange for paying a transaction fee. The output is unspendable. The earliest examples of the most popular forms of these types of scripts are as follows:
- OP_RETURN OP_DATA_40: c4397247190d3f8d88b587990d1c374d6b0ae25ebf9ced81ea8b69665b43d7de
- OP_RETURN OP_DATA_32: 139c004f477101c468767983536caaeef568613fab9c2ed9237521f5ff530afd
- OP_RETURN OP_DATA_20: 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc
- OP_RETURN OP_DATA_23: 46377ec1dcbddfa13e7756756873888b92d23b9ff78414258257ba30c0ac383b
- OP_RETURN: eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29
- OP_RETURN OP_DATA_38: 63e75e43de21b73d7eb0220ce44dcfa5fc7717a8decebb254b31ef13047fa518
11. A P2Pool Bug
The "OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH" transaction type was created by a bug in the P2Pool software. The script is the ASCII encoding of the word "script". The outputs are unspendable. It first occurred in the blockchain in transaction fa735229f650a8a12bcf2f14cca5a8593513f0aabc52f8687ee148c9f9ab6665 and has occurred 182 times up to and including block 290,000.
The "OP_DATA_20 OP_NOP2 OP_DROP" script is another non-standard transaction type similar to transaction type 8. Its first occurrence in the blockchain is in transaction b8fd633e7713a43d5ac87266adc78444669b987a56b3a65fb92d58c2c4b0e84d and it has occurred 15 times up to and including block 290,000.