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.

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:

• Anyone can right-click save the JPEGs. Literally every degenerate buying inscriptions knows this. Literally every single one. Nobody is buying inscriptions based on the delusion that they are buying access. Accepting this and updating your worldview will bring it closer to reality, and less likely to be destroyed by it.

• Inscriptions aren't real, they're just a collective hallucination. I've been saying basically exactly this since day one, that ordinals and inscriptions are an opt-in lens with which to view Bitcoin. Behaving as if this is some kind of damning revelation makes you look like a moron. Additionally, it shows that you misunderstand one of the most fundamental things about humans, civilization, and culture: Everything important is just social conventions. Bitcoin is, in fact, just a social convention. Or, put another way, it's not the software or data that matter, it's the social conventions around it. Inscriptions are no different.

• You can just store the data off-chain. People value on-chain data. It makes inscriptions scarce, and dramatically improves reliability and user-safety. Every other NFT ecosystem uses off-chain data, and uninformed users delegate trust to whoever happens to be pinning the files on IPFS, and they might stop at any time. On-chain data is a vast improvement in trustlessness, which, I am told, is highly valued by ideological maxis.

• Inscriptions are illegitimate. There's an obvious difference between things that are illegitimate, like state violence, and things that you just think are stupid. Arguing that something is illegitimate because you don't like it or don't see the purpose of it makes you look like a retard.

• Inscriptions are a state attack. Somehow, you see NFTs and shitcoins on other chains, understand that they exist because of enthusiasm, demand, grift, and degeneracy, don't think that these things are a state attack on Ethereum, and somehow turn around and think that they're a state attack on Bitcoin?

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.

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:

• Any public discussion will consist only of the most engaged users. Many less engaged users simply won't be aware that a discussion is taking place, or might not participate, regardless of their views. These voices simply won't be heard. This includes people who aren't terminally online, many people who don't speak English as their native language, and people who just don't particularly like arguing online. This means that the bias must be strong towards the status quo,

• A programmer's job, fundamentally, is to drag his (or her!) balls through miles of broken glass if it benefits the user. Unless the status quo is so complex and unmentionable that it is untenable, disruptive changes must be avoided. As a spirited GitHub commenter put it, "Code and protocols get messy as they age. That's reality. Purity is for virgins."

What does this mean, practically?

• ord will commit to the stability of positive inscription numbers. Negative, or cursed, inscription numbers are subject to change at any time, if new cursed inscriptions are recognized.

• At some as-of-yet unannounced block height in the future, new inscriptions which would previously have been cursed will be blessed, and will receive positive inscription numbers as part of the main sequence of inscription numbers. Hopefully, this kind of community wide coordination is not a common occurrence, but it may happen again from time to time, if it is advantageous to recognize new kinds of inscriptions which previously would have been invalid.-

• The commitment to the stability of inscription numbers does not preclude the fixing of bona fide bugs. If there is a legitimate bug, and the only reasonable way to fix it proves disruptive to inscription numbers, we will fix it.

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:

• Complexity: How complex is the protocol? Is it easy to implement? Is it easy to adopt?
• User experience: Are there any implementation details which have a negative effect on the user experience? In particular, protocols that rely on off-chain data have a lighter on-chain footprint, but introduce a great deal of complexity, and require users to either run their own servers, or discover and interact with existing servers.
• State model: Protocols that are UTXO-based fit more naturally into Bitcoin and promote UTXO set minimization by avoiding the creation of "junk" UTXOs.
• Native token: Protocols with a native token which is required for protocol operations are cumbersome, extractive, and naturally less widely adopted.

Comparing existing fungible token protocols for Bitcoin:

• BRC-20: Not UTXO-based and rather complex, since it requires use of ordinal theory for some operations.
• RGB: Very complicated, relies on off-chain data, has been in development for a long time with no adoption.
• Counterparty: Has a native token required for some operations, not UTXO-based.
• Omni Layer: Has a native token required for some operations, not UTXO-based.
• Taproot Assets: Somewhat complicated, relies on off-chain data.

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.

Overview

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.

Transfer

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 the numeric ID of the run to assign
• OUTPUT is the index of the output to assign it to
• AMOUNT is the amount of the run to assign

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:

• ID 100, output 1, 20 runes
• ID 100, output 2, 10 runes
• ID 120, output 1, 5 runes

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.

