I've been working on a numbering scheme for satoshis that allows tracking and transferring
individual sats. These numbers are called ordinals. Satoshis
are numbered in the order in which they're mined, and transferred from transaction inputs to
transaction outputs in first-in-first-out order. More details are available in the BIP.
Ordinals don't require a separate token, another blockchain, or any changes to Bitcoin. They
work right now.
Ordinals can be represented in a few ways:
With raw notation, like so 1905530482684727°. The number is the ordinal number, and the "°"
is the Romance language ordinal symbol.
With decimal notation, like so 738848.482684727°. The first number is the block height, and
the second is the index of the ordinal within the block.
With degree notation, like so 0°108848′992″482684727‴. We'll get to that in a moment.
Here's a link to an index that returns the ordinal ranges contained within a particular
Bitcoin UTXO. If it returns null, that means the UTXO has been spent, so try
another.
Arbitrary assets, such as NFTs, security tokens, accounts, or stablecoins can be attached to
Ordinals.
Ordinals is an open-source project, developed on
GitHub. The project consists of a BIP describing the ordinal scheme, an index that
communicates with a Bitcoin Core node to track the location of all ordinals, a wallet that
allows making ordinal-aware transactions, a block explorer for interactive exploration of the
blockchain, and functionality for minting ordinal NFTs.
Rarity
Since ordinals can be tracked and transferred, people will naturally want to collect them.
Ordinal theorists can decide for themselves which sats are rare and desirable, but I wanted to
provide some hints.
Bitcoin has periodic events, some frequent, some more uncommon, and these naturally lend
themselves to a system of rarity. These periodic events are:
Blocks: A new block is mined approximately every 10 minutes, from now until the
end of time.
Difficulty adjustments: Every 2016 blocks, or approximately every two weeks, the
Bitcoin network responds to changes in hashrate by adjusting the difficulty target which
blocks must meet in order to be accepted.
Halvings: Every 210,000 blocks, or roughly every four years, the amount of new
sats created in every block is cut in half.
Cycles: Every six halvings, something magical happens: the halving and the
difficulty adjustment coincide. This is called a conjunction, and the time period between
conjunctions a cycle. A conjunction occurs roughly every 24 years. The first conjunction
should happen some time in 2032.
This gives us the following rarity levels:
common: Any sat that is not the first sat of its block
uncommon: The first sat of each block
rare: The first sat of each difficulty adjustment period
epic: The first sat of each halving epoch
legendary: The first sat of each cycle
mythic: The first sat of the genesis block
Which brings us to degree notation, which unambiguously represents an ordinal in a way that
makes rarity easy to see at a glance:
A°B′C″D‴
│ │ │ ╰─ Index of sat in the block
│ │ ╰─── Index of block in difficulty adjustment period
│ ╰───── Index of block in halving epoch
╰─────── Cycle, numbered starting from 0
Ordinal theorists often use the terms "hour", "minute", "second", and "third" for
A, B, C, and D, respectively.
Now for some examples. This ordinal is common:
1°1′1″1‴
│ │ │ ╰─ Not first sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle
This ordinal is uncommon:
1°1′1″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle
This ordinal is rare:
1°1′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── Not the first block in halving epoch
╰─────── Second cycle
This ordinal is epic:
1°0′1″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle
This ordinal is legendary:
1°0′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle
And this ordinal is mythic:
0°0′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── First cycle
If the block offset is zero, it may be omitted. This is the uncommon ordinal from above:
1°1′1″
│ │ ╰─ Not first block in difficutly adjustment period
│ ╰─── Not first block in halving epoch
╰───── Second cycle
Supply
Total Supply
common: 2.1 quadrillion
uncommon: 6,929,999
rare: 3437
epic: 32
legendary: 5
mythic: 1
Current Supply
common: 1.9 quadrillion
uncommon: 745,855
rare: 369
epic: 3
legendary: 0
mythic: 1
At the moment, even uncommon ordinals are quite rare. As of this writing, 745,855 uncommon
ordinals have been mined - one per 25.6 bitcoin in circulation.
Names
Each ordinal has a name, consisting of the letters A through Z, that get
shorter the larger the ordinal is. They could start short and get longer, but then all the
good, short names would be trapped in the unspendable genesis block.
As an example, 1905530482684727°'s name is "iaiufjszmoba". The name of the last ordinal to
be mined is "a". Every combination of 10 characters or less is out there, or will be out there,
some day.
Exotics
Ordinals may be prized for reasons other than their name or rarity. This might be due to a
quality of the number itself, like having an integer square or cube root. Or it might be due to
a connection to a historical event, such as ordinals from block 477,120, the block in which
SegWit activated, or ordinal 2099999997689999°, the last ordinal that will ever be mined.
Such ordinals are termed "exotic". Which ordinals are exotic and what makes them so is
subjective. Ordinal theorists are are encouraged to seek out exotics based on criteria of their
own devising.
A commonly accepted cut-off for early NFTs is March 19th, 2018, the date the first ERC-721
contract, SU SQUARES, was deployed on Ethereum.
Whether or not ordinals are of interest to NFT archaeologists is an open question! In one
sense, ordinals were created in early 2022, when I finalized the Ordinals specification. In
this sense, they are not of historical interest.
In another sense though, ordinals were in fact created by Satoshi Nakamoto in 2009 when he
mined the Bitcoin genesis block. In this sense, ordinals, and especially early ordinals, are
certainly of historical interest.
I personally favor the latter view. This is not least because the ordinals were
independently discovered on at least two separate occasions, long before the era of modern NFTs
began.
On October 8th, 2012, jl2012 posted a scheme to the Bitcoin Talk
forum which uses decimal notation and has all the important properties of ordinals. The
scheme was discussed but never implemented.
These independent inventions of ordinals indicate in some way that ordinals were discovered,
or rediscovered, and not invented. The ordinals are an inevitability of the mathematics of
Bitcoin, stemming not from their modern documentation, but from their ancient genesis. They are
the culmination of a sequence of events set in motion with the mining of the first block, so
many years ago.
There are a lot of things that I wish would happen, but don't have the time to actually do
myself. I complain about such things all the time to basically anyone who will listen. Such
efforts are all well and good, and sometimes actually pay off, but additionally, I'd like to
materially support people who might actually do these things.
This post, which I'll try to keep up-to-date, if I remember, documents the projects which I
wish some talented go-getter would take on, and in which I would invest money in if given the
opportunity.
If you are one of these aforementioned go-getters, email
me!
Email-based messaging: The only reason we use anything but email to communicate is
because email is missing features that could easily be added. Deliver us from
multi-messaging app hell!
RSS-based social networking: RSS could easily serve as the basis for standards-based
social networking, and would be useful even without taking a significant market share.
Bitcoin-based NFTs: NFTs are getting lots of creative people both excited and paid. Let
them suckle at mama Bitcoin's sweet and bountiful bosem instead of Ethereum's shrivled,
insecure, bitter, centralized tit. This can't be done on the Bitcoin L1, so should be
pursued as an L2. The key here is figuring out how to avoid needing a new token.
Bitcoin-based smart contracts: Much like the NFT item above. Let the degens feast at the
Bitcoin board, not at the Ethereum kiddy table. Must avoid needing a new token. The best
path forward is to fork Liquid, add smart contract functionality to Elements, and run it as
Bitcoin-pegged federation.
Self-hosted block game: There should be a Minecraft-like game that can be programmed and
modded from within the game.
Expanding on this
tweet: You could launch a super fancy social networking site with all the features that
everyone expects, but built entirely on existing open standards:
Sign-up: Pick a domain. This is your username. Register domain through service. Can be
transferred out at any time. $10 a year is nothing.
Profile: Hosted at domain.tld.
Messaging: Email at whatever@domain.tld. User can use whatever email app
they want.
Social Graph: Contacts via CardDAV.
Authentication: Done with Oath.
Permission System: Entirely done with contacts. First pass filtering is done with spam
filter. Email from non-contacts goes to message requests folder. Contacts can be marked using
CardDAV groups and fields as "friends", which enables bypassing spam filter and seeing
private items.
Feed: RSS at https://username.com/feed.xml. Private items require
authentication. Include email address in RSS metadata, and comment via email.
Return email to its rightful place as the one true messaging protocol. It's this or use a
dozen messaging apps for the rest of your life, there is no other realistic option.
How?
Add the features that make people use other messaging protocols to email.
Which features?
Contacts
Description: Chat, mobile notifications, read receipts, and other features, should not be
available to arbitrary addresses. User approves addresses who can use these features.
Implementation: Add-to-contacts UI in client.
Degredation: N/A.
Chat
Description: Dedicated chat UI. No subject line. Return to send.
Implementation: Add dedicated chat UI to client. Messages sent from chat UI have header
chat: true. Messages received with chat: true are shown in chat UI.
Only chat from contacts appear in chat UI. Chat from non-contacts appears in message request
UI.
Degradation: Message desplayed in inbox UI.
Mobile Notifications
Description: Some messages trigger mobile notification. User configurable.
Implementation: Mobile app has notification category for mail from contacts with header
urgent: true.
Degradation: No mobile notification.
Read Receipts and Typing Indicators
Description: See read receipts and typing indicators on sent mail.
Implementation: Add receipt-endpoint: <URL> header to outgoing mail.
Display read receipts and typing indicators sent to own receipt-endpoint. Only
send read receipts and typing indicators to contacts.
Degredation: No read receipts or typing indicators.
Voice Calling
Description: Initiate voice calls from within client.
Implementation: Query MX server for voice call endpoint. Display voice call button next to
conversations where MX server supports voice calls.
Degredation: No voice call button displayed when not supported.
Video Calling
Same as voice calling.
Message Requests
Description: Email from arbitrary senders should go into a message request folder, instead
of in the inbox, to prevent phishing attacks, and encourage users to whitelist contacts which
enables richer features.
Implementation: Email from senders who are not contacts goes into message request folder.
Message request folder is distinct from spam folder.
Degredation: Email appears in main inbox.
Emoji
Description: Mail consisting of a small number of emoji is displayed in a larger font.
Implementation: Display mail consisting of a small number of emoji in a larger font.
Degredation: Emoji appear smol and sad.
Stickers
Description: Users can send "stickers" which are scaled appropriately.
Implementation: Display mail consisting of a single image scaled to UI.
Degredation: Images appear at fixed size.
Improved Rich Text Support
Description: Allow rich formatting without breaking plain text readers or using arbitrary
HTML.
Implementation: Messages can indicate that they are formatted as markdown. Format messages
for graphical clients and display with added line-breaks for plain text readers.
Degredation: Messages appear as plain text markdown, which is highly readable.
End-to-end Encryption
Description: Messages between users are end-to-end encrypted to avoid being read by third
parties.
Implementation: Query MX server for public key of receipient, encrypt mail for recipient
with pubkey.
Degredation: Messages are not encrypted. This is strict improvement to not encrypting any
email. Once email E2EE is widespread enough, refuse to send mail to recipients that don't
support it.
Prevent Replies Leaking Information
Description: Including messages in replies bloats messages, can accidentally leak
information, and has is not necessary due to threaded clients.
Implementation: Don't include original message in reply by default. User may use dedicated
quote reply UI to include quotes of original message.
Degredation: None.
Faster Message Delivery
Description: Deliver email instantly without any delay.
Implementation: Define mapping of email symantics over HTTP/3 as email/2, providing
persistant connections and an efficient binary encoding. Query MX server email/2 support and
use it if available, using persistant connections and binary encoding for instant message
delivery.
Degredation: Messages are delivered at normal speed.
Disappearing Messages
Description: Messages can be configured to dissappear after some amount of time.
Implementation: Query if recipient MX server supports disappearing messages. If so, let
sender set amount of time before messages disappear. Enforced by recipient, not sender, since
sender enforcement is impossible.
Degredation: Option to turn on disappearing messages is not available when not supported by
recipient.
Group Chats
Description: It should be possible to easily add and remove addresses from group chats.
Implementation: Email already supports group emails, but configuring adding and removing
addresses from group chats is difficult. Query MX server for group chat support endpoint.
Dedicated API for creating and updating group chats, referenced by ID. Group chat emails are
associated with ID, instead of just being arbitrary lists of addresses, allowing any
participant, if they have the permissions, to add and remove members from chat.
Degredation: Group chats are received as ordinary multi-address emails.
A letter to Maalika Manoharan, Product Manager, Gmail. Sent via LinkedIn Inmail, which
is palpably ironic.
Hi Maalika,
My name is Casey Rodarmor, and I am a former Google SRE and SWE.
I am writing you today because you may be one of the few people that can deliver us from the
multi-messenger hell that the human race finds itself in today. Everyone needs to use six or
more messaging apps, and everyone hates it.
However, there is an easy way out of this. Email is a federated, decentralized,
standards-based messaging platform that everyone already uses. The only reason people use other
messaging protocols is because those messaging protocols have features that email doesn't
have.
Here is the path to email world domination. It is very simple:
Add the features that email is missing, one by one, in a backwards compatible way.
These features include:
Chat messages with low UI overhead and no subject line
Group chats
Read receipts
Voice calling
Video calling
Typing indicators
Message requests
Stickers
Better rich text support
End-to-end encryption
Faster message delivery
Pay money for guaranteed delivery
These features can all be implemented in backwards compatible ways that gracefully degrade
when they aren't supported.
These features should be designed and implemented in an open process, involving the internet
community, public RFCs, and implementations by multiple clients and service providers.
This is a major undertaking, but the benefit is huge, both for Google, Gmail, and the
internet community.
Every single non-email protocol will fall by the wayside, and we can return to a simpler,
more productive, and more secure world, one where everyone just uses email to communicate, an
open, standards-based, internet native protocol.
This could be, without exaggeration, the most important work of your life.
Do you have time to discuss this with me? I have no agenda, just someone who thinks that
this is possible, and ultimately very achievable.
Federated blind mints have attractive privacy, scaling, and security properties that are
highly complementary to those of Bitcoin and the Lightning Network.
I originally became interested in blind mints while thinking about Lightning Network wallet
usability issues. When Lightning works, it is fantastic, but keeping a node running and
managing a wallet present a number of challenges, such as channel unavailability due to force
closes, the unpredictability of the on-chain fee environment, the complexity of channel backup,
and the involved and often subtle need to manage liquidity.
All of these problems are tractable for a skilled node operator, but may not be
soluble in the context of self-hosted wallets operated by non-technical users, hereafter
normies. If this is the case, then normies may have no choice but to use hosted
Lightning wallets, compromising their privacy and exposing them to custodial risk.
Chaumian mints, also known as Chaumian banks, or blind mints, offer a compelling solution to
these problems, particularly when operation is federated. Chaumian mints, through the use of
blind signatures, have extremely
appealing privacy properties. The mint operators do not know the number of users, their
identities, account balances, or transaction histories. Additionally, mint transactions are
cheap and can be performed at unlimited scale.
Mint implementations, typified by eCash,
have hitherto been centralized, and thus, like all centralized, custodial services, expose
users to custodial risk in the form of operator absquatulation and mismanagement. To fix this,
mint operation can be federated, with all operations performed by a quorum of nodes controlled
by different parties.
Despite these interesting properties, Chaumian mints have largely been forgotten. This
post gives an excellent overview of the
phenomenon. I believe that Chaumian mints are currently severely underrated in general, and in
particular deserve consideration as a potential avenue for improving custodial Lightning
Network wallets.
Compared to a naïve hosted Lightning Network wallet, a service operated as a federated
Chaumian mint offers excellent privacy, usability, security, and scaling.
Privacy: Privacy leaks from a Lightning mint come in two forms,
internal and external, when a mint operator or an outside actor,
respectively, observes sensitive information.
Blind signatures protect against internal privacy leaks, making them a strict improvement in
that respect over custodial Lightning wallets.
When compared to a single-user Lightning network wallet, Lightning mints also protect
against external privacy leaks. If the activity of a single-user Lightning Network wallet can
be observed, which is possible but non-trivial, all such activity is preemptively that of the
owner of the wallet. However, similar to a standard custodial Lightning Network wallet, any
observable Lightning Network activity of a Lightning mint is the aggregate activity of its
users, who thus form an anonymity set. If the number of users, and thus the anonymity set size,
is large, external privacy leaks are also prevented.
Usability: Compared to a self-managed Lightning Network wallet, and similar
to a standard custodial Lightning Network wallet, Lightning mint wallets offer superior
usability. A user need not be concerned with the details of node operation or channel
management, and can deposit to and withdraw from their account with standard Lightning Network
invoices.
Security: The security of a Lightning mint is weaker than that of a
self-hosted wallet. A quorum of federation members can abscond with funds. However, compared to
a standard custodial Lightning Network wallet, security is greatly improved. Additionally,
federation members might be located in different jurisdictions, making the mint robust to
regulatory interference. Furthermore, members might be entities with online reputations, such
as anonymous Bitcoin Twitter users with an established history of productive shitposting,
providing further assurances against mismanagement and fraud.
Scaling: Mint operations are extremely lightweight, similar to Lightning
Network transactions, so scaling properties are similar to the Lightning Network itself.
Additionally, users need not manage their own channels, so a well-capitalized federation can
open channels efficiently, lowering the per-transaction channel management overhead.
Interoperability and market dynamics: Additionally, my hope is that such
systems will be developed with a standardized protocol for communication between wallet
interfaces and mint backends. This would allow users to use different backends with the same
local wallet interface, encouraging competition in the market.
For more discussion of Chaumian mints and their applicability to Bitcoin, see fedimint.org. Elsirion, the author, is also at work on MiniMint, a
federated Chaumian mint with Bitcoin and eventually Lightning Network support.
To close with a bit of speculation, I believe that Chaumian mints were never of particular
interest or importance because they were limited to interoperating with the fiat currencies of
the time. With the ascendance of Bitcoin, mints now have access to a powerful, decentralized,
and uncensorable currency , made economical and fast by the Lightning Network.
I believe this layering of Chaumian mints on top of Bitcoin and the Lightning Network will,
in the fullness of time, be demonstrated to be enormously powerful, and make Chaumian mints
themselves worthy of renewed study and consideration.
I was trying to find an image reference for what different clipper guard lengths look like.
Every single reference I found had different models with different hairstyles, or used
illustrations instead of photographs.
After searching a bit, I found this video, which shows the same person with different hair
lengths, with the hair uniformly short over the whole head.
I think it's quite interesting that a random YouTuber may have created a best-in-the-world
reference, even if it's for something as mundane as haircut lengths.
I feel like BGP would be a great place to experiment with PKI systems, possibly with some
additional global consensus mechanism.
BGP has well known security flaws that cause real problems. It is very common that
misconfigured or malicious route advertisements cause outages or redirect traffic to an
attacker. (C.f. BGP hijacking against Bitcoin miners.)
Some kind of PKI system which let AS operators associate one or more public keys with
their AS, and handled transfers of IP space between ASs, would allow BGP updates to be
signed by the AS owner's key and totally eliminate this class of vulnerability.
Additionally, it would allow ASs to end-to-end encrypt and authenticate BGP
communications. BGP updates aren't exactly sensitive, but why not, ya know?
There are around 60,000 ASs in existence, so a modest 7 tx/second message rate would be
enough to process an update to each one 10 times every day. If the purpose of the network
were just to handle public key updates, likely only a small fraction of this would be
needed for routine and emergency key updates.
There are 837,482 IP prefixes, so these could be turned over once every 1.5 days or so.
IP blocks move relatively infrequently, like AS keys would, so this is probably
AS operators are usually well funded, and have ready access to compute, network,
rackspace, and skilled humans. If running some kind of box with not-totally-crazy resource
and maintenance requirements marginally increased their security, they would all do it.
AS operators have a high degree of control over their network peering relationships, and
many large networks have direct physical connections to multiple other ASs. This mitigates
the risk of partitioning and starvation attacks somewhat.
There is a high degree of cooperation, goodwill, and existing relationships between AS
operators. This makes me wonder if schemes that I usually see as not fit for use in
cryptocurrency contexts, like Ripple-style consensus systems, might actually work in the AS
context. Ripple has no credible mechanism to deal with consensus failure if network
operators disagree on the state of the network, and there are many incentives that might
cause Ripple network operators to disagree on network state. However, in the AS context,
there is little reason for network operators to disagree, and they are highly motivated to
such disagreements out of band.
Maybe no global consensus mechanism is necessary, and some kind of simple PKI would be
good enough! However, it would be very nice if the current network consensus could be
summed up in a small amount of data , such that it would be easy and low-bandwidth to
discover if you were out of sync with the network, or being partitioned in the case of
single-homed networks.
Twitter is funding a team
to decentralize social media. I think they should start with messaging.
TL;DR
Why
Messaging is a subset of social media.
Users are tired of the wild proliferation of messaging apps.
Social networks are all different, making them hard targets for standardization;
messaging apps are all the same, making them easy targets for standardization and
interoperability.
Messaging is easier to scale.
How
Build on the matrix protocol.
Extend email.
Or maybe both.
Update: I no longer believe Matrix is fit for use.