Ciro Santilli $$ Sponsor Ciro $$ 中国独裁统治 China Dictatorship 新疆改造中心、六四事件、法轮功、郝海东、709大抓捕、2015巴拿马文件 邓家贵、低端人口、西藏骚乱
The key difficulties of cryptocurrencies are:
Until those problems are solved, the only real applications of cryptocurrency will by illegal activities, notably buying drugs, paying for ransomware. But also paying for anti-censorship services from inside dictatorships. It is for this reason that Ciro Santilli believes that privacy coins are the best investments until then. People concerned with their privacy are likely to more naturally make fewer larger payments to reduce exposure, and therefore transaction fees matter less, and can be seen as a reasonable privacy tax. Also drugs are expensive, just have a look at any uncensored Onion service search engine, so individual transactions tend to be large.
If crypto really takes off, 99.99% of people will only ever use it through some cryptocurrency exchange (unless scalability problems are solved, and they replace fiat currencies entirely), so the experience will be very similar to PayPal, and without "true" decentralization.
For those reasons, Ciro Santilli instead believes that governments should issue electronic money, and maintain an open API that all can access instead. The centralized service will always be cheaper for society to maintain than any distributed service, and it will still allow for proper taxation.
Ciro believes that it is easy for people to be seduced by the idealistic promise that "cryptocurrency will make the world more fair and equal by giving everyone equal opportunities, away from the corruption of Governments". Such optimism that new technologies will solve certain key social problems without the need for constant government intervention and management is not new, as shown e.g. at HyperNormalisation by Adam Curtis (2016) when he talks about the cyberspace (when the Internet was just beginning): Technologies can make our lives better. But in general, some of them also have to be managed.
In any case, cryptocurrencies are bullshit, the true currency of the future is going to be Magic: The Gathering cards. And Cirocoin.
One closely related thing that Ciro Santilli does think could be interesting exploring right now however, notably when having Monero-like anonymity in mind, would be anonymous electronic voting.
TODO evaluate the possible application of cryptocurrency for international transfers:
Of course, the ideal solution would be for governments to just allow for people from other countries to create accounts in their country, and use the centralized API just like citizens. Having an account of some sort is of course fundamental to avoid money laundering/tax evasion, be it on the API, or when you are going to cash out the crypto into fiat. So then the question becomes: suppose that governments are shit and never make such APIs, are international transfers just because traditional banks are inneficient/greedy? Or is it because of the inevitable cost of auditing transfers? E.g. how does Transferwise compare to Bitcoin these days? And if cryptocurrency is more desirable, why wouldn't Transferwise just use it as their backend, and reach very similar fees?
Notable ones:
Official website:
Reference implementation: Bitcoin Core.
Here is a very direct description of the system:
  • each transaction (transaction is often abbreviated "tx") has a list of inputs, and a list of outputs
  • each input is the output of a previous transaction. You verify your identity as the indented receiver by producing a digital signature for the public key specified on the output
  • each output specifies the public key of the receiver and the value being sent
  • the sum of output values cannot obvious exceed the sum of input values. If it is any less, the leftover is sent to the miner of the transaction as a transaction fee, which is an incentive for mining.
  • once an output is used from an input, it becomes marked as spent, and cannot be reused again. Every input uses the selected output fully. Therefore, if you want to use an input of 1 BTC to pay 0.1 BTC, what you do is to send 0.1 BTC to the receiver, and 0.9 BTC back to yourself as change. This is why the vast majority of transactions has two outputs: one "real", and the other change back to self.
Code 1. "Sample Bitcoin transaction graph" illustrates these concepts:
  • tx0: magic transaction without any inputs, i.e. either Genesis block or a coinbase mining reward. Since it is a magic transaction, it produces 3 Bitcoins from scratch: 1 in out0 and 2 in out1
  • tx1: regular transaction that takes:
    • a single input from tx0 out0, with value 1
    • produces two outputs:
      • out0 for value 0.5
      • out1 for value 0.3
    • this means that there was 0.2 left over from the input. This value will be given to the miner that mines this transaction.
    Since this is a regular transaction, no new coins are produced.
  • tx2: regular transaction with a single input and a single output. It uses up the entire input, leading to 0 miner fees, so this greedy one might (will?) never get mined.
  • tx3: regular transaction with two inputs and one output. The total input is 2.3, and the output is 1.8, so the miner fee will be 0.5
Code 1. Sample Bitcoin transaction graph.
                   tx1                     tx3
  tx0            +---------------+       +---------------+
