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)
  • 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

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_SINGLEBYTE_END", 0xF0),
-    ("OP_DOUBLEBYTE_BEGIN", 0xF000),

@@ -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


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.

2 Answers 2


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.

  • I've edited my original post to reframe the question's scope, namely, what are some other non-standard transactions (i.e. not 76a914__88ac or multisig related) (fantastic answer btw) Commented Feb 9, 2015 at 6:08

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.

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:

Some other amusing Txns to note:

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

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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.