Light Pools
bitcoin · cryptocurrency · markets

Bitcoin has inscriptions and will soon have runes, protocols for bitcoin-native digital artifacts and tokens.

However, these assets still suffer from a lack of decentralized trading venues.

Assets on other chains are commonly traded using automatic market makers, or AMMs. AMMs pool assets and use simple formulae to dynamically price swaps between assets.

They are efficient from an on-chain transaction cost perspective, but they are still on-chain, requiring additional transaction overhead compared to that required for the swaps themselves.

They also produce inefficient prices, since AMM prices can only change as a result of on-chain activities: deposits, withdrawals, and executions, which are costly.

Bitcoin lacks the Turing-complete smart contracts necessary for implementing AMMs. Fortunately, there is an alternative which is more efficient, both from a transaction cost and pricing perspective.

The idea behind light pools is simple. Users who wish to offer swaps between Bitcoin-native assets, like rare sats, inscriptions, or runes, run nodes which quote prices for swaps.

These quotes are signed messages, gossiped between other light pool nodes. Quotes must include BIP-322 signatures of the UTXOs that contains the asset offered in trade. Requiring signed quotes eliminates spam, since quotes can be rate-limited on a per-UTXO basis. Additionally, when UTXOs are spent, corresponding offers can be dropped.

When a market taker wants to accept the quote of a market maker, they use the information in the quote to construct a PSBT which includes their signatures, and broadcast it to the network. These messages can also be gossiped by the network, and rate-limited based on the taker's UTXOs. The maker receives this message, possibly asyncronously, countersigns, and broadcasts it to the Bitcoin network to be mined.

These PSBTs and transactions are not vulnerable to mempool sniping, since signatures commit to all inputs and outputs.

Light pools require more implementation work than an AMM. Someone will need to write an implementation of the gossip network, quote message format, and PSBT construction and finalization. However, these are all done with a little bit of elbow grease, and don't require tilting at the quixotic open-research-problem windmills that plague much of cryptocurrency. (And Bitcoin, to be fair.)

The user experience of light pools should be quite good. Users can run their own node to accumulate an order book, or rely on a third party. Prices can update in real time, between blocks, without any on-chain activity.

Little work has been done on decentralized asset trading on Bitcoin, simply because the market cap of Bitcoin-native assets was small. With rare sats, inscriptions, and soon runes, the table is set and the time is ripe, and light pools seem like a promising avenue to explore.

Inscriptions: A Guide for the Ideological Maxi
bitcoin · ordinals · shitpost

If you ask me my views, they will be nearly indistinguishable from those of, for lack of a better term, ideological Bitcoin maximalists. I loathe the state, have no particular respect for authority, and believe that Bitcoin is the path away from the debauched debasement of our lives and civilization that fiat currency has wrought.

However, I do not consider myself an ideological Bitcoin maximalist, with the primary reason being that ideology often does not survive contact with reality.

This is the unenviable position that ideological Bitcoin maximalism, and the insipid culture accompanying it, finds itself in at the present moment: an uncomfortable contact with a reality with which it does not comport.

Ideological Bitcoin maximalism has a lot of good things going for it. It is because of those things that this blog post was written. This post contains advice for ideological Bitcoin maximalists, advice which will hopefully help them stop scoring own goals and committing unforced errors. In other words, how they can stop being losers.

Let me start by saying that this post is not written to defend ordinals and inscriptions. They do not need defending. The cat is out the bag, and nobody can put it back in.

Now, for the advice.

My first piece of advice is that whining about inscriptions makes you, and Bitcoin, look weak. Simultaneously believing that Bitcoin is unstoppable internet money and thinking that a bunch of retards publishing JPEGs on-chain is any kind of problem is a contradiction. We both know the truth that, push come to shove, the former is true and the latter is false. Bitcoin is unstoppable internet money, and the JPEGs are a non-issue. But, by espousing both beliefs, you weaken any argument you might make that Bitcoin can resist the state.

For all the whining on Twitter, nobody has been able to make so much as a dent in ordinals and inscriptions. So, given that, and given that we have important work to do in destroying fiat, maybe you should stop whining about something you can't change, and adjust to the new, and possibly uncomfortable reality that NFTs have come to Bitcoin? This will no doubt not be the last time that people start doing unpleasant things on Bitcoin, so it would be a good exercise to start accepting it now. You can then refocus your efforts on more important things, like spreading Satoshi's good word and helping as many people as possible learn how to use Bitcoin.

Also, strategically, all press is good press, and complaining about inscriptions just makes more people learn about them, and makes the inscribers extra keen to nakadashi JPEGs into the blockchain, just to make you look like idiots. If normies like doing something, then you're not going to make any friends, or make any headway on anything, by scolding them for doing it.

If you still insist on complaining about inscriptions, at least take a moment to learn about them, so you can ditch your worst and least compelling arguments. These include:

Attempting to censor inscriptions is exactly identical to attempting censoring other kinds of transactions. Any machinery you build or public support you muster will immediately lend support to censorship on Bitcoin in general. Fortunately, processing transactions that someone views as illegitimate is exactly the thing Bitcoin was built for, so you will ultimately fail, but we would all be better of if you didn't try to convince people that censoring Bitcoin transactions was something they should bother trying. You've already managed to confuse Ocean Mining into thinking that it's possible and a good idea, and although they'll eventually bend the knee even further than they already have, it would be nice if we just got another mining pool, instead of having it needlessly gimped right out of the gate.

So, what should you do about inscriptions?

Just ignore them. More valuable use-cases will price out the majority of inscriptions. There will always be some high-value inscriptions, but they don't compete seriously with hard money and uncensorable transactions. Bitcoin's destiny is high fees. Embrace it.

We have much bigger fish to fry, and if you're interested in doing more than just pearl clutching and engagement farming, we can all get to frying them.

The Stable is the Aesthetic
bitcoin · ordinals

When a dev tells you that something is weird and hard and they have to change behavior that users rely on, the correct response is somewhere between "Cool story, bro." and "Wah, wah, wah, are the bits being mean to you?". Developers serve users, not the other way around.

For this and other reasons, the ord developers recommit to the stability and predictability of inscription numbers, and will not pursue renumbering.

As someone who people in the ordinals community mysteriously pay a lot of attention to, I see myself as having two distinct roles with regards to proposals such as the great renumbering.

