A Bitcoin wallet stores a collection of public/private key-pairs of a user, and not directly bitcoins. A Bitcoin address is an identifier of 26–35 alphanumeric characters, and it strictly derives from the hash of a generated public key (pubkey in the following; Antonopoulos, 2017). A private key is a random 256 bit number, and the corresponding pubkey is generated through an Elliptic Curve Digital Signature Algorithm (ECDSA). A transaction input must store the proof it belongs to who wants to reuse the money received in a previous transaction. The output of a transaction instead describes the destination of bitcoins by providing a challenge to users. Hence, the ownership of the coins is expressed and verified through links to previous transactions. For example, in order to send 3 bitcoins (BTC) to Bob, Alice needs to refer to other transactions she has previously received, whose amount is 3 BTC at least. To lock the coin, a script called scriptPubKey is used, while to prove the ownership of a coin, a script called scriptSig is used instead. In the following, we will refer to them as “locking script” and “unlocking script.”

A UTXO is an Unspent Transaction Output that can be spent as an input in a new transaction. To assemble the candidate block, a Bitcoin miner selects transactions from the memory pool (mempool for short): as its name suggests, it is a pool of memorized transactions collected by a miner. The data that is stored in the mempool consists of unconfirmed transactions which still needs to be processed by the Bitcoin Network, by applying a priority metric to each transaction and by adding the highest priority transactions in the next block first than lower priority ones. Today's miners choose which transactions to mine only based on fee-rate, thus prioritizing the transactions with highest fees per kilobyte of transaction size. Any transaction left in the mempool, after the block is filled, will remain in the pool for inclusion in the next block. As transactions remain in the mempool, their inputs “age,” as the UTXO they spend get deeper into the block-chain with new blocks added on top. Eventually, a transaction without fees might reach a high enough priority to be included in the block for free (Antonopoulos, 2017).

The Bitcoin transactions language Script is a Forth-like (Rather et al., 1993) stack-based execution language. Script requires minimal processing and it is intentionally not Turing-complete (no loops) to lighten and secure the verification process of transactions. An interpreter executes a script by processing each item from left to right in the script. Script is a stack-based language: data is pushed onto the stack, instead the operations can push or pop one or more parameters onto/from the execution stack, operate on them, and possibly push their result back in the stack.

For example, the operator op_add pops two items from the stack, add them, and finally push the resulting sum onto the stack. There are also conditional operators such as op_equal: it pops two items from the stack and pushes true (represented by number 1) if the operands are equal, or false (represented by 0) if they are not equal. In Bitcoin, transaction scripts usually contain a final conditional operator, so that they can produce the result true, which points to a valid transaction.

Most locking scripts refer to a public key address: they require the proof of ownership of the address in order to spend money. However, this is not mandatory (Andrychowicz et al., 2014): any combination of locking and unlocking scripts that result in a final true value is valid. Figure 1 we show the step-by-step validation procedure of this locking plus unlocking script. We have this locking script: “2 op_add 8 op_equal,” which can be satisfied by the unlocking script: “6'.” The validation software combines the locking and unlocking scripts and produces the following script: “6 2 op_add 8 op_equal.” This script is interpreted left-to-right as: first 8 is pushed onto an empty stack, then 2, and then the operation op_add is performed between the two last operands in the stack, which are also popped from it. The result, i.e., 8, is pushed onto the stack, and then the 8 in the script is pushed as well. Finally, op_equal is performed, thus removing the two 8 and pushing true as result.

Opcodes are the operators of the scripting language. Now we describe some operators that we will refer to in the next sections:

In the first few years of Bitcoin history, the developers introduced some limitations in the scripts that could be processed by the reference client. In fact, transactions can be accepted by the network if their locking and unlocking scripts match a small set of believed-to-be-safe templates. This is the isStandard() and isStandardTx() test, and transactions passing it are called standard transactions⁴. More accurately, the isStandard() function gives TRUE if all the outputs (locking script) use only standard transaction forms. On the other hand, the isStandardTx() function gives TRUE if all the inputs (unlocking script) use only standard transaction forms according to the output that they are spending. The main reason behind defining and checking standard transactions is to prevent someone from attacking Bitcoin by broadcasting harmful transactions. Moreover, these checks also keep users from creating transactions that would make adding new transaction features in the future more difficult. There are seven standard types of transactions.

