Satoshi uploader by Ciro Santilli 40 Updated 2025-07-16
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:
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.
This is a collection of cool data found in the Bitcoin blockchain using techniques mentioned at: Section "How to extract data from the Bitcoin blockchain". Notably, Ciro Santilli developed his own set of scripts at github.com/cirosantilli/bitcoin-inscription-indexer to find some of this data. This article is based on data analyzed up to around block 831k (February 2024).
Drop some Bitcoins at 3KRk7f2JgekF6x7QBqPHdZ3pPDuMdY3eWR if you are loaded and like this article in order to support some much needed higher educational reform: Section "Sponsor Ciro Santilli's work on OurBigBook.com".
When this kind of non-financial data is embedded into a blockchain some people called an "inscription". The study or "early" inscriptions had been called a form of "archaeology"[ref][ref]. Since this is a collection of archeological artifacts, we call it a "museum"!
One really cool thing about inscriptions is that because blockchains are huge Merkle trees, it is impossible to censor any one inscription without censoring the entire blockchain. It is also really cool to see people treating the Bitcoin blockchain basically like a global social media feed!
Starting on December 2022, ordinal ruleset inscriptions took the bitcoin blockchain by storm, and dwarfed in volume all other previous inscriptions. This museum focuses mostly on non-ordinals, though certain specific ordinal topics that especially interest he curators may be covered, e.g. Ordinal ruleset inscription porn and ordinal ASCII art inscription.
Hidden surprises in the Bitcoin blockchain by Ken Shirriff (2014) is a mandatory precursor to this article and contains the most interesting examples of the time. But much happened since Ken's article which we try to cover. This analysis is also a bit more data oriented through our usage of scripting.
Artifacts can be organized in various ways:
In this article we've done a mixture of:
  • themes: if multiple items fall in a theme, we tend to put it there first
  • then by media type if they don't fit any specific theme
  • then by encoding
  • and finally chronologically within each section
Who said it was easy to be a museum curator!
The toplevel transaction is 78f0e6de0ce007f4dd4a09085e649d7e354f70bc7da06d697b167f353f115b8e
Like all AtomSea & EMBII uploads, the data it is encoded as P2FKH.
The full concatenated payload contains the following ASCII characters:
8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba|396*8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba
575061146335bd57f2dc132112152d0eeea44cf187ea6a52ac02435a7e5bea44
674c7cc34ea44bb276c6caf76f2b28fa1597380ab6e6a6906076d8f7229ca5b3
8e2642416ad20924b43f51a633fa1c0a5ba8e4a7b631877db1c64540a42081c9
a3084018096b92af04df57b6116e01ff4b7c7e8bd228235ed49e23f4a2817029
39348722b841afa0c5b67e5af10839afe965ed1b24874e89336bea9fa4ef3091
tomSea & EMBII
Output 2 is a change, so it contains no data and has been excluded. Change appear to be randomly placed in the list of output of the uploads, but they can be easily removed because they are the only output with a different value.
The newlines shown above are explicitly encoded as CR LF newlines with characters 0d 0a.
396 is the number of payload bytes between 396*8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba and the last txid 39348722b841afa0c5b67e5af10839afe965ed1b24874e89336bea9fa4ef3091, including newlines but exclusding the last line.
The last line appears to contain arbitrary data to fill out the 20 byte payload granularity:
  • A is missing from AtomSea
  • there is a NUL character just after EMBII, possibly part of the protocol?
Now let's inspect the transactions linked to from toplevel.
tx 8881a937a437ff6ce83be3a89d77ea88ee12315f37f7ef0dd3742c30eef92dba contains only payloads without any change. It starts with the following UTF-8 string with CR LF spaces;
"396\“There is nothing like returning to a place
 that remains unchanged to find the ways in
 which you yourself have altered.”
 -Nelson Mandela


Nelson Rolihlahla Mandela was a South African anti-apartheid revolutionary, politician and philanthropist who served as President of South Afrd۽^2c'︨`ica from 1994 to 1999. -Wikipedia

Born: July 18, 1918, Mvezo, South Africa
Died: December 5, 2013
396 is once again the number of payload bytes present in that string.
This is immediately followed without any separator by a filename, and another size marker:
Nelson-Mandela.jpg?14400/
then followed by all the 14400 - len(Nelson-Mandela.jpg?) + len(/) JPEG bytes bytes, starting with the two JPEG file signature byte "FF D8".
Further toplevel transaction payloads are then simply concatenated with the previous ones, until the last bytes of the image "FF D9" appears at the end of the payload.
00000430  d2 81 de 80 0c 52 f1 40  ea 29 68 03 ff d9 6f 6d  |.....R.@.)h...om|
00000440  53 65 61 20 26 20 45 4d  42 49 49 00              |Sea & EMBII.|
padded once again by an AtomSea & EMBII string fragment terminated by a NUL character.
These were found by running object detection software for some porn/nudity detection. We need to run some more, all sex was likely missed: github.com/GantMan/nsfw_model/issues/160
This section is about ordinals that are interesting primarily due to technical reasons linked to edge cases of the protocol.
Interesting MIME types:
Different ord markers:
  • 71e85885522047240a9e70542145dbf2385e1bd468e6ac6002aa755422ea10f5 uses takingnames. Decode with:
    bitcoin-core.cli decodescript "$(bitcoin-core.cli getrawtransaction 71e85885522047240a9e70542145dbf2385e1bd468e6ac6002aa755422ea10f5 true | jq -r '.vin[0].txinwitness[1]')" | jq -r .asm | sed 's/.* 0 //;s/ OP_ENDIF//;s/ //g' | xxd -r -p > 71e85885522047240a9e70542145dbf2385e1bd468e6ac6002aa755422ea10f5.png
    gives the PNG of the wireframe draing of a washing machine with transparent background.