One is to have and propose things that I think are good ideas. This will continue, and I don't see any particular reason to self-censor. In other words, the unfettered blog posts will continue. The community needs to understand that these are proposals only, and that I have had and will continue to have wacky ideas.

The other role is as one of the people who helps make decisions about what to implement in ord, the ordinals reference implementation. Raph, as lead maintainer, has the final say, but he hasn't stopped listening to my wacky ideas, so I still have some influence. Those decisions must be made with respect to the userbase of ord and the greater ordinals community.

When I first decided to propose renumbering, I knew that it had to meet a very high bar. Changes to ord and to ordinals must be Pareto improvements, changes to the status quo that leave everyone better off, or extremely close to it. Changes cannot create winners and losers, even if the benefit to the winners might be greater than the harm to the losers.

After reading discussion on GitHub and Twitter, lurking in many a Twitter space, and discussing it with many people, it's clear that the great renumbering does not meet that very high bar, and is better off consigned to the dustbin of history.

A couple of the arguments that I personally found most persuasive:

What does this mean, practically?

Inscriptions are both a technical artifact, and an artistic technology. Technical considerations must contend on equal footing with aesthetic considerations.

Inscription numbers are here to stay.


I'm not sure creating a new fungible token protocol for Bitcoin is a good idea. Fungible tokens are 99.9% scams and memes. However, they don't appear to be going away any time soon, similar to the way in which casinos don't appear to be going away any time soon. Creating a good fungible token protocol for Bitcoin might bring significant transaction fee revenue, developer mindshare, and users to Bitcoin. Additionally, if this protocol had a small on-chain footprint and encouraged responsible UTXO management, it might serve as harm reduction compared to existing protocols. At least one of which, BRC-20, is already quite popular, and has the undesirable consequence of UTXO proliferation.

When comparing existing fungible token protocols, there are a few important ways in which they differ:

Comparing existing fungible token protocols for Bitcoin:

What would a simple, UTXO-based fungible token protocol with a good user experience for Bitcoin look like? Here's one, called "runes", because it sounds cool.


Rune balances are held by UTXOs. A UTXO can contain any amount of any number of runes.

A transaction contains a protocol message if it contains an output whose script pubkey contains an OP_RETURN followed by a data push of the ASCII uppercase letter R. The protocol message is all data pushes after the first.

Runes input to a transaction with an invalid protocol message are burned. This allows for future upgrades that change how runes are assigned or created from creating situations where old clients erroneously assign rune balances.

Integers are encoded as prefix varints, where the number of leading ones in a varint determines its length in bytes.


The first data push in a protocol message is decoded as a sequence integers.

These integers are interpreted as a sequence of (ID, OUTPUT, AMOUNT) tuples. If the number of decoded integers is not a multiple of three, the protocol message message is invalid.

ID is encoded as a delta. This allows multiple assignments of the same rune to avoid repeating the full rune ID. For example, the tuples:

[(100, 1, 20), (0, 2 10), (20, 1, 5)]

Make the following assignments:

The AMOUNT 0 is shorthand for "all remaining runes".

After processing all tuple assignments, any unassigned runes are assigned to the first non-OP_RETURN output, if any.

Excess assignments are ignored.

Runes may be burned by assigning them to the OP_RETURN output containing the protocol message.


If the protocol message has a second data push, it is an issuance transaction. The second data push is decoded as two integers, SYMBOL, DECIMALS. If additional integers remain, the protocol message is invalid.

An issuance transaction may create any amount, up to 2^128 - 1 of the issued rune, using the ID 0 in assignment tuples.

SYMBOL is a base 26-encoded human readable symbol, similar to that used in ordinal number sat names. The only valid characters are A through Z.

DECIMALS is the number of digits after the decimal point that should be used when displaying the issued rune.

If SYMBOL has not already been assigned, it is assigned to the issued rune, and the issued rune receives the next available numeric rune ID, starting at one.

If SYMBOL has already been assigned, or is BITCOIN, BTC, or XBT, then no new rune is created. Issuance transaction assignments using the 0 rune ID are ignored, but other assignments are still processed.


When displaying UTXO balances, the native bitcoin balance of a UTXO can be displayed with rune ID zero and the symbol BITCOIN, BTC, or XBT.

No attempt is made to avoid symbol squatting, to keep the protocol simple. One possible, but still simple, technique to avoid symbols squatting would be to only allow assignment of symbols above a certain length, with that length decreasing over time, before eventually reaching zero and allowing all symbols. This would avoid short, desirable symbols being assigned in the early days of the protocol, and encourage competition for desirable symbols later on, when such competition might be meaningful.

Hand Wringing

Should such a thing exist? I don't know. It's about as simple as possible, does not rely on off-chain data, does not have a native token, and fits nicely into Bitcoin's native UTXO model. Such a scheme might draw users from other schemes with worse on-chain footprints, and bring developer and user mindshare to Bitcoin, encouraging them to adopt Bitcoin itself.

On the other hand, the world of fungible tokens is a near totally irredeemable pit of deceit and avarice, so it might be a wash.

The Great Renumbering
bitcoin · ordinals

Inscription numbers are numbers assigned to inscriptions in the order in which they are created, starting at zero for the genesis inscription.

When inscription numbers were originally added to ord, the Ordinals wallet and explorer that powers, they were intended to be stable and never change.

However, now that we have more experience with the protocol, that seems less tenable and has undesirable consequences, as maintaining stable inscription numbers is a challenge in the face of changes to the inscription protocol.

Consider a simple case, an update that allows multiple inscriptions to be created in a single transaction.

The inscription numbers assigned by an implementation that recognizes multiple inscriptions in a single transaction would differ from those assigned by an implementation that does not.

The former implementation would see T1, creating two new inscriptions, and T2, creating a single new inscription, and assign inscription numbers N, N+1, and N+2, the latter implementation would assign inscription number N to the first and only inscription it recognized in T1, and N+1 to the inscription in T2.

There are many such updates that we would like to make or have made which would introduce discrepancies like these, including:

We've been able to make these changes and keep inscription numbers stable using what I've now come to think of as a regrettable hack: cursed inscriptions. Whenever ord indexes an inscription which would not be recognized by an earlier version, it assigns a negative inscription number. This keeps old inscription numbers stable, while still recognizing new inscriptions.