Pay to Public Key Hash (P2PKH): The transaction Pay to public key hash is the most used in the network. This is because it is the default transaction in a Bitcoin client. These transactions contain a locking script that encumbers the output with a public key hash: “op_dup op_hash160 <public key a hash> op_equal op_checksig.” Figure 2 shows an example of P2PKH script validation. A P2PKH output can be unlocked (spent) by a public key and a digital signature created with the corresponding private key: “ <signature a> <public key a>.”

Pay to Public Key (P2PK): The Pay to Public Key scheme is simpler than P2PKH; it was used in coinbase transactions, i.e., the one with the miners are paid for their job, until July 2012, then they started use the P2PKH (see Figure 3). P2PK, as the name suggests, has in its locking script directly the pubkey, instead of its hash: “ <public key a> op_checksig.” Since 2017 the most used output in a coinbase transaction is the OP_RETURN, which is a provably unspendable (see section 5). This coinbase transactions have some P2PKH outputs in order to pay the miners and more OP_RETURN outputs, which do not carry bitcoin (the value of the outputs is 0 BTC). The number OP_RETURN outputs Is greater than the number of P2PKH ones. These OP_RETURN outputs are related to Segregated Witness⁵ (SegWit) implemented soft fork: They are linked to the Merkle root of the witness tree. The SegWit needs an extended blockheader, but the blockheader cannot be extended without a hardfork, so segwit blocks commit to this witness tree by including the root in an OP_RETURN in the coinbase transaction⁶. Figure 4 shows the P2PK script validation process. To unlock this transaction, only the corresponding signature of pubkey in the locking script is needed: “ <signature a>.”

Multi-signature: Multi-signature scripts set a condition where N public keys are recorded in the script, and at least M of those signatures must be used to unlock a transaction. This is also known as an M-of-N scheme, where N is the total number of keys and M is the lower threshold of signatures required for a validation. The maximum M for the current Bitcoin Core implementation is 15. The general form of a locking script setting an M-of-N multi-signature condition is: “m <public key 1> <public key 2> … <public key n> n op_checkmultisig.” In Figure 5 the validation steps of this script is visually represented. The locking script can be satisfied with an unlocking script containing: “op_0 <signature 1> <signature 2> … <signature M>.” Notice that the prefix op_0 is required because of a bug in the original implementation of checkmultisig: due to this bug, one more argument on the stack is required. checkmultisig simply considers it as a placeholder.

Data output (op_return): The Data output transactions are used to store data not related to Bitcoin payments. Their form is “op_return <data>.” Since any output with op_return is provably un-spendable. Thus, the output can be immediately pruned from the UTXO⁷ set even if it has not been spent. These transactions can be used to save different kinds of information on the block-chain, which is in this way used as an immutable distributed ledger by applications, as e-voting ones (Bistarelli et al., 2017, 2019b), for example. Such transactions are unlockable. Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Additionally, it is trivially obvious that the demand for external, massively-replicated data store is essentially infinite. Despite this, OP_RETURN has the advantage of not creating bogus UTXO entries, compared to some other ways of storing data in the block-chain. This helps miners to be faster in calculating the priority transactions function.

Pay to Script Hash (P2SH): A Pay to Script Hash transactions contain the hash of a script of a different transaction (called redeem script) in their locking script. For example, we can hash a 2-of-5 multi-signature transaction. Instead of “pay to this 5-key multi-signature script,” the P2SH equivalent transaction is “pay to a script with this hash.” Hence, the script only stores a 20-byte hash instead of five pubkeys (around 180 byte using the compressed form). Figure 6 shown an example of locking script: “op_hash160 <2-of-5 multi-signature script hash> op_equal,” with the unlocking script as: “ <sig1> <sig2> <2-of-5 multi-signature script>.” See Figure 6 for an example of P2SH script validation. More details about this transaction are given in section 4.

Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH): With the introduction of the Segregated Witness⁸ (SegWit) in Bitcoin, the default transaction P2PKH can be also obtained in a different way. The main differences of the Segregated Witness are the locking script shorter and the signature that are moved outside the unlocking script (see Figure 7). In fact, in place of the longer script in P2PKH, the script in P2WPKH is shortened to: “op_0 <public key a hash>” A P2WPKH output can be unlocked (spent), as the P2PKH, by a public key and a digital signature created by the corresponding private key: “ <signature s> <public key a>.” The difference is that these components are no longer in the unlocking script, but in the witness field instead.