+----------+     | in0           |       | in0           |
| out0     |<------out: tx0 out0 |  +------out: tx1 out1 |
| value: 1 |     +---------------+  |    +---------------+
+----------+     | out0          |  |    | in1           |
| out1     |<-+  | value: 0.5    |  | +----out: tx2 out0 |
| value: 2 |  |  +---------------+  | |  +---------------+
+----------+  |  | out1          |<-+ |  | out1          |
              |  | value: 0.3    |    |  | value: 1.8    |
              |  +---------------+    |  +---------------+
              |                       |
              |                       |
              |                       |
              |    tx2                |
              |  +---------------+    |
              |  | in0           |    |
              +----out: tx0 out1 |    |
                 +---------------+    |
                 | out0          |<---+
                 | value: 2      |
Since every input must come from a previous output, there must be some magic way of generating new coins from scratch to bootstrap the system. This mechanism is that when the miner mines successfully, they get a mining fee, which is a magic transaction without any valid inputs and a pre-agreed value, and an incentive to use their power/compute resources to mine. This magic transaction is called a "coinbase transaction".
The key innovation of Bitcoin is how to prevent double spending, i.e. use a single output as the input of two different transactions, via mining.
For example, what prevents me from very quickly using a single output to pay two different people in quick succession?
The solution are the blocks. Blocks discretize transactions into chunks in a way that prevents double spending.
A block contains:
  • a list of transactions that are valid amongst themselves. Notably, there can't be double spending within a block.
    People making transactions send them to the network, and miners select which ones they want to add to their block. Miners prefer to pick transactions that are:
    • small, as less bytes means less hashing costs. Small generally means "doesn't have a gazillion inputs/outputs".
    • have higher transaction fees, for obvious reasons
  • the ID of its parent block. Blocks therefore form a linear linked list of blocks, except for temporary ties that are soon resolved. The longest known list block is considered to be the valid one.
  • a nonce, which is an integer chosen "arbitrarily by the miner"
For a block to be valid, besides not containing easy to check stuff like double spending, the miner must also select a nonce such that the hash of the block starts with N zeroes.
For example, considering the transactions from Code 1. "Sample Bitcoin transaction graph", the block structure shown at Code 2. "Sample Bitcoin blockchain" would be valid. In it block0 contains two transactions: tx0 and tx1, and block1 also contains two transactions: tx2 and tx3.
Code 2. Sample Bitcoin blockchain.
 block0           block1             block2
+------------+   +--------------+   +--------------+
| prev:      |<----prev: block0 |<----prev: block1 |
+------------+   +--------------+   +--------------+
| txs:       |   | txs:         |   | txs:         |
| - tx0      |   | - tx2        |   | - tx4        |
| - tx1      |   | - tx3        |   | - tx5        |
+------------+   +--------------+   +--------------+
| nonce: 944 |   | nonce: 832   |   | nonce: 734   |
+------------+   +--------------+   +--------------+
The nonces are on this example arbitrary chosen numbers that would lead to a desired hash for the block.
block0 is the Genesis block, which is magic and does not have a previous block, because we have to start from somewhere. The network is hardcoded to accept that as a valid starting point.
Now suppose that the person who created tx2 had tried to double spend and also created another transaction tx2' at the same time that looks like this:
| in0           |
| out: tx0 out1 |
| out0          |
| value: 2      |
Clearly, this transaction would try to spend tx0 out1 one more time in addition to tx2, and should not be allowed! If this were attempted, only the following outcomes are possible:
  • block1 contains tx2. Then when block2 gets made, it cannot contain tx2', because tx0 out1 was already spent by tx2
  • block1 contains tx2'. tx2 cannot be spent anymore