Cursed inscriptions and negative inscriptions numbers have a number of downsides:

In light of the above, I propose that we make inscription numbers permanently unstable, and bless all cursed inscriptions, both retroactively and on an ongoing basis. Cursed inscription numbers would be folded into the main sequence, and, going forward, inscription numbers should not be used in URLs, which is already the case for ord, and inscription numbers would be de-emphasized on /inscription pages.

This would substantially simplify the ord codebase, make it easier to produce an implementation that assigns the same sequence numbers, and make future protocol changes easier.

Inscribing Mainnet
art · bitcoin · ordinals

ord version 0.4.0 has been released. Inscriptions are finally ready for Bitcoin mainnet.


Inscriptions are digital artifacts native to the Bitcoin blockchain. They are created by inscribing sats with content using ord, and can be viewed with the ordinals explorer. They do not require a separate token, a side chain, or changing Bitcoin.

Inscriptions are created by including content, like an image, text, SVG, or HTML, in an inscription transaction. The content is included in the transaction witness, which normally contains signatures and other data proving that a transaction is authorized.

Along with the content, the inscription transaction contains a content type, also known as a MIME type, identifying the type of content to be inscribed.

When mined, the inscription is made on the first sat of the first output of the transaction, permanently and inexorably marking it, distinguishing it from its fellows. It is no longer just a sat, it is an intertwined component of the long and confusing tale that is human art and culture.

Using ordinal theory, the unspent output containing an inscribed sat can be found, and its movements and ownership tracked across time and transactions, allowing inscriptions to traded, gifted, bought, and sold.

This allows inscriptions quite native to Bitcoin. They can be sent to normal bitcoin addresses, in normal bitcoin transactions, and benefit from timelocks, multisig, and all the rest of Bitcoin's infrastructure. To avoid losing them, a wallet that holds inscriptions must perform sat control, the sizing and alignment of transaction inputs and outputs that controls the destination of individual sats, but aside from that, transactions that transfer inscriptions are quite mundane.

Digital Artifacts

Inscriptions are digital artifacts, and digital artifacts are NFTs, but not all NFTs are digital artifacts. Digital artifacts are NFTs held to a higher standard, closer to their ideal. For an NFT to be a digital artifact, it must be decentralized, immutable, on-chain, and unrestricted. The vast majority of NFTs are not digital artifacts. Their content is stored off-chain and can be lost, they are on centralized chains, and they have back-door admin keys. What's worse, because they are smart contracts, they must be audited on a case-by-case basis to determine their properties.

Inscriptions are unplagued by such flaws. Inscriptions are immutable and on-chain, on the oldest, most decentralized, most secure blockchain in the world. They are not smart contracts, and do not need to be examined individually to determine their properties. They are true digital artifacts.

ord 0.4.0

ord is an open-source binary written in Rust, and developed on GitHub. It implements an ordinal wallet, which can create and transfer inscriptions, and a block explorer. There are public mainnet, signet, and testnet instances.

ord is experimental software, and comes with no warranty or guarantees. ord 0.4.0, the latest release, has been tested carefully, and can now be used to make inscriptions on mainnet, and that those inscriptions will not break due to a future protocol change.

Three mechanisms exist to introduce opt-in changes to the protocol, without breaking existing inscriptions: Versioning, optional fields, and mandatory fields.

Inscriptions can contain a version field. The inscription parser will ignore inscriptions with an unrecognized version. This allows introducing fundamental changes to inscriptions, without disrupting existing inscriptions.

Additionally, fields can be marked as optional or mandatory, which determines how an inscription parser treats an unrecognized field. Unrecognized optional fields are ignored but the inscription is normally, while unrecognized mandatory fields render the whole inscription invalid.

Individual features that can be safely ignored if unsupported can be introduced as optional fields, while features that must be supported in order in order to understand an inscription can be introduced as mandatory fields.

Inscriptions are not finished, but this flexibility gives us confidence that future improvements can be made opt-in and non-disruptive.

Let markets and bazaars where rare sats and inscriptions are traded grow and flourish, and may their wares never crack or vanish.

What's missing?

Inscriptions have many unique benefits and features, but they have not yet reached feature parity with other NFT implementations.

Two key features are missing: provenance and decentralized markets.

Provenance is the ability to determine the author of an inscription, or its membership in a set of inscriptions all created by the same person. We have a design that accomplishes this, and its implementation is tracked in issue #783. A transaction creating a new inscription, X, may include an existing inscription, P, in its inputs, which is returned back to the owner in its outputs. Since only the owner of P could have made this transaction, this identifies P as the parent of X. This mechanism is flexible, and can be used to identify an inscription as being created by an individual, or to identify an inscription as being a member of a larger collection. Furthermore, this mechanism is recursive. You can create in inscription that represents your identity, and use that inscription as the parent of an inscription that itself is used as the parent inscription for a collection.

For inscriptions be valuable, there must be venues where they can be bought and sold. We have a sketch for decentralized and trustless offers to buy and sell using partially-signed transactions, and its implementation is tracked in issue #802. The owner of an inscription may offer it for sale by publishing a transaction that includes it as an input, and containing an output that pays to them the sale price. Any third party can take such a transaction, add their own input of at least the sale price, add an output sending the inscription to themselves, and finalize it by broadcasting it to be mined. Offers to buy are similar.

What's next?

Inscriptions have been designed to be native to the web. Inscriptions are byte strings, identified with a content type, and so can be displayed in a browser. HTML, CSS, JavaScript, SVG, MP3, PNG, and JPEG, are supported by the ordinals explorer.

Inscription content is sandboxed so that it cannot make outgoing web requests. However, in the future, this sandboxing will be relaxed to allow inscriptions to use the content of other inscriptions. This will allow for the development of an a modular, on-chain ecosystem of remixing and composition. This is tracked in issue #1082.

Inscriptions are unnamed and untitled, but we hope to give artificers the ability to give their inscriptions globally unique, human-readable names. This is tracked in issue #794.

The future of inscriptions is bright. We hope not only to reach feature parity with other NFT implementations, but to surpass them.

Single Word Seed Phrases

Ord Alpha
bitcoin · ordinals

We just released ord version 0.1.0!