Considering the first 550 000 blocks in the block-chain, there are 356 588 805 transactions that generate a total of 968 098 854 outputs, of which 910 274 680 have been spent (94,03%). These include 967 874 499 standard transaction outputs (99,98% of the total number of outputs). Hence, non-standard transaction outputs are only the 0,02% of the total.

In Figure 8 we show the distribution of standard transactions. As introduced before, the most common class is represented by P2PKH transactions, since they are the default ones in the Bitcoin client. The P2SH scheme is the second mostly frequently used class of transactions, with almost 150 million outputs. Interestingly, the number of P2SH and op_return transactions has considerably increased if compared to the data from early 2018 (Bistarelli et al., 2018a). In Figure 8 we see that the most used M-of-N multi-signature class corresponds to the scheme 1-3, with 58% of all the multi-signature transactions. The second most used scheme is 1-2, with 41%. We found also: 38 repetitions of 3-3, 3 repetitions of 0-1, only one 1 transaction in the form 3-5, 1 in 1-9, and, finally, 1 in the 9-9 form.

Transactions are validated through isStandard() and isStandardTx() functions in the Bitcoin Core reference implementation. In case they do not pass such tests, they are simply discarded. However, some transactions that deviate from the standard enforced by Bitcoin Core can be mined as well: these transactions can be issued in the block-chain thanks to miners that relax these checks enforced by such control functions, as for example Eligius¹¹. Non-standard transactions use more complex script forms, represent challenges, or just result from bugs. Their singularity comes from non-standard inputs or outputs.

Correctly validating non-standard transactions can make the creation of future transactions harder for two separate reasons:

Concerning the first reason, the non-standard transaction check was first implemented by Nakamoto before P2SH existed, so it could not be so easily circumvented. This gave developers time to better analyze the script language and fix problems with the remaining opcodes: e.g., in some cases¹² it was possible to create a transaction that took 5 h to be verify. However, even if the scripting language is perfectly safe, each script has to be stored by every full node until it is spent as part of the UTXO database. Since a locking script is limited to 10,000 bytes, this means that an attacker can add up to 10 KB to the UTXO set for every output he creates, potentially quickly adding enough data to degrade performance enough that the rate of stale blocks (orphan blocks) mined increases, which would reduce miner profits and encourage them to centralize further to recover that lost revenue.

Concerning the second reason, there are some opcodes the network does not want people to use. These are opcodes that might be redefined in the future, e.g., the op_nopX opcodes that have been used for soft forks in the past (op_nop1 became op_checklocktimeverify and op_nop2 became op_checksequenceverify). Lately, Bitcoin Core 0.16.1 quit the use of op_codeseparator in non-segwit in preparation for another potential soft fork that will reduce some lingering problems with expensive verification. In those cases, standard transactions forbid both the scriptPubKey and the redeemScript (P2SH) versions (and, when applicable, the segwit P2WSH version), thus the easy circumvention is not possible in that case¹³.

One of the reasons to include non-standard transaction in the block-chain could be that miners have a long-term investment in the health of the Bitcoin network. If Bitcoin collapses, then their expensive ASICs are worthless. Miners particularly need bitcoins to remain valuable over the long term because their hardware produces bitcoins over time. If nobody includes transactions in blocks, then bitcoins would be useless and therefore worthless. That would impact on miners long-term investment. If this ever became a problem, transactions would just wind up with higher fees to encourage miners to include them. Right now, enough miners include a transaction with a very small fee and there is no reason in paying more¹⁴.

We searched in the block-chain for these particular transactions and we obtained nine patterns of non-standard transactions. We now describe them by also highlighting the interval of years in which they were confirmed in the block-chain.