Notably, it is not possible that block1 contains both tx2 and tx2', as that would make the block invalid, and the network would not accept that block even if a miner found a nonce.
Since hashes are basically random, miners just have to try a bunch of nonces randomly until they find one that works.
The more zeroes, the harder it is to find the hash. For example, on the extreme case where N is all the bits of the hash output, we are trying to find a hash of exactly 0, which is statistically impossible. But if e.g. N=1, you will in average have to try only two nonces, N=2 four nonces, and so on.
The value N is updated every 2 weeks, and aims to make blocks to take 10 minutes to mine on average. N has to be increased with time, as more advanced hashing hardware has become available.
Once a miner finds a nonce that works, they send their block to the network. Other miners then verify the block, and once they do, they are highly incentivized to stop their hashing attempts, and make the new valid block be the new parent, and start over. This is because the length of the chain has already increased: they would need to mine two blocks instead of one if they didn't update to the newest block!
Therefore if you try to double spend, some random miner is going to select only one of your transactions and add it to the block.
They can't pick both, otherwise their block would be invalid, and other miners wouldn't accept is as the new longest one.
Then sooner or later, the transaction will be mined and added to the longest chain. At this point, the network will move to that newer header, and your second transaction will not be valid for any miner at all anymore, since it uses a spent output from the first one that went in. All miners will therefore drop that transaction, and it will never go in.
The goal of having this mandatory 10 minutes block interval is to make it very unlikely that two miners will mine at the exact same time, and therefore possibly each one mine one of the two double spending transactions. When ties to happen, miners randomly choose one of the valid blocks and work on top of it. The first one that does, now has a block of length L + 2 rather than L + 1, and therefore when that is propagated, everyone drops what they are doing and move to that new longest one. domain registration: 2008-08-18 by, an American company. But using a privacy oriented registrar: It is unknown how he could have paid anonymously, so it seems likely that the true identity could be obtained by law enforcement if needed.
2008-08-22: private Wei Dai email. Reproduced at on from address Email provider shutting down entirely on 2021-09-30 as per, homepage now juts contains useless Bitcoin stuff.
Bitcoin whitepaper announcement: 2008-10-31 linking to, email sent from from Claimed one year and a half development time. Provider apparently closed in 2014:, as of 2021 just reads:
Once upon a time a man paid me a visit in cyberspace, at this very domain. He planted a seed in our heads that would become the path we are walking today.
Replies in November: under claims source code shared privately by request at that point.
First open source release: 9 January 2009. Announcement: "Windows only for now. Open source C++ code is included" Arghhhhhh how can those libertarians use Microsoft Windows??? Had a GUI already.
2011-04-23 Satoshi sent his last email ever, it was to Martti Malmi. mentions:
May 2011 was also the last time Satoshi communicated privately with other Bitcoin contributors. In an email that month to Martti Malmi, one of the earliest participants, Satoshi wrote, "I've moved on to other things and probably won't be around in the future."
Hal Finney:
Released by Satoshi Nakamoto on the early mailing list discussions where Bitcoin was announced.
More conveniently available at: nowadays.
Interesting ones:
  • 77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69 0 OP_IF OP_INVALIDOPCODE None None OP_ENDIF. The second constant contains an ASCII patch Remove (SINGLE|DOUBLE)BYTE so presumably this is a proof of concept.
+ duscusses what happens if there is an invalid opcode in a branch that is not taken. + Discussed at:
  • 4373b97e4525be4c2f4b491be9f14ac2b106ba521587dad8f134040d16ff73af 0 OP_ADD OP_ADD None OP_EQUAL OP_NOTIF OP_RETURN OP_ENDIF OP_FROMALTSTACK None OP_DROP is provably unspendable because it always falls on OP_FROMALTSTACK but nothing is ever placed in the ALTSTACK
They appear to be included, with rationale that you can already include syntactically valid crap in an unprovable way: 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:, 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.
Reference implementation?
Executables provided:
  • bitcoin-qt