Issuance

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.

Notes

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.

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 ordinals.com, 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:

• Multiple inscriptions per transaction
• Inscriptions in reveal inputs other than the first
• Inscriptions with new even fields
• Multiple inscriptions on the same sat

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:

• An inscription number now does not tell you anything about the order in which the inscription was made.
• The logic required to keep track of which inscriptions are cursed is a source of bugs and complexity.
• "Blessing" cursed inscription types, i.e., collectively deciding that after a certain block height, certain cursed inscription types will no longer be assigned negative numbers, and be assigned positive numbers instead, requires coordination.
• Cursed inscription numbers are permanently unstable, so a substantial number of inscription numbers are already unstable, even under the status quo.

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.

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

Inscriptions

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.

• action action action action action action action action action action action action
• agent agent agent agent agent agent agent agent agent agent agent agent
• aim aim aim aim aim aim aim aim aim aim aim aim
• all all all all all all all all all all all all
• ankle ankle ankle ankle ankle ankle ankle ankle ankle ankle ankle ankle
• announce announce announce announce announce announce announce announce announce announce announce announce
• audit audit audit audit audit audit audit audit audit audit audit audit
• awesome awesome awesome awesome awesome awesome awesome awesome awesome awesome awesome awesome
• beef beef beef beef beef beef beef beef beef beef beef beef
• believe believe believe believe believe believe believe believe believe believe believe believe
• blue blue blue blue blue blue blue blue blue blue blue blue
• border border border border border border border border border border border border
• brand brand brand brand brand brand brand brand brand brand brand brand
• breeze breeze breeze breeze breeze breeze breeze breeze breeze breeze breeze breeze
• bus bus bus bus bus bus bus bus bus bus bus bus
• business business business business business business business business business business business business
• can can can can can can can can can can can can
• cannon cannon cannon cannon cannon cannon cannon cannon cannon cannon cannon cannon
• canyon canyon canyon canyon canyon canyon canyon canyon canyon canyon canyon canyon
• carry carry carry carry carry carry carry carry carry carry carry carry
• cave cave cave cave cave cave cave cave cave cave cave cave
• century century century century century century century century century century century century
• cereal cereal cereal cereal cereal cereal cereal cereal cereal cereal cereal cereal
• chronic chronic chronic chronic chronic chronic chronic chronic chronic chronic chronic chronic
• coast coast coast coast coast coast coast coast coast coast coast coast
• convince convince convince convince convince convince convince convince convince convince convince convince
• cute cute cute cute cute cute cute cute cute cute cute cute
• dawn dawn dawn dawn dawn dawn dawn dawn dawn dawn dawn dawn
• dilemma dilemma dilemma dilemma dilemma dilemma dilemma dilemma dilemma dilemma dilemma dilemma
• divorce divorce divorce divorce divorce divorce divorce divorce divorce divorce divorce divorce
• dry dry dry dry dry dry dry dry dry dry dry dry
• elevator elevator elevator elevator elevator elevator elevator elevator elevator elevator elevator elevator
• else else else else else else else else else else else else
• embrace embrace embrace embrace embrace embrace embrace embrace embrace embrace embrace embrace
• enroll enroll enroll enroll enroll enroll enroll enroll enroll enroll enroll enroll
• escape escape escape escape escape escape escape escape escape escape escape escape
• evolve evolve evolve evolve evolve evolve evolve evolve evolve evolve evolve evolve
• exclude exclude exclude exclude exclude exclude exclude exclude exclude exclude exclude exclude
• excuse excuse excuse excuse excuse excuse excuse excuse excuse excuse excuse excuse
• exercise exercise exercise exercise exercise exercise exercise exercise exercise exercise exercise exercise
• expire expire expire expire expire expire expire expire expire expire expire expire
• fat fat fat fat fat fat fat fat fat fat fat fat
• fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch fetch
• fever fever fever fever fever fever fever fever fever fever fever fever
• forward forward forward forward forward forward forward forward forward forward forward forward
• fury fury fury fury fury fury fury fury fury fury fury fury
• garment garment garment garment garment garment garment garment garment garment garment garment
• gauge gauge gauge gauge gauge gauge gauge gauge gauge gauge gauge gauge
• gym gym gym gym gym gym gym gym gym gym gym gym
• half half half half half half half half half half half half
• harsh harsh harsh harsh harsh harsh harsh harsh harsh harsh harsh harsh
• hole hole hole hole hole hole hole hole hole hole hole hole
• hybrid hybrid hybrid hybrid hybrid hybrid hybrid hybrid hybrid hybrid hybrid hybrid
• illegal illegal illegal illegal illegal illegal illegal illegal illegal illegal illegal illegal
• include include include include include include include include include include include include
• index index index index index index index index index index index index
• into into into into into into into into into into into into
• invest invest invest invest invest invest invest invest invest invest invest invest
• involve involve involve involve involve involve involve involve involve involve involve involve
• jeans jeans jeans jeans jeans jeans jeans jeans jeans jeans jeans jeans
• kick kick kick kick kick kick kick kick kick kick kick kick
• kite kite kite kite kite kite kite kite kite kite kite kite
• later later later later later later later later later later later later
• layer layer layer layer layer layer layer layer layer layer layer layer
• legend legend legend legend legend legend legend legend legend legend legend legend
• life life life life life life life life life life life life
• lyrics lyrics lyrics lyrics lyrics lyrics lyrics lyrics lyrics lyrics lyrics lyrics
• margin margin margin margin margin margin margin margin margin margin margin margin
• melody melody melody melody melody melody melody melody melody melody melody melody
• mom mom mom mom mom mom mom mom mom mom mom mom
• more more more more more more more more more more more more
• morning morning morning morning morning morning morning morning morning morning morning morning
• nation nation nation nation nation nation nation nation nation nation nation nation
• neck neck neck neck neck neck neck neck neck neck neck neck
• neglect neglect neglect neglect neglect neglect neglect neglect neglect neglect neglect neglect
• never never never never never never never never never never never never
• noble noble noble noble noble noble noble noble noble noble noble noble
• novel novel novel novel novel novel novel novel novel novel novel novel
• obvious obvious obvious obvious obvious obvious obvious obvious obvious obvious obvious obvious
• ocean ocean ocean ocean ocean ocean ocean ocean ocean ocean ocean ocean
• oil oil oil oil oil oil oil oil oil oil oil oil
• orphan orphan orphan orphan orphan orphan orphan orphan orphan orphan orphan orphan
• oxygen oxygen oxygen oxygen oxygen oxygen oxygen oxygen oxygen oxygen oxygen oxygen
• pause pause pause pause pause pause pause pause pause pause pause pause
• peasant peasant peasant peasant peasant peasant peasant peasant peasant peasant peasant peasant
• permit permit permit permit permit permit permit permit permit permit permit permit
• piano piano piano piano piano piano piano piano piano piano piano piano
• proof proof proof proof proof proof proof proof proof proof proof proof
• pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin pumpkin
• question question question question question question question question question question question question
• real real real real real real real real real real real real
• report report report report report report report report report report report report
• rough rough rough rough rough rough rough rough rough rough rough rough
• rude rude rude rude rude rude rude rude rude rude rude rude
• salad salad salad salad salad salad salad salad salad salad salad salad
• scale scale scale scale scale scale scale scale scale scale scale scale
• screen screen screen screen screen screen screen screen screen screen screen screen
• sea sea sea sea sea sea sea sea sea sea sea sea
• seat seat seat seat seat seat seat seat seat seat seat seat
• sell sell sell sell sell sell sell sell sell sell sell sell
• seminar seminar seminar seminar seminar seminar seminar seminar seminar seminar seminar seminar
• seven seven seven seven seven seven seven seven seven seven seven seven
• sheriff sheriff sheriff sheriff sheriff sheriff sheriff sheriff sheriff sheriff sheriff sheriff
• siege siege siege siege siege siege siege siege siege siege siege siege
• silver silver silver silver silver silver silver silver silver silver silver silver
• soldier soldier soldier soldier soldier soldier soldier soldier soldier soldier soldier soldier
• spell spell spell spell spell spell spell spell spell spell spell spell
• split split split split split split split split split split split split
• spray spray spray spray spray spray spray spray spray spray spray spray
• stadium stadium stadium stadium stadium stadium stadium stadium stadium stadium stadium stadium
• sugar sugar sugar sugar sugar sugar sugar sugar sugar sugar sugar sugar
• sunny sunny sunny sunny sunny sunny sunny sunny sunny sunny sunny sunny
• sure sure sure sure sure sure sure sure sure sure sure sure
• tobacco tobacco tobacco tobacco tobacco tobacco tobacco tobacco tobacco tobacco tobacco tobacco
• tongue tongue tongue tongue tongue tongue tongue tongue tongue tongue tongue tongue
• track track track track track track track track track track track track
• tree tree tree tree tree tree tree tree tree tree tree tree
• trouble trouble trouble trouble trouble trouble trouble trouble trouble trouble trouble trouble
• twelve twelve twelve twelve twelve twelve twelve twelve twelve twelve twelve twelve
• twice twice twice twice twice twice twice twice twice twice twice twice
• type type type type type type type type type type type type
• uniform uniform uniform uniform uniform uniform uniform uniform uniform uniform uniform uniform
• useless useless useless useless useless useless useless useless useless useless useless useless
• valid valid valid valid valid valid valid valid valid valid valid valid
• very very very very very very very very very very very very
• vibrant vibrant vibrant vibrant vibrant vibrant vibrant vibrant vibrant vibrant vibrant vibrant
• virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual
• vocal vocal vocal vocal vocal vocal vocal vocal vocal vocal vocal vocal
• warrior warrior warrior warrior warrior warrior warrior warrior warrior warrior warrior warrior
• word word word word word word word word word word word word
• world world world world world world world world world world world world
• yellow yellow yellow yellow yellow yellow yellow yellow yellow yellow yellow yellow