Pay to Public Key Hash 0 [2011]: It corresponds to a distortion of P2PKH, with the difference that instead of the hash of a pubkey, there is a 0 value. The locking script is in the form “op_dup op_hash160 0 op_equalverify op_checksig.” These transactions are unspendable because, as P2PKH ones, in order to verify them a miner needs (i) the pubkey corresponding to the hash in the locking script, and (ii) the private key to generate the corresponding signature. However, we know that hash160 returns a 20 byte long hash: therefore, no key passed to the hash function can return 0 ¹⁵. A Bitcointalk thread¹⁶ indicates that this deviation was mainly performed by MtGox. The outputs represent a value of 2609.36304319 BTC, around 8, 000$ at that time (around 20 million dollars nowadays).

P2PKH NOP [2011, 2014]: This transaction is identical to P2PKH with the only difference that a nop (an operation that does nothing) is in the locking script: “op_dup op_hash160 <hashpubkey> op_equalverify op_checksig op_nop.” This transaction was probably used to test the op_nop operator. It can be unlocked by a script identical to that of P2PKH ¹⁷.

OnlyHash [2011-2014]: The OnlyHash transactions are the most numerous non-standard class in the block-chain. These transactions contain a hash in the locking script, which is usually the hash of a file for using the block-chain as a ledger to register documents. Therefore, the security and resilience of the block-chain system can be used by applications such as digital-note services, stock exchange certificates, and smart contracts. The blocking script corresponds to “ <hash-of-something>.” These transactions were used before the introduction of the op_return, which can be used for the same purpose ¹⁸.

P2Pool Bug [2012]: These transactions are due to a bug ¹⁹ in the P2Pool²⁰ mining tool between February 2nd, 2012 and April 1st, 2012. Instead of a plain P2PKH locking script, the following script was added: “op_ifdup op_if op_2swap op_verify op_2over op_depth.” This script does not make any sense and is not even valid as the OP_IF is not closed by a corresponding OP_ENDIF, hence it is consequently unlockable ²¹.

op_checklocktimeveirfy op_drop (CLTV) [2012]: In this case the locking script is in the form: “ <data>op_checklocktimeveirfy op_drop.” The op_checklocktimeveirfy operator makes the transaction invalid if the element at the top of the stack is greater than the nLockTime²² field of a transaction. In practice, using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably un-spendable until a certain point in the future, i.e., it is a way to freeze funds up to certain future day ²³. Therefore, by checking the <data> element against the rules above, we can verify the transaction by using an unlocking script that inserts true into the stack ²⁴.

OP_MIN OP_EQUAL [2012]: These transactions are related to a script as “op_min 3 op_equal,” which simply needs two numbers corresponding to the equation x ≤ y ∧ x = 3 to be verified. Hence, to unlock it is possible to prepare an unlocking script as “3 4.” We can see this transaction as a proof of how an equation can be used to generate a bitcoin transaction. This means that anyone can easily unlock such a transaction without any private key ²⁵.

Pay to Hash (P2H) [2012-2015]: These transactions are a simplification of plain P2SH ones; we have a blocking script identical to P2SH, with the difference that the internal hash does not refer to a redeem script, but it is the hash of an hexadecimal string: “op_hash160 <hash160ofsomething> op_equalverify.” There are two variants, where only the type of hashing operator changes: one corresponds to hash256, while the other one to sha256. The two blocking scripts are “op_hash256 <hash256ofsomething> op_equal” and “op_sha256 <sha256ofsomething> op_equal.” We can consider these transactions as “contest” in the network to find the correct value of the hash in the transactions.

A P2H cannot be considered a Hash Time-locked Contract (HTLC). A HTLC is essentially a type of payment in which two people agree to a financial arrangement where one party will pay the other party a certain amount of cryptocurrency. However, the receiving party only has a certain amount of time to accept the payment, otherwise money is returned to the sender. Instead a P2H transaction is different from a HTLC because it generates a payment that can be accepted by the receiver without any time-constraint.

These outputs can only be spent by providing data that once hashed (called hashlock) by a cryptographic function is equal to a given hash ²⁶.

The verification step is simple: the hexadecimal string of the hash in the blocking script is enough to spend the transaction ²⁷.

