Quantum logic gate by Ciro Santilli 40 Updated 2025-07-16
At Section "Quantum computing is just matrix multiplication" we saw that making a quantum circuit actually comes down to designing one big unitary matrix.
We have to say though that that was a bit of a lie.
Quantum programmers normally don't just produce those big matrices manually from scratch.
Instead, they use quantum logic gates.
Some authors use the convention of:
They might have shut down, but they still have the cutest name! And they've made some cute inscriptions too, see: HHTT
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.
Micronation by Ciro Santilli 40 Updated 2025-07-16
Video 1.
How do you start a new country? by Jay Foreman (2021)
Source.
For a detailed analysis of one transaction see: Nelson-Mandela.jpg.
Best guess so far, all in ASCII hex of output scripts:
Ordinals are inscriptions created with the protocol described at: docs.ordinals.com/inscriptions.html The protocol was designed by developer Casey Rodarmor, and shares a few similarities with the AtomSea & EMBII protocol.
The protocol also includes a way to have ownership over inscriptions, effectively creating an NFT system on top of the bitcoin blockchain. AtomSea & EMBII also already had such a system however. In either case, Ciro Santilli couldn't give less of a fuck about who owns some random publicly viewable digital asset.
For whatever reason, orinals became extremelly popular compared to the AtomSea & EMBII format, leading to millions os inscriptions, and 10k+ images as of block 830k. They also started to take up a substatial portion of the available block space.
This in turn led to a lot of child porn rediscussion, and people linking back to this page to view earlier inscriptions: incoming links.
Unfortunately, unlike AtomSea & EMBII and even cryptograffiti.info uploads, most ordinals are designed to be just souless bulk collectibles, as with as much artistic merit as any random collectible card set or postage stamps you may find at a newpaper stall. To make things worse many of them are likely algorithmically generated. Eternal September had truly arrived to the Bitcoin blockchain. As a result, machine learning would be almost essential in order to find interesting uploads amidst such bulk.
The source code for the reference uploader and indexer is at: github.com/ordinals/ord
The reference viewer server for the runs at: ordinals.com.
The i0 at the end of the URL above means "inscription 0". This is because a single transaction can have multiple inscriptions.
Some of them have sold for high prices. Magic Eden is a popular interface for trading them:
The ordinals also started taking up large portions of the Bitcoin blockchain:
Apparently the "Taproot" Bitcoin update made it easier to upload image-sized data once again, which had become prohibitively expensive 2023 and much earlier:
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:

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