I've been working on a numbering scheme for satoshis that allows tracking and transferring individual sats. These numbers are called ordinals, and constitute a numeric namespace for Bitcoin. 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.
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 the same 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.