ord is an ordinal number wallet and the index that serves

This release of ord is by no means complete, but it now supports making ordinal-aware transactions on mainnet using the ord wallet send command thanks to @raphjaph, and boasts much faster indexing thanks to @callmeier.

ord wallet send

The ord wallet commands interact with an existing Bitcoin Core wallet using Core's RPC interface, and this release features a new send subcommand that constructs an ordinal-aware transaction to send a particular ORDINAL to a recipient's ADDRESS:

ord wallet send ORDINAL ADDRESS

We write extensive tests alongside every feature, but bugs can always slip through, and the project as a whole is still immature, so restrictions apply when using ord wallet send with Mainnet wallets.

ord wallet send will refuse to interact with a Mainnet wallet with a name other than ord, which does not start with ord-, to encourage users to explicitly mark wallets as being intended for use with ord.

Using bitcoin-cli wallet commands with an ord wallet risks spending your rarest and most exotic sats, and using ord wallet commands with your main wallet risks doxing your main stash if you assocaite a spicy ordinal with your identity.

Index Optimization

ord must build and maintain an index that maps transaction outputs to ordinal ranges. ord 0.1.0 now exploits the fact that many UTXOs are spent soon after they're created, and uses an in-memory cache to avoid huge numbers of database insertions and retrievals. ord uses the redb database, which is already quite fast, but using an in-memory cache avoids reads from and writes to redb's B-tree, which are more expensive than the in-memory cache's hashmap.

Backwards Compatibility

ord is still alpha-quality software, so breaking changes are inevitable, but starting with version 0.1.0, we'll indicate when breaking changes are included in a release by bumping the minor version number (0.x.0).

Try it out!

Check out ord 0.1.0 and let us know what you think! ord is CC-0-licensed open-source software developed on GitHub.

Bitcoin Chaosnet

Ideas for a new Bitcoin testnet:

One of Bitcoin's core features is that coins have real-world value. A testnet with coins that have no value doesn't reproduce dynamics essential to Bitcoin, and doesn't encourage real-world use.

Competitive Governance
markets · governance

I've been thinking about competitive governance, trying to dissect what, exactly, its desirable properties might be, and how to achive them. It strikes me that there are two separate desriable properties that governments have under competition, which, for lack of a better word, I'll call incentives and constraints.

Good incentives encourage governments to do useful things. Whereas constraints prevent them from doing harmful things, or cause governments to cease to exist if the do harmful things, or at least limit the harm that they can do.

Sending Ordinals on Signet
bitcoin · ordinals

Raph and I have been working hard on ord, the ordinal block explorer and wallet, and have just finished the initial version of the ord wallet send ORDINAL ADDRESS command, which makes a transaction sending ORDINAL to ADDRESS.

Ordinal-aware Bitcoin transactions are rather tricky, and must attend to a number of considerations:

This requires a great deal of stressful fiddling with transaction input and output size and order, and a great deal of checks for edge cases. You can see all the gory details in the transaction builder.

All that fiddling has paid off, and today we made three transactions on signet:

ord wallet send will hopefully be much easier to use compared to using bitcoin-cli to manually construct ordinal-aware transactions. Give it a shot and let us know what you think!

Ordinal Theory
bitcoin · computers · internet · cryptocurrency · ordinals

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.

A block explorer is available at You can explore recent blocks, and look up ordinals by number, decimal, degree, or name.

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.


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:

This gives us the following rarity levels:

Which brings us to degree notation, which unambiguously represents an ordinal in a way that makes rarity easy to see at a glance:

│ │ │ ╰─ 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:

│ │ │ ╰─ Not first sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle

This ordinal is uncommon:

│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficutly adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle

This ordinal is rare:

│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── Not the first block in halving epoch
╰─────── Second cycle

This ordinal is epic:

│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle

This ordinal is legendary:

│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle

And this ordinal is mythic:

│ │ │ ╰─ 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:

│ │ ╰─ Not first block in difficutly adjustment period
│ ╰─── Not first block in halving epoch
╰───── Second cycle


Total Supply

Current Supply

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.


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.


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 lively community of archaeologists devoted to cataloging and collecting early NFTs has sprung up. Here's a great summary of historical NFTs by Chainleft.

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 August 21st, 2012, Charlie Lee posted a proposal to add proof-of-stake to Bitcoin to the Bitocin Talk forum. This wasn't an asset scheme, but did use the ordinal algorithm, and was implemented but never deployed.

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.

Hell Money Podcast Episode 8 Show Notes: Crypto is Trash

Crypto History


2009 - Bitcoin

2011 - Early Altcoins

2017 - ICO Boom

2020 - DeFi and NFTs

Crypto Psychological Archetypes

What's wrong with…?



Stable Coins




Proof of Stake





Multisig Is Probably Better Than Proof Of Stake
computers · cryptocurrency

A large reputable member threshold multisig operating as functionaries for a Bitcoin-pegged deterministic replicated state machine sidechain with as-compatible-as-possible-with-mainchain semantics is probably more reliable and secure that most alternative chains.

Investable Desiderata
computers · cryptocurrency · internet · markets

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!

Standards-based Social Networking
computers · internet

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:

Upgrading Email
computers · internet


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.


Add the features that make people use other messaging protocols to email.

Which features?


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.


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.


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.


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.

The Path to Email World Domination
computers · internet

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:

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.

With best regards, Casey Rodarmor

The Terrestrial Dividend
markets · politics

Tax the land, pay the people.

The Terrestrial Dividend consists of a tax and a dividend. Revenue is generated with a tax on the unimproved value of land and distributed as a cash dividend to all citizens.


If You're in Favor of Wealth Redistribution

If you are in favor of wealth redistribution, you should want to raise as much money as possible, as fairly as possible, and get as much as possible into the hands of those who need it.

The Terrestrial Dividend accomplishes all of these goals.

If You are Against Wealth Redistribution

If you are not in favor of wealth redistribution, you should want revenue generation to be as efficient as possible, and to minimize the negative economic impact of distribution. Additionally, you should want wealth redistribution to be done in such a way that if it is harmful, incentives align to reduce it.

The Terrestrial Dividend accomplishes all of these goals.

The Terrestrial Tax

