77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69 Updated 2024-12-15 +Created 1970-01-01
View more
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.
Read the full article
Bitcoin Updated 2024-12-15 +Created 1970-01-01
View more
Official website: bitcoin.org/en/
Reference implementation: Bitcoin Core.
Read the full article
Bitcoin blockchain parser Updated 2024-12-15 +Created 1970-01-01
View more
This section is about partial implementations that are only able to read the blocks, ususally coming from Bitcoin Core, to interpret the data.
Read the full article
Daisy chain Bitcoin inscription Updated 2024-12-15 +Created 1970-01-01
View more
This is a term invented by Ciro Santilli, and refers to a loose set of uncommon Bitcoin inscription methods that involve inscribing one or a small number of payloads per Bitcoin transaction.
These methods are both inefficient and hard to detect and decode, partly because Bitcoin Core does not index spending transactions: bitcoin.stackexchange.com/questions/61794/bitcoin-rpc-how-to-find-the-transaction-that-spends-a-txo. This makes finding them all that more rewarding however.
On the other hand, they do have the advantage of not depending on any block size limits, as their individual transactions are very small.
Inscribing anything large would however take a very long time, as you'd have to wait until the previous payload chunk is confirmed before going to the next one. This alone makes the format impractical perhaps.
Read the full article
Satoshi uploader Updated 2024-12-15 +Created 1970-01-01
View more
By "Satoshi uploader" we mean the data upload script present in tx 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17 of the Bitcoin blockchain.
The uploader, and its accompanying downloader, are Python programs stored in the blockchain itself. They are made to upload and download arbitrary data into the blockchain via RPC.
These scripts were notably used for: illegal content of block 229k. The script did not maintain its popularity much after this initial surge up loads, likely all done by the same user: there are very very few uploads done after block 229k with the Satoshi uploader.
Our choice of name as "Satoshi uploader" is copied from A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin by Matzutt et al. (2018) because the scripts are Copyrighted Satoshi Nakamoto on the header comment, although as mentioned at Hidden surprises in the Bitcoin blockchain by Ken Shirriff (2014) this feels very unlikely to be true.
A more convenient version of those scripts that can download directly from blockchain.info without the need for a full local node can be found at: github.com/cirosantilli/bitcoin-inscription-indexer/blob/master/download_tx_consts.py by using the --satoshi option. E.g. with it you can download the uploader script with:
./download_tx_consts.py --satoshi 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17
mv 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17.bin uploader.py
The scripts can be found in the blockchain at:
The uploader script uses its own cumbersome data encoding format, which we call the "Satoshi uploader format". The is as follows:
  • ignore all script operands and constants less than 20 bytes (40 hex characters). And there are a lot of small operands, e.g. the uploader itself uses format www.blockchain.com/btc/tx/4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17 has a OP_1, data, OP_3, OP_CHECKMULTISIG pattern on every output script, so the OP_1 and OP_3 are ignored. I.e., it is P2FMS.
  • ignore the last output, which contains a real change transaction instead of arbitrary data. TODO why not just do what with the length instead?
  • the first 4 bytes are the payload length, the next 4 bytes a CRC-32 signature. The payload length is in particular useful because of possible granularity of transactions. But it is hard to understand why a CRC-32 is needed in the middle of the largest hash tree ever created by human kind!!! It does however have the adavantage that it allows us to more uniquely identify which transactions use the format or not.
This means that if we want to index certain file types encoded in this format, a good heuristic is to skip the first 9 bytes (4 size, 4 CRC, 1 OP_1) and look for file signatures.
Let's try out the downloader to download itself. First you have to be running a Bitcoin Core server locally. Then, supposing .bitcon/bitoin.conf containing:
rpcuser=asdf
rpcpassword=qwer
server=1
txindex=1
we run:
git clone git://github.com/jgarzik/python-bitcoinrpc.git
git -C python-bitcoinrpc checkout cdf43b41f982b4f811cd4ebfbc787ab2abf5c94a
wget https://gist.githubusercontent.com/shirriff/64f48fa09a61b56ffcf9/raw/ad1d2e041edc0fb7ef23402e64eeb92c045b5ef7/bitcoin-file-downloader.py
pip install python-bitcoinrpc==1.0
BTCRPCURL=http://asdf:qwer@127.0.0.1:8332 \
  PYTHONPATH="$(pwd)/python-bitcoinrpc:$PYTHONPATH" \
  python3 bitcoin-file-downloader.py \
  6c53cd987119ef797d5adccd76241247988a0a5ef783572a9972e7371c5fb0cc
worked! The source of the downloader script is visible! Note that we had to wait for the sync of the entire blockchain to be fully finished for some reason for that to work.
Other known uploads in Satoshi format except from the first few:
  • tx 89248ecadd51ada613cf8bdf46c174c57842e51de4f99f4bbd8b8b34d3cb7792 block 344068 see ASCII art
  • tx 1ff17021495e4afb27f2f55cc1ef487c48e33bd5a472a4a68c56a84fc38871ec contains the ASCII text e5a6f30ff7d43f96f61af05efaf96f869aa072b5a071f32a24b03702d1dcd2a6. This number however is not a known transaction ID in the blockchain, and has no Google hits.
Read the full article