We just released ord version 0.1.0!

ord is an ordinal number wallet and the index that serves ordinals.com.

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.

Ideas for a new Bitcoin testnet:

• Cool, cyberpunk branding and design, so people pay attention to it and want to use it. I suggest "The Bitcoin Chaos Network" or "Bitcoin Chaos", for short. Black and white branding with no Bitcoin orange in sight.

• Trading coins for money is encouraged.

• Proof-of-work mining identical to mainnet. No testnet fast difficulty adjustment.

• Development policy of including anything that has a reasonable chance of being merged into core.

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.

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:

• Rare ordinals shouldn't accidentally be lost to the recipient or the fee.
• The ordinal being sent should be aligned to the beginning of the output going to the recipient.
• Additional postage should be added so that the ordinal can be sent onward without needing to merge in additional UTXOs.
• Excess sats should be stripped from the recipient's output.
• Inputs and outputs must be aligned so that the ordinal being sent actual makes it to the recipient.

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:

• This transaction is simple send of mvzwjdjcofe. The first output is change, added to ensure that mvzwjdjcofe is the first ordinal in the output sent to the recipient:

  ord wallet send mvzwjdjcofe tb1qaykcryeds0kmz3azv5tn46dyt3wu5l5qc3djz0

• This transaction sends ordinal nphhwymyrjx to tb1qew25cz5603xqzkw66m5yq9ruflkkpgjyprcdc5:

  ord wallet send nphhwymyrjx tb1qew25cz5603xqzkw66m5yq9ruflkkpgjyprcdc5

  nphhwymyrjx is first in the input, so no alignment output is needed to make it first in the recipient's output.

  However, the input is quite large, so an additional output is added that brings the size of the recipient's output down to 10,000 sats. We could reduce the size of recipient's output to the dust limit, however in that case, UTXOs would need to be merged in to pay for fees when sending the ordinal onwards.

• This transaction sends ordinal 139761296637063 to tb1q02yk08hkp9pkyhwdsdfd0ra437tjcdnrjs0sxv:

  ord wallet send 139761296637063 tb1q02yk08hkp9pkyhwdsdfd0ra437tjcdnrjs0sxv

  There's a lot going on here! Let's break down the inputs and outputs:

  Inputs:

  1. Contains 139761296637063 at offset 7,500.
  2. Needed to pay for all outputs

  Outputs:

  1. Change containing 7,500 sats to make 139761296637063 the first ordinal of the recipient's output.
  2. The recipient's output containing 139761296637063 at offset 0. Worth 10,000, so that the recipient can forward 139761296637063 without needing to merge in additional UTXOs.
  3. Change containing 16,006 sats, to reduce the recipient's output to 10,000 sats.

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!

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

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.

Archaeology

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.