The Terrestrial Tax is economically efficient. The supply of land is fixed, so a tax on the unimproved value of land does not prevent the production of more land. A tax on widgets, on the other hand, reduces the incentive to produce widgets.

The Terrestrial Tax is progressive. Land is owned by the wealthy, so the wealthy would pay a much greater share of the tax. Due to the fixed supply of land, the tax cannot be passed on to tenants.

The Terrestrial Tax respects privacy. The government does not need to know who owns what land, or what they are doing with it. The tax can be collected with anonymous payments, and only in the case of non-payment must the government involve itself.

The Terrestrial Tax cannot be avoided. It is impossible to hide land or disguise use of land.

The Terrestrial Tax encourages productive economic activity. Since the tax is levied on the unimproved value of land, under-utilized land is a liability, and will be brought into productive use or sold, not held as a speculative asset.

The Terrestrial Tax is simple. Income, sales, value-added, and corporate taxes require enormously complex and err-prone reporting. The details of these taxes are the source of endless political litigation. Under the Terrestrial Tax, the only complexity is in fairly valuing the unimproved value of land, clearly an easier task.

The Terrestrial Tax is legible. The negative effects of a too-low or too-high tax rate can be observed and the rate corrected.

The Terrestrial Dividend

The Terrestrial Dividend is beneficial. Cash is more useful in all circumstances than in-kind payments of the same value. The people who need help will get the most benefit possible.

The Terrestrial Dividend is fair. All citizens receive equal-sized cash payments. There is no need to exclude certain recipients, since the wealthy will already pay more tax than they receive as dividend.

The Terrestrial Dividend is efficient. Cash payments avoid the overhead of defining the details of and administering in-kind benefits.

The Terrestrial Dividend is what people want. People prefer cash over in-kind benefits of the same value.

The Terrestrial Dividend is unobtrusive. It is not means tested, nor does it require an application. The poor are the least equipped to fill out applications and submit documentation of income, so this ensures that even the very worst off have the best chance of receiving benefits.

The Terrestrial Dividend is legible. The negative effects of a too-low or too-high dividend can be observed and the amount corrected.


The Terrestrial Tax and Dividend are good policies on their own, but even better together due to aligning incentives.

If you want to increase the amount of the dividend, you should want to increase the value of all land, so that the dividend can be increased.

If you want to reduce the amount of the tax, you should want to increase the value of all land, so the tax rate can be reduced without reducing the divided.

Under the Terrestrial Dividend, everyone should care about reducing government overhead and waste, because it comes out of their own pockets.

Also, everyone should care about removing bad policies and implementing good ones, because they increase the value of all land and make everyone better off.

Tax the land, pay the people.

Coin IDs

Good evening list,

This mail is inspired by Chia's coin IDs. Chia coin IDs consist of:

sha256(parent id, sha256(scriptpubkey), amount)

One consequence of this is that outputs in Chia have a dedicated textual ID. This seems beneficial, separate from any larger technical consequences, and made me wonder if we couldn't replicate that in Bitcoin.

Outputs, a.k.a. outpoints, are commonly represented as TXID:INDEX. For example, the first output of transaction c7dd35a4f81977feac0d235d0e77265cacd362bfc2f0246e384a80d3b0a53a9b is represented as c7dd35a4f81977feac0d235d0e77265cacd362bfc2f0246e384a80d3b0a53a9b:0.

I find this representation unsatisfying:

I propose a dedicated representation of outputs using Bech32m. Bech32m is especially legible, due to its human-readable part, and is compact, and easy to type and verify. Although having error correction doesn't seem absolutely necessary, it doesn't seem like a downside. The representation uses "coin" as the human-readable part, with the payload being the transaction ID, followed by the 4 byte index.

For example:




Anacdotally, I find that many non-expert users I talk to think and talk about Bitcoin as if it were an account-based system, and tend to think in terms of transactions. I wonder if having coin IDs, in the form I propose or in some other form, would help remedy this, similar to how transaction ids, block hashes, and addresses help reify those concepts. The particulars of the representation are of secondary importance.

Best regards,
Casey Rodarmor

[0],,,, and


Conventional software configuration is backwards.

If you want an HTTP server to listen on port 80 and serve some directory full of files, you tell the service to bind to port 80 and pass it the path of the files to serve:

$ http-server --port 80 --files /srv/www
Serving `/srv/www` via HTTP on port 80.

This is backwards. Let's call this kind of configuration "internal configuration", because it's configuration that happens inside programs.

Instead, processes should declare a namespace of resources that they consume or produce:

$ mount http-server /http
Mounted `http-server` instance at `/http`.
$ tree /http

After mounting, resources would be mapped as you see fit, from outside the process, without having to stop or reconfigure the service:

$ listen 80 /http/socket/listen
Connections to port 80 are being forwarded to socket `/http/socket/listen`.
$ export /srv/www /http/imports/files
Filesystem `/srv/www` exported to `/http/imports/files`.

Let's call this "external configuration", because it's configuration that happens outside programs.

External configuration has a number of benefits:

Wound Care

Got some minor cuts and scrapes while doing water sports (not the fetish kind you perv), was curious about the optimal way to dress them, which lead to reading at least a dozen papers and articles on wound care and dressing selection.

It is a complex and interesting topic! Here is my probably-inaccurate summary:

The four stages of wound healing are hemostasis, inflammation, proliferation, and maturation.

Hemostasis is the body's immediate reaction to and stabilization of the wound. Blood clots and stops flowing from the wound. Or doesn't, in which case hemostasis is the first and last stage of wound healing.

Inflammation comes next, which includes processes that prevent infection and initiate healing. Injured blood vessels leak transudate (water, salt, and protein) white blood cells head to the wound, tissue turns red and swells, and bacteria and dead cells are removed from the wound.

Proliferation is the phase where the bulk of tissue reconstruction and healing takes place. Lost tissue grows back, and the wound closes. In the final phase of proliferation, epithelial cells regrow and cover the wound.

Maturation, also called remodeling, is the finalization and cleanup phase. The plumbers, electricians, and carpenters leave the building site, and all the loose ends are tied up. Temporary cells die off via apoptosis, and the new tissue reorganizes and strengthens.

The appropriate dressing depends on the characteristics of the wound, and so, as you might imagine, there exists a rich terminology for wound description.