There are apparently two methods:
Specific implementations:
TODO: it would be cool to have something like but including the actual transactions:
TODO who owns it? Are they reliable?
This helper dumps a transaction JSON to a binary:
bitcoin-tx-out-scripts() (
    # Dump data contained in out scripts. Remove first 3 last 2 bytes of
    # standard transaction boilerplate.
    echo curl "${h}?format=json" |
    jq '.out[].script' tmp.json |
    sed 's/"76a914//;s/88ac"//' |
    xxd -r -p > "${h}.bin"
Set of scripts b Ciro Santilli, primarily created while researching Cool data embedded in the Bitcoin blockchain. has all strings -n20 strings, we can obtain the whole thing and clean it up a bit with:
wget -O all.html
cp all.html all-recode.html
recode html..ascii all-recode.html
awk '!seen[$0]++' all-recode.html > all-uniq.html
awk to skip the gazillion "mined by message" repeats.
A lot of in that website stuff appears to be cut up at the 20 mark. As shown in Force of Will, this is possibly because they didn't use -w in strings -n20, and the text after the newlines was less than 20 characters.
That website can be replicated by downloading the Bitcoin blockchain locally, then:
cd .bitcoin/blocks
for f in blk*.dat; do strings -n20 -w $f | awk '!seen[$0]++' > ${f%.dat}.txt; done
tail +n1 *.txt
Remove most of the binary crap:
head -n-1 *.txt | grep -e '[. ]' | grep -iv 'mined by' | less
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 without the need for a full local node can be found at: by using the --satoshi option. E.g. with it you can download the uploader script with:
./ --satoshi 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17
mv 4b72a223007eab8a951d43edc171befeabc7b5dca4213770c88e09ba5b936e17.bin
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 has a OP_1, data, OP_3, OP_CHECKMULTISIG pattern on every output script, so the OP_1 and OP_3 are ignored
  • 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:
we run:
git clone git://
git -C python-bitcoinrpc checkout cdf43b41f982b4f811cd4ebfbc787ab2abf5c94a
pip install python-bitcoinrpc==1.0
BTCRPCURL=http://asdf:qwer@ \
  PYTHONPATH="$(pwd)/python-bitcoinrpc:$PYTHONPATH" \
  python3 \
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.
tx 243dea31863e94dc2f293489db02452e9bde279df1ab7feb6e456a4af672156a contains another upload script. The help reads:
Publish text in the blockchain, suitably padded for easy recovery with strings
This is likely a system that uploads text to the blockchain.
One example can be seen on the marijuana plant.
Messages are uploaded one line per transaction, and thus may be cut up on the blk.txt, and possibly even out of order.
But because each line starts with j( you can generally piece things up regardless.
TODO identify. The first occurrence seems to be in tx e8c61e29c6b829e289f8d0fc95f9eb2eb00c89c85cfa3a9c700b15805451ae6a:
Claims provably fair. clarifies what that means: they prove fairness by releasing a hash of the seed before the bets, and the actual seed after the bets.
As mentioned in, it functions basically as cryptocurrency tumbler in practice. contains some comments on the data.
From that page we manually extract the hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f and then:
wget -O 0.hex
xxd -p -r 0.hex
and that does contain the famous genesis block string:
EThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks
The JSON clarifies that the data is encoded in the script field of the transaction input:
The extra E (0x45 in ASCII) in EThe Times is just extra noise required by the script, we can break things up as:
04ffff001d0104 45 5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73
  • 54 is T
  • the 04ffff001d0104 part just doesn't show up on the terminal because it is not made of any printable characters.
The initial 04 is OP_RETURN
TODO what is actual the meaning of the ffff001d010445 part?
TODO the output of the transaction has a jumbled script, likely just a regular output to get things going, can't be arbitrary like input.
The message proves a minimal starting date for the first mine.
And it hints that one of Bitcoin's motivation was the financial crisis of 2007-2008, where banks were given bailouts by the government to not go under, which many people opposed as the crisis was their own fault in the first place.
A notable related stab is taken at len Sassaman tribute.
This was getting very hot as of 2022 for some reason. Would be good to understand why besides the awesome name.
Cryptocurrency with focus on anonymity.
As mentioned at Section "Cryptocurrency", Ciro Santilli believes that anonymity is the only feature that really matters on crypto coins, and therefore if he were to invest in crypto, he would invest in Monero or some other privacy coin. gives an overview of the privacy mechanisms:
  • ring signatures, which hide the true output (sender) Gives an overview. Mentions that it is prone to heuristic attacks.
    Uses a system of decoys, that adds 10 fake possible previous outputs as inputs, in addition to the actual input.
    So the network only knows/verifies that one of those 11 previous outputs was used, but it does not know which one.
    It's a bit like having a built-in cryptocurrency tumbler in every transaction.
    TODO so how do you know which previous outputs were spent or not?
  • RingCT which hides the amounts.
  • stealth addresses, which hides who you send to
    This forces receivers to scan try and unlock every single transaction in the chain to see if it is theirs or not.
    The sender therefore can know when the money is spent, but once again, not to whom it is being sent.
Coinbase has actually stayed away from trading it even as of 2019 when Monero was the third largest market capitalization crypto because of fear of regulatory slashback: Although it must be said, the value of privacy crypto is greatly reduced when everyone is trading it on exchanges, which require a passport upload to work.
Ubuntu 20.10 as per
sudo apt install git build-essential cmake libuv1-dev libssl-dev libhwloc-dev
git clone
mkdir xmrig/build && cd xmrig/build
cmake ..
make -j$(nproc)
At we see that all you then need is a single CLI command:
xmrig -o -u <your-monero-address>
Seems simple, well done devs!
Benchmark on Lenovo ThinkPad P51 (2017) as per
./xmrig --bench=1M
948.1 h/s
which according to the mining pool would generate 0.0005 XMR/day, which at the February 2021 rate of 140 USD/XMR is 0.07 USD/day. The minimum payout in that pool is 0.004 XMR so it would take 8 days to reach that.
So clearly, application-specific integrated circuit mining is the only viable way of doing this.