UnLocked (UL) [2015]: This transaction has an empty locking script: it can be unlocked by simply having true as unlocking script. Almost all of these transactions carry an amount of 0 BTC, i.e., they are valueless transactions. Such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include²⁸ an additional one after sending funds to an address they control ²⁹.

OP_RETURN ERROR [2016-2017]: These transactions are identical to OP_RETURN, with the difference that there is an error in the script code. The code asks to push onto the stack a number of opcode higher than what is really in the code itself. For example an OP RETURN script could ask to insert in the stack the next 40 bytes in the code, but if there are only 28 bytes, the execution fails. This transaction is apparently due to a programming error. The locking script is: “op_return error” (an error is returned)³⁰.

OP_2 OP_3 ERROR [2017-2018]: These transactions are similar to OP_RETURN ERROR, but they have no OP_RETURN in the script code. As the OP_RETURN ERROR, their code asks to push onto the stack a number of bytes higher than what is really in the code itself. Probably these transactions, like the op_return error, are related to an implementation error This is the locking script: “op_2 op_3 error” (an error is returned)³¹.

Statistics for non-standard transactions: Non-standard transactions are 224 355 (0,02%), even if the majority of them, i.e., 219 174, are unlocked transactions with a 0 BTC value (all of them in year 2015). This means that they are transactions without blocking scripts, and they do not carry any money: in practice they are “fake” transactions. Thus, if we do not consider such transactions, “real” non-standard ones are only 5 181: 0,000 5% of the total number in the block-chain.

In Figure 9 we show the distribution of non-standard transactions. Without considering unlocked ones, 2 3 ERROR is the most common class, with more than three thousand transactions. The second class is the OnlyHash, with almost one thousand outputs, while the remaining ones have few outputs. In Figure 9 we show the percentage of non-standard transactions associated with each miner. In order to identify the miner of a transaction we looked for the block of this transaction. Then we took the coinbase transaction of the block, in this particular transaction there is a field called just coinbase where the miners put their id. We classified the miners according to these tags ³².

In Figure 10 we associate the percentage of non-standard transactions: we found that year 2018 has more than 3,200 occurrences of this kind of transactions, all of type op_2 op_3 error. Overall, these non-standard transactions contain almost 2,615 bitcoins that are no longer spendable.

Like in the block-chain analysis, also inside P2SH transactions the majority of the transactions is standard. In fact there are 140 509 279 standard transactions, which are 99,92% of the total. In Figure 11 we show the distribution of standard transactions inside P2SH ones. The most frequent class of transactions is not the P2PKH (only 447), as in section 3, but it is the multi-signature one, with more than 90 million occurrences (65,7%). The second one is the P2WKH with almost 35 million transactions (24,6%).

Inside P2SH we found 111 122 non standard transactions (0,08% of the total); this amount is four times more than what we obtained when we “simply” analyzed the block-chain (0,02%). We found several new classes of non-standard transactions, which are different from previous ones.

The data dimension inside the OP_RETURN transaction is different also because the standard dimension changed during years. In fact, in the Bitcoin Core 0.9.0³⁸ the limit was only 40 bytes. Then from the 0.10.0³⁹ release on February 16th 2015, Bitcoin nodes could choose whether to accept or not OP_RETURN transactions, and to set a maximum dimension. The 0.11.0⁴⁰ release on July 12th 2015 extended the data limit to 80 bytes. Finally, the 0.12.0⁴¹ release on February 23th 2015 set the maximum to 83 bytes (80 byte default, plus 3 bytes overhead).

In Figure 14 we show the distribution of OP_RETURN data size. The most used size is 20 bytes with more than 4 million occurrences, the second one is 80 bytes with almost 1 million outputs, and the third is the 40 bytes with more than 500 thousands occurrences. There are also other transactions with only one occurrence, which we do not show in Figure 14, exactly with size 95, 114, 134, 190, 449, and 983 bytes. There are also 296 518 output with data size 0, i.e., empty, of which 222 348 were made in September 2015 by compromised addresses⁴². These transactions were definitely used as stress tests for the Bitcoin network (Baqer et al., 2016).

In Figure 15 we show the distribution of OP_RETURN transactions over time. It seems clear that every year the OP_RETURN occurrences double, and this proves that their use is increasing at a high rate.

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.