A sloughy wound is with a layer of infected gunk, usually yellow, You've probably noticed this when you've had an infected scrape. Slough is dead tissue that must be removed for the wound to heal, and a sloughy wound should be covered with a moist dressing that allows the slough to liquefy. I gather that mechanical debridement of slough, e.g. the use of wet-to-dry dressings, although still widely used, is no longer a standard of care.

A necrotic wound has some amount of dead skin or flesh covering or surrounding the wound, usually of a ghastly black color. If necrotic tissue is badly infected, it should be surgically removed. However, since this is invasive and destructive, the preferred alternative for the removal of non-infected necrotic tissue is the use of a moist, occlusive dressing promoting autolytic debridement, the natural separation of viable and non-viable tissue.

A granulating wound wound in the process of healing. It has a nice bright, healthy red color, and should be covered in a moist occlusive dressing and left to heal.

An epithelial wound is in the final stages of healing, with new skin growing over and covering the wound.

Interesting tidbit, if a wound is deep, it should be packed with some kind of dressing, to prevent premature wound closure before the wound void fills in with new tissue.

For my own rather boring although mildly sloughy wounds, I went with hydrocolloid dressings. Hydrocolloid dressings are occlusive dressings which create a moist environment for wound healing. As they transition from sloughy wounds to granulating wounds, I might switch to just using a film dressing, which are more flexible, comfortable, and durable.

After all this, I'm a little bummed that I don't have much weirder, graver, more complicated wounds that would demand more complex and interesting care. 😂

Lightning Mints
cryptocurrency · internet · computers · markets

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 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.

cryptocurrency · politics

Bitcoin will greatly reduce the power of the state, which rests entirely on its capacity for violence. This capacity is maintained by paying and equipping people to commit violence on its behalf, and it acquires the resources to do so by printing money, collecting taxes, and issuing debt.

read more…


I don't do as much deep thinking as I used to. When I was a kid, I remember imagining what it would be like if the universe was symmetrical, mirrored right down the middle. I imagined a white room, floating in space, right on the plane that separates the two halves of the universe. If you parked your spaceship outside and opened the door, you would see yourself in front of you, opening the same door. It would be the you from the other side of the universe.

read more…

Wanko Manko
fiction · shitpost

Thought of a hilarious idea for a manga and eventually anime when it inevitably gets super popular.

It takes place in Japan, but only because that seems like the only appropriate setting for an anime.

The story is about a twenty-something bachelor. He wants a dog, so he adopts a beautiful female malamute from a shelter.

However! When he gets home, he realizes that the dog has the most beautiful human-looking vagina he has ever seen. Like, all-time-top-voted-post-on-r/godpussy tier. Of course, since it's an anime, you only ever see it pixelated.

Then, basically the entire show revolves around him trying to resist the temptation to fuck his dog, and situations that make it hard to resist temptation. His catchphrase is "Inu ni makemasen!" / "I won't lose to the dog!"

Like, for example, in one episode he leaves out a jar of strawberry jam, and the dog gets into it, and then when the dog is done eating the jam, it pulls its snout out of the jar, and there's strawberry jam on its mouth in the exact shape of sexy lipstick. This of course sends him into a fit of desire, and he has to like, I dunno, take a cold bath, or watch sumo wrestling or something to resist.

In the final episode, he's taking the dog for a walk in a dog park, and he sees another dog running around, and notices that it has a huge, beautiful human penis. (Pixelated, natch.) He then look over and sees its owner, who's a beautiful woman his age. They lock eyes and instantly fall in love.

I can't decide if it's a happy ending, where he gets this great girl and the two dogs with beautiful junk get each other. Or if it's a darker ending, where he has sex with the woman for the first time and her pussy is absolutely ruined, and he realizes that she hasn't resisted temptation and has been getting railed on the reg by her dog and its huge human cock. Or afterwards he asks her how it was, and she says "It was okay…" in a super wistful voice, and then looks over at her dog, while the color drains from his face as he realizes the truth.

I'm not sure whether it should be called Wanko Manko, which means "Dog Pussy" in Japanese but rhymes, or Venus in Fur, as a play on Venus in Furs by Leopold von Sacher-Masoch.

For some reason I'm fascinated by the debris in this vacuum product photo. If you look closely, you can see that it's several specific kinds of debris. Uncooked grains of rice, sunflower seeds, maybe coffee beans, and clumps of hair. I'm imagining some intern getting just the right debris ready for the photo.



Policy For Manufacture

The complex priority system that the state is using in many countries to roll out the covid vaccine is reminiscent of this plane boarding algorithm:

Yes, it is optimal. No, it won't work in real life.

The state, of course, ignores this. Its reach exceeds its grasp, and we are left with fragile, sub-optimal, poorly implemented plans that are, without exaggeration, worse than a free-for-all, and much worse than market allocation.

The state makes the same mistake in all spheres, because it makes no distinction between designing policy and implementing policy.

The opposite of this is design for manufacturing, where designers of a product modify a design with manufacturing constraints in mind, even if it makes the design worse on some axes. The final outcome, of course, is substantially better.

The product is subject to fewer delays, costs less, and can be made in higher quantities.

However, we cannot expect the state to grasp this simple wisdom, for it is utterly bereft of the incentive to do so.

Haircut Numbers

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.

How To Debug Things
  1. What is happening?

  2. What is a hypothesis that would explain why this is happening?

  3. How can you test this hypothesis?

  4. Test it! What did you do?

  5. Did it work? If not, write down what happened and go back to step 2.

  6. You're done! Nice work!

Sex Sells

As an unrepentant degenerate and fan of microeconomics, it should come as no surprise that I find the online sexual economy endlessly fascinating.

Most of what happens there isn't surprising to me, with the exception of pricing for online sexual services, which is much higher than I would have expected.

As an example, take private, one-on-one cam shows. Browsing, the going rate seems to be between $2.50 and $5.00 per minute, or $150 to $300 per hour.

This is mysterious to me.

Looking at ads on, offline prostitutes seem to charge $300 an hour. This isn't the amount advertised for a one hour session, but the marginal difference in price between a one hour and two hour session, and thus a reasonable estimate of the hourly rate, when preparation and travel are factored out.

Given that private cam shows are legal, can be done at home, and require minimal equipment; while offline prostitution is physically dangerous, illegal, unpleasant1, and highly taboo, it seems strange that they are priced roughly the same.