These were ordinals that were only indexed in later versions of the script. So to prevent changing the useless indices of existing ordinals, they gave them negative numbers.
The word "cursed" is a meme from the 2010/20s, e.g. knowyourmeme.com/memes/cursed-images--2.
Some examples:
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.
Bitcoin addresses are by convention expressed in Base58, which is a human readable binary-to-text encoding invented by Bitcoin.
It is a bit like Base64, but obsessed with eliminating characters that look like one another in popular but stupid fonts like capital "I" and lower case ell "l". As such, any embedded text is rather obfuscated due to this limitations, and people often resort to leet-like replacements such as '1' to represent 'I'.
This seems to be one of the earliest strategies used to encode messages into the Bitcoin blockchain. The first known example appears in 2011. Then starting November 2011, a large number of messages were inscribed n short successsion, presumably by a single person or small group.
The interest in Base58 encoding might have initially arisen with people's desire to have "vanity addresses", that is Bitcoin addresses that have real words in them, much like vanity plates or vanity numbers. Such addresses with long words in them are hard to find while keeping the address spendable, because they have to correspond to a private key. An extreme notable example is:which contains the awkward 13 letter word:
embarrassable
in it. TODO: proof that it is pendable?
Perhaps inspired by this, some people also decided to use Base58 addresses as a way to create more general unspendable inscriptions, even even though the method is much more clumsy and complicated than P2FKHS. There is however a certain art to working under limitations.
Figure 1. . Although it is not solely focused on inscriptions and may also contain functional burn addresses, it is likely that the methods of Khatib/Legout capture the overall trend of base58 inscription counts.
These messages were originally found with: github.com/cirosantilli/bitcoin-inscription-indexer#payload-size-out-utxo-2vals which tracks the largest transactions with unspent outputs.
Bitcoin Burn Addresses: Unveiling the Permanent Losses and Their Underlying Causes later revealed many new ones.
Finding Base58 messages is intrinsically hard for a few reasons
The interesting following transactions contain base58 encoded messages on addresses, sorted chronologically, and heighlighted either due to their earliness or historical or artistic quality:
Related:
Mt. Gox was the first Cryptocurrency exchange in existence, and when it shutdowon in Febrauary 2014 because the website was crap and they got hacked, some people were not happy at all about their missing funds!
tx 0540b5dda23ee870330c6b1e18a88c592cf8d847c47f1dc1d5328f46115b12b3 (2014-02-25)
2014-02-25: The day Mt.Gox shut down. Farewell, may even you rest in peace!
tx c00a4a04905a2e8d8dee8a768165aa6bdf842413a8a648462a6349db89cd77f2 (2014-02-27) has an ASCII art of a seal, TODO understand meme:
        o
      / |
      | \
  .   |  |
.'\`  | \|
  | \_/ \ \
  \____/\/
<3 You Seals!
There are also a few Base58 messages referring to Mt Gox, the nicest and most expensive one being to burn addres:which as of 2025 holds 0.014537 BTC burnt on:
Many of these transactions also contain other quick messages, e.g.:
Pali Canon by Ciro Santilli 40 Updated 2025-07-16
Anything that is not in the Pali Canon has basically zero chance of having come from Buddha or his immediate followers.
tipitaka.fandom.com/wiki/Puggala-Pannatti-Chap.2:
He who stores up whatever he gets and he who gives away whatever he gets - these two persons are hard to satisfy.

Pinned article: Introduction to the OurBigBook Project

Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
We have two killer features:
  1. topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculus
    Articles of different users are sorted by upvote within each article page. This feature is a bit like:
    • a Wikipedia where each user can have their own version of each article
    • a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
    This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
    Figure 1.
    Screenshot of the "Derivative" topic page
    . View it live at: ourbigbook.com/go/topic/derivative
  2. local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:
    This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
    Figure 2.
    You can publish local OurBigBook lightweight markup files to either https://OurBigBook.com or as a static website
    .
    Figure 3.
    Visual Studio Code extension installation
    .
    Figure 4.
    Visual Studio Code extension tree navigation
    .
    Figure 5.
    Web editor
    . You can also edit articles on the Web editor without installing anything locally.
    Video 3.
    Edit locally and publish demo
    . Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.
    Video 4.
    OurBigBook Visual Studio Code extension editing and navigation demo
    . Source.
  3. https://raw.githubusercontent.com/ourbigbook/ourbigbook-media/master/feature/x/hilbert-space-arrow.png
  4. Infinitely deep tables of contents:
    Figure 6.
    Dynamic article tree with infinitely deep table of contents
    .
    Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact