Non-standard P2SH scripts

In a previous article, I explored different forms of non-standard scripts present in the Bitcoin blockchain. In this article, I’ll focus on non-standard scripts use in pay-to-script-hash (P2SH) transactions.

How does P2SH works?

All bitcoins are secured by a script: a sequence of instructions describing how to spend the bitcoins it secures. When spending bitcoins, arguments resulting in a valid execution of the script must be provided. While the underlying language used for these scripts can handle many different operations (arithmetic, cryptography, string operations, …), only a few standard script templates are broadcasted by Bitcoin peers.

Among them is P2SH, pay-to-script-hash. P2SH Bitcoin addresses (those beginning with a ‘3’) encode the cryptographic hash of a script, instead of encoding a ECDSA public key like the first version of Bitcoin addresses (beginning with a ‘1’). The hashed script, along with the arguments needed for its valid execution, are only revealed when spending the bitcoins sent to a P2SH address.

The main use of P2SH is multisig, 99% of known P2SH scripts use it. The remaining 1% is what I explored.

Open Assets

The main source of non standard P2SH scripts is the Open Assets Protocol. Around 78% of the 31.300 non-standard scripts I studied were Open Assets definition pointers.

Open Assets is a colored coins protocol that’s been implemented for Bitcoin. The goal of this protocol is to be able to define and trade real world assets using the Bitcoin blockchain. The first part in this protocol is inserting a reference to the asset definition (a document describing the asset, the conditions attached to it, the issuer’s identity, …) in the blockchain.

The reference is usually the document’s hash160. It’s also possible to create a asset definition pointer by using the document’s URL and its SHA-256. However, this type of asset definition pointer is too big to be put in the marker output like the hash160. The solution is put to use P2SH to include arbitrary data in the blockchain. The marker data is inserted in a standard script but discarded when executing the script, hence making it present in the blockchain but not making the transaction unspendable.

Around 24.000 thousands assets have been defined this way, the great majority (22.000) of these assets are stocks (from the NASDAQ’s website and stock.com), they were defined around July 21st, 2015.

Storing text

From emails, code to advertising, the blockchain contains a lot of text. Even the first Bitcoin transaction ever contained the text:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

implying that the creation of Bitcoin was a reaction to the 2008 crisis.

P2SH is convenient when storing text in the blockchain as it’s possible to store up to 1.5KB of text at a time.

I focused on a specific type of script used to store text in the blockchain, it is the most common script used to that effect. Here’s an annotated example of this script storing a payload split in two parts:

<signature>                         # An ECDSA signature
<text> <text>                       # The text payload split in 2
OP_HASH160 <hash160> OP_EQUALVERIFY # Checking the 2nd part's hash
OP_HASH160 <hash160> OP_EQUALVERIFY # Checking the 1st part's hash
<pk> OP_CHECKSIGVERIFY              # Checking the signature
<n> OP_DROP                         # Pushing then dropping a number
OP_DEPTH OP_0 OP_EQUAL              # Checking if the stack is empty

This kind of Bitcoin script comes from a Python script authored by Peter Todd, a Bitcoin Core developer. Each part of the text is a line from the original text, the <n> OP_DROP part is just to ensure a unique script hash if the same text is used with the same public key, finally, the check for an empty stack is there to prevent script malleability.

This first time this Python script was used was on April, 1st 2015 and consisted of publishing the Python script itself (PGP signed by Peter Todd) along with a rather nonsensical Cointelegraph article mentioning «a small script embedded into the blockchain that either forces the download and install of more powerful code».

Other texts included in the blockchain using this script are varied, from Neals Stephenson’s Cryptonomicon and Unix — The Hole Hawg, logs from the #bitcoin-wizards IRC channel, satoshi’s posts on Bitcointalk, bitcoin-dev mails and reddit comments.

Trivial scripts

As with normal scripts, P2SH scripts also encode trivial scripts, that can be spent without providing any ECDSA signature nor hard work.

For example, the script:

OP_3 OP_5 OP_4 
OP_3DUP 
OP_ADD OP_9 OP_EQUALVERIFY
OP_ADD OP_7 OP_EQUALVERIFY
OP_ADD OP_8 OP_EQUALVERIFY
OP_1

encodes the equation system:

z + y = 9, z + x = 7, x + y = 8

whose only solution is x=3, y=5 and z=4.

This script’s address is 3MbZjYS1Kjo5An9vVCwZYTd2JeobwjUsFh and it was published and spent on November 21st, 2015.

Another example of non-standard P2SH script is:

OP_1 
1449587175 OP_CHECKLOCKTIMEVERIFY OP_DROP 
OP_1 OP_ADD OP_2 OP_EQUAL

This script uses the newest addition to the script instruction set: OP_CHECKLOCKTIMEVERIFY (CLTV). It’s a normal 1 + 1 = 2 script, with the twist that it can’t be spent until a given point in time.

Introduced by BIP-65, and recently activated in a softfork, CLTV allows users to make a transaction spendable only after a point in the future. For this example, this script was spendable only after December 8th, 2015 at 3:06pm (UTC) and was spent on December 8th, 2015 at 3:21pm (UTC) making it the first transaction using CLTV.

Conclusion

Non-standard scripts are now mainly created using P2SH, in the last 2 months, only a handful of non-P2SH non-standard scripts have been mined. As for my previous article, I focused on scripts that I found interesting, not on all of the non-standard P2SH scripts.

A list of all non-standard P2SH scripts is available at this address.