A priori, I would have expected a price difference of 10× or more, like $300 per hour offline and $30 per hour on cam.

read more…

Advice For Programmers

In an October 1935 article in Esquire. Hemingway offers this advice to a young writer:

The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.

Reformulated for programmers and equally valuable:

The best way is aways to stop when you are going good and you have just written a failing test. If you do that every day when you are writing a program you will never be stuck. That is the most valuable thing I can tell you so try to remember it.

If you start programming for the day, a failing test to fix will get you right back on track.

Instead of having to muster willpower to get started and brainpower to figure out what you were doing and what to do next, you can mindlessly do whatever it is that will fix the test.

After that, you'll be much more likely to be in the flow of things, and be able to keep going in good spirits.

Equitable Auction

The PS5 was released about a week ago, and, predictably, it is impossible to get one. All retailers, online and IRL, are sold out. Of course, consoles are available on Ebay at ruinous prices, so at least the scalpers are doing well.

Economists, of course, are wringing their hands and mumbling about Vickrey auctions. What Sony should do, they mutter, is to hold a daily auction for PS5s, and let the market decide the price.

The economists are, of course, quite right. If Sony auctioned off PS5s there would be no lines, no scalpers, and no uncertainty. You could put in a bid at the price that you wanted to pay, and then simply wait until demand had died down for your bid to be filled. As a bonus, Sony would make more money for producing something that people wanted to buy, and more capital to ramp up production.

Unfortunately, the economists don't get their say here, because of their arch enemy, non-economists. Non-economists, or, normal people, as they are otherwise known, as far as I can tell, don't understand that there is such a thing as an inescapable trade-off. They want everyone to get a PS5, everyone to pay MSRP for it, there to be no scalpers, nobody to ever make a profit from demand exceeding supply, and all things to be fair, based on confused and self-contradictory conceptions of unfairness.

So, companies can't hold auctions for scarce goods, and have to set an MSRP, produce whatever they can, and hope for the best.

I wonder though, if there might be some way for a company to hold an auction for their products, but in a way that would be perceived as fair.

Here is one possible setup for such an auction, using Sony as the example company, and the PS5 as the example product:

Essentially, any time someone pays over MSRP for a PS5, they ensure that eventually, someone will get a PS5 for less than MSRP. If someone rich or impatient buys a PS5 for $1000, two less impatient people can eventually buy PS5s for $250.

I think, perhaps, this would be perceived as fair. But, with real people, you never know.


I wrote a nontrivial AppleScript to merge duplicates in my iTunes library.

It is easily the most gruesome thing I have ever written.

read more…

Just: How I Organize Large Rust Programs

One of the things that I personally struggled with when learning Rust was how to organize large programs with multiple modules.

In this post, I'll explain how I organize the codebase of just, a command runner that I wrote.

just was the first large program I wrote in Rust, and its organization has gone through many iterations, as I discovered what worked for me and what didn't.

There are some things that could use improvement, and many of the choices I made are somewhat strange, so definitely don't consider the whole project a normative example of how to write rust.

read more…

Autonomous Consensus

I feel like BGP would be a great place to experiment with PKI systems, possibly with some additional global consensus mechanism.



I just published a simple crate that performs lexical path cleaning: lexiclean.

Lexical path cleaning simplifies paths by removing ., .., and double separators: //, without querying the filesystem. It is inspired by Go's Clean function, and differs from the Go version by not removing . if that is the only path component left.

I implemented this for a command line utility I'm working on, but split it off so others could use it.

There are a few reasons I prefer lexical path cleaning to fs::canonicalize:

There are some reasons you might prefer fs::canonicalize:

Are there any other reasons to prefer one over the other? I'd love to hear them!

It is very lightly tested! If you intend to use it, I encourage you to submit additional tests containing paths you might encounter, if you think the existing tests don't cover them. In particular, I haven't thought about all the exotic prefixes that Windows paths might be adorned with, so there might be bugs there.

I don't expect to modify the crate or add features to it beyond what I need for my own purposes, so if there are additional features you want, please consider opening a PR! Of course, if you find a bug, I will happily fix it.


From Scott Alexander on the Amish health care system:

The Muslims claim Mohammed was the last of the prophets, and that after his death God stopped advising earthly religions. But sometimes modern faiths will make a decision so inspired that it could only have come from divine revelation. This is how I feel about the Amish belief that health insurance companies are evil, and that good Christians must have no traffic with them.

The post is about the advantages of the Amish health care system, which seems to have much lower costs and equal effectiveness when compared to conventional American health insurance centered health care.

