Non standard Tx with obscure OP codes: examples

Question

I've been writing Python code to fetch various transactions and came across this: 77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69.

The script field is as follows:

• scriptPubKey: "OP_IF OP_INVALIDOPCODE 4effffffff ........... OP_ENDIF" (where ..... is the hex data, all ~2900 bytes worth)

What is going on with..?:

• OP_IF / OP_ENDIF codes (wiki says they correctly open and finish a script)
• OP_INVALIDOPCODE
• 0x4effffffff

• the HUGE data size of

  46726f6d2061336136316665663433333039623966623233323235646637393130623033616663353436356239204d6f6e205365702031372030303a30303a303020323030310a46726f6d3a205361746f736869204e616b616d6f746f203c7361746f7368696e40676d782e636f6d3e0a446174653a204d6f6e2c2031322041756720323031332030323a32383a3032202d303230300a5375626a6563743a205b50415443485d2052656d6f7665202853494e474c457c444f55424c4529425954450a0a492072656d6f76656420746869732066726f6d20426974636f696e20696e20663165316662346264656638373863386663313536346661343138643434653735343161376538330a696e2053657074203720323031302c20616c6d6f73742074687265652079656172732061676f2e204265207761726e6564207468617420492068617665206e6f740a61637475616c6c792074657374656420746869732070617463682e0a2d2d2d0a206261636b656e64732f626974636f696e642f646573657269616c697a652e7079207c2020202038202b2d2d2d2d2d2d2d0a20312066696c65206368616e6765642c203120696e73657274696f6e282b292c20372064656c6574696f6e73282d290a0a64696666202d2d67697420612f6261636b656e64732f626974636f696e642f646573657269616c697a652e707920622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a696e64657820363632303538332e2e38396239623162203130303634340a2d2d2d20612f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a2b2b2b20622f6261636b656e64732f626974636f696e642f646573657269616c697a652e70790a4040202d3238302c3130202b3238302c38204040206f70636f646573203d20456e756d65726174696f6e28224f70636f646573222c205b0a2020202020224f505f57495448494e222c20224f505f524950454d44313630222c20224f505f53484131222c20224f505f534841323536222c20224f505f48415348313630222c0a2020202020224f505f48415348323536222c20224f505f434f4445534550415241544f52222c20224f505f434845434b534947222c20224f505f434845434b534947564552494659222c20224f505f434845434b4d554c5449534947222c0a2020202020224f505f434845434b4d554c5449534947564552494659222c0a2d2020202028224f505f53494e474c45425954455f454e44222c2030784630292c0a2d2020202028224f505f444f55424c45425954455f424547494e222c20307846303030292c0a2020202020224f505f5055424b4559222c20224f505f5055424b455948415348222c0a2d2020202028224f505f494e56414c49444f50434f4445222c20307846464646292c0a2b2020202028224f505f494e56414c49444f50434f4445222c2030784646292c0a205d290a200a200a4040202d3239332c3130202b3239312c3620404020646566207363726970745f4765744f70286279746573293a0a202020202020202020766368203d204e6f6e650a2020202020202020206f70636f6465203d206f72642862797465735b695d290a20202020202020202069202b3d20310a2d20202020202020206966206f70636f6465203e3d206f70636f6465732e4f505f53494e474c45425954455f454e4420616e642069203c206c656e286279746573293a0a2d2020202020202020202020206f70636f6465203c3c3d20380a2d2020202020202020202020206f70636f6465207c3d206f72642862797465735b695d290a2d20202020202020202020202069202b3d20310a200a2020202020202020206966206f70636f6465203c3d206f70636f6465732e4f505f5055534844415441343a0a202020202020202020202020206e53697a65203d206f70636f64650a2d2d200a312e372e392e340a0a `
  

Which decodes to:

c ♣N    Mú♣From a3a61fef43309b9fb23225df7910b03afc5465b9 Mon Sep 17 00:00:00 2001
From: Satoshi Nakamoto <[email protected]>
Date: Mon, 12 Aug 2013 02:28:02 -0200
Subject: [PATCH] Remove (SINGLE|DOUBLE)BYTE

I removed this from Bitcoin in f1e1fb4bdef878c8fc1564fa418d44e7541a7e83
in Sept 7 2010, almost three years ago. Be warned that I have not
actually tested this patch.
---
 backends/bitcoind/deserialize.py |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/backends/bitcoind/deserialize.py b/backends/bitcoind/deserialize.py
index 6620583..89b9b1b 100644
--- a/backends/bitcoind/deserialize.py
+++ b/backends/bitcoind/deserialize.py
@@ -280,10 +280,8 @@ opcodes = Enumeration("Opcodes", [
     "OP_WITHIN", "OP_RIPEMD160", "OP_SHA1", "OP_SHA256", "OP_HASH160",
     "OP_HASH256", "OP_CODESEPARATOR", "OP_CHECKSIG", "OP_CHECKSIGVERIFY", "OP_CHECKMULTISIG",
     "OP_CHECKMULTISIGVERIFY",
-    ("OP_SINGLEBYTE_END", 0xF0),
-    ("OP_DOUBLEBYTE_BEGIN", 0xF000),
     "OP_PUBKEY", "OP_PUBKEYHASH",
-    ("OP_INVALIDOPCODE", 0xFFFF),
+    ("OP_INVALIDOPCODE", 0xFF),
 ])


@@ -293,10 +291,6 @@ def script_GetOp(bytes):
         vch = None
         opcode = ord(bytes[i])
         i += 1
-        if opcode >= opcodes.OP_SINGLEBYTE_END and i < len(bytes):
-            opcode <<= 8
-            opcode |= ord(bytes[i])
-            i += 1

         if opcode <= opcodes.OP_PUSHDATA4:
             nSize = opcode
--
1.7.9.4

h

Are there other non-standard transaction examples which are similarly noteworthy? To be clear, the hidden code is fun, but I'm looking for non-standard usage of OP_CODEs in Txns which have preferably been accepted as well formatted.

Answer 1

There has been discussion about this particular transaction before on reddit. This is clearly not a valid transaction and was probably used to store data on the blockchain before OP_RETURN.

Why was it relayed? It may not have been. There's a very easy way to get a transaction like this included and it's by submitting the transaction directly to a mining pool like eligius. As long as you add a high enough fee, they will process valid, but non-standard transactions.

Answer 2

I found an INCREDIBLY detailed spreadsheet documenting every single "weird" Tx up until March 2014. It's available at John Ratcliff's Code Suppository in his "Transaction Input Signatures in the Bitcoin Blockchain over time" blog post, which in itself, is an incredibly comprehensive source of technically based Bitcoin information.

• Spreadsheet documenting "weird Txns" (March 4th, 2014 link)

Similar in discussion and conclusions, Ken Shirriff assesses Txn Malleability in his discussion, which is especially noteworthy since both these articles date from around the Mt. Gox implosion of Feb. 2014.

From John Ratcliff:

On November 26, 2013 a whole bunch of input scripts show up which appear to all be considered valid by blockchain.info but when I processed them I found that they still had extra data on the stack after the signature portion had been parsed. This doesn't make them invalid, just unusual.

He continues:

On seven occasions, instead of finding the expected SIGHASH_ALL byte of 0x01 a SIGHASH byte of 0 was found instead. For those transactions blockchain.info appears to mark them as valid, though I'm not sure why it is.

On 120 occasions, the SIGHASH_ALL value is found, however, it is preceded by a single zero byte.

An additional 45 times prior to encountering SIGHASH_ALL multiple zero bytes are found.

On one occasion in the blockchain, prior to finding the SIGHASH_ALL value there was a stream of 0x2A bytes. Blockchain.info still flagged this as being a valid transaction, so I guess this is acceptable, though I'm not sure why.

Eleven times I found a public key signature that was just hex 0x21 bytes long instead of the standard 0x41 value we are used to seeing.

Several thousand transactions use the PUSHDATA0 instruction in the front of the script, and then I couldn't fully parse all of the signature. There is probably nothing wrong with this format, it's just not the most standard and I haven't taken it into account yet.

SIGHASH_PAY_ANY and SIGHASH_PAY_SINGLE were used like a hundred times or so.

Examples provided include:

• the first transaction in the blockchain which has an 'abnormal' signature (block #157785, DEC 17, 2010)
• On December 13, 2013, the blockchain got spammed with a huge number of inputs which have invalid script signatures.
• The next abnormal input happens on January 7, 2013, with an input script that just contains OP_1 (a true statement). This happens again on January 20, 2013.
• On July 21, 2013 someone left an amusing text message in their signed transaction. Blockchain.info identifies this signed transaction as being of 'Escrow' type.

Some other amusing Txns to note:

• 38df010716e13254fb5fc16065c1cf62ee2aeaed2fad79973f8a76ba91da36da: I should not run the washing machine while listening to WZBC. I managed to convince myself that the machine was slowly failing -- that a rythmic, squeaking noise it had been making had gotten a little worse. Ten minutes later, though, the machine had paused. But the noise was still there.
• 320a5c8eb5e8e0d4fc2ae48fc6f2d1c86ebe637193a61fcc9a13925d9cf96b1b: All your dummy values are belong to us.

And....in this Tx's scriptSig, a meta-joke of sorts, referencing Terminator's Skynet AI!:

• 61e26d407c17e8ee33a8b166c78f78c53cdcdc0078ae1f9405e6583cfb90eaf4:

Skynet went online on August 4th 1997, and began to learn at a geometric rate. It became self-aware on August 29th 1997 2:14 am Eastern Time. On August 29th 1997 2:15 am it discovered nihilism, and either shut itself down due to despair, or because it was logical. We're not sure which.

On August 4th, 1998, it failed to renew its domain name, which was promptly squatted on by a link farmer pitching X10 cameras and singing electric fish.

March 2015 edit:

A Survey of Bitcoin Transaction Types from QuantaBytes provides another great source of various Tx and historical commentary (ie first instance of a P2SH Tx = 9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6)