The post is gripping (well, at least if you're interested in why American health care is so expensive), so I recommend reading it. But briefly, the Amish seem to have much lower costs with the same quality of care due to:

I wonder if much of this could be replicated with, not an insurance plan, but, something else… an "uninsurance plan":

I suspect that such a plan would be very cheap, to make a number up, perhaps no more than $10 per month. If it were only $10 per month, and members got an HSA, they might want to join just for that. And, if they got insurance-negotiated rates when paying out-of-pocket while being uninsured, the would almost certainly be willing to pay for it.

Such an uninsurance plan would encourage consumers to plan ahead, shop around, and save for medical expenses in their HSA, maybe giving them health care approaching that of the Pennsylvania Dutch.


Nature abhors a discontinuity.


Just Hack

Just is a general-purpose command runner written in Rust with a make-like syntax.

If you're interested in hacking on just, I'd love to help!

read more…

USG was always this this incompetent, this inefficient, this craven, this self-serving. It just needed external stresses requiring a competent response to reveal the extent of its functional bankruptcy.

BTC chart lookin' spicy 👀👀👀


Ideal Male Body


Anarcho Catbus Wartime Flag





Bonded Matzot

I happened to visit these pages one after the other:

The similarity is striking.

read more…



All democracy gives you is this: People convince themselves that the best way to get what they want is by voting, lobbying, and running for office, and not with AK-47s in the streets.

Which, all things considered, is probably better than nothing.

But don't suck democracy's dick and expect good decisions, wise governance, and functional laws to shoot out of it.



Programmer Art


Punished Jones



This is the 200th time I have Googled "CSS Box Model" and I have become exceedling efficient at it.

sharing · programming


Intermodal is a new command-line BitTorrent metainfo1 utility for Linux, Windows, and macOS. The binary is called imdl.

It can create, display, and verify .torrent files, as well as generate magnet links.

demonstration animation

It has lots of features and niceties, is easy to install and run, and is hopefully just the beginning of an ambitious project to make decentralized content sharing better.

Features include:

You can install the latest version of imdl to ~/bin with:

curl --proto '=https' --tlsv1.2 -sSf | bash

Development is hosted on GitHub, where you can find the code, the issue tracker, and more installation options.

Give it a try and let me know what you think!

I'm eager to hear what works, what doesn't, and what features you'd like to see added. I'll be working on novel functionality—more on that below—and I'd love to hear your critical feedback and ideas.

You can get in touch by open an issue, joining the discord server, or sending me an email.

Happy sharing!

read more…

Decentralize Messaging

Twitter is funding a team to decentralize social media. I think they should start with messaging.




Update: I no longer believe Matrix is fit for use.

read more…

Popcorn Time Should Become a Browser

I am not a lawyer. This is not legal advice.

Popcorn Time-style video streaming apps seem to be vulnerable to legal action by rightsholders.

For example, the domain was recently suspended, and the operator of a site which merely provided information about how to obtain and use Popcorn Time was sentenced to prison.

Although given that Popcorn Time's servers do not themselves host infringing content this may seem a bit unfair, it is simply the reality of the world we live in.

It is interesting to note, however, that although web browsers can be used in exactly the same way as Popcorn Time, namely searching for and viewing copyrighted movies, the developers of web browsers have thus far not faced successful legal challenges.

read more…

The Stack

Computering is a party. The stack is best visualized as a bunch of Jenga blocks on the floor, and the heap as a bunch of balloons floating around bumping into each other on the ceiling. The fact that the stack usually grows downwards in memory is a travesty.

I saw a janitor sweeping dirt from the fronds of his enormous push broom with a normal-sized broom.

Unix Utilities in Rust for Great Success

I've often been asked for suggestions for an appropriate first project in Rust, and I think that writing a version of a unix utility is a great choice, for a bunch of reasons!

read more…


A Kademlia-inspired modification of Dandelion for use in Grin.

read more…


We all stood, gathered our things, walked down the cafe stairs and out to the dark and bustling Berlin street.

After a few goodbyes and handshakes, everyone headed off in different directions, for different destinations.

The meeting had felt momentous to me, a marker of strange and interesting times to come. I headed to the U-Bahn, alone.

New Rustacean Resources


I woke up last night after only a few hours of sleep, sweaty and disoriented.

Maybe it was miasmatic vapors rising up from beneath South of Market streets. Maybe it was the widening gyre opening up under the world. Maybe it was nothing at all. I don't know.

It felt like the world had ended, but I was still there. And the lights of the city glimmered through the window, so, it was still there too.

read more…

Lightning Exchange

The Lightning Network has the potential to greatly improve cryptocurrency exchanges.

Lighting Network payment channels could be established between users and exchanges to speed the transfer of funds.

This would be a huge boon, moving many on-chain deposit and withdrawal transactions off-chain, but is possibly only the beginning.

Since Lightning Network payments can span different blockchains, an exchange could use a cross-chain Lightning node to expose its internal order book to external entities.

read more…


IOTA is a cryptocurrency targeting the internet of things. It purports to be scalable, decentralized, and feeless. Unfortunately it is none of those things.

In this article I attempt to summarize the numerous technical, social, and ethical problems surrounding the IOTA project, The IOTA Foundation, and the IOTA developers.

read more…

Actuality Films

VXX is a dangerous chimeric creature; it is structured like a bond, trades like a stock, follows VIX futures and decays like an option. Handle with care.

And, currently being algo traded by a program written in Excel VBA.

Strange times indeed.

Structural Heterogeneity

Investing in cryptocurrencies is not the same as buying simple equity in a company.

Although each company has a different business model, they and the equity they issue are largely structurally homogeneous. They hold their monies in banks, pay for their expenses with wire transfers and cheques, follow prescribed rules of accounting, and issue stock that operates according to well understood rules. This is not to say that said practices are good or bad. They are simply a known factor.

Cryptocurrencies and tokens, however, are structurally heterogeneous. They have different codebases, modes of operation, levels of complexity, and security models. Although broadly lumped into the same category, they can, by the nature of these differences, have almost nothing in common.

Investing in one is like buying stock in a company with novel business models, banking practices, and accounting methods, and furthermore whose stock is issued under a bespoke scheme and follows unique trading rules.

Accordingly, a much, much greater level of care is required when making such investments. If any one of these novel mechanisms fail, your investment may go up in billowing smoke and flames overnight.

This is not to say that you should completely avoid cryptocurrencies and tokens, just, you know, do your homework.

I only program in PL/I because I'm BASED.


Programs first crawled from the murky oceans as simple lists of instructions that executed in sequence. From these humble beginnings they have since evolved an astonishing number of ways of delinearizing.

In fact, most programming paradigms simply amount to different ways to transform a linear source file into a program with nonlinear behavior.

Some examples:

Parse structure from the languageless void.


This is pretty nuts. I was poking around in the storage area of my house, and I found a huge cardboard box filled with letters and audio cassettes and dust. Everything was Danish, German, and English, but mostly Danish. The name Max Rasmussen was everywhere, so I think it was all his stuff. I had to get a tape player at best buy to play the tapes, but surprisingly, they all played fine. One of them was an interview, in English, between Max and a man named Hans. I listened to it a few times, and I don't even know what to say. It's transcribed below.

read more…

Declarative Programming

"Well," he began, moving closer to her, "declarative programming is when you tell the computer what you want, and then the computer figures out how to get it. Pretty sweet, huh?"

"What kinds of things can you tell the computer you want?" she asked excitedly, her cheeks beginning to flush.

He thought for a moment, and began stroking her hair gently. "All kinds of things. There's a language called Prolog you can use to ask about logical relationships. In SQL you can ask questions about huge quantities of data. With a program like bison you can declaratively describe a language, letting bison generate a program that recognizes it."

"Oh," she said breathlessly, leaning her head on his shoulder, "so I don't have to worry about choosing an algorithm--the computer will pick one for me?"

read more…