ordinals/ord

👁‍🗨 Rare and exotic sats

ord's Issues

Scarcity

Atoms, as currently devised, are extremely scarce. Currently, it works out to around 1 atom per 26 bitcoin. This is good and bad. Atoms are scarce, so more likely to have and hold value. However, their scarcity means that, if you need an atom to mint an NFT, for example, you might have to pay a lot for the privilage.

Alternatives:

• One atom per coinbase output. Allows more atoms to be created if there's more demand.
• Fractionalization schemes.
• Multiple tiers of atoms. Tier 0: One per block. Tier 1: One per coinbase output. Tier 2: One per transaction output of every mined transaction. T0 is scarce and inelastic supply. T0 is less scarce, and production can respond to demand. T2: Absurd amounts, more than anyone could every one.

One possibility is that every output of every transaction of every block creates an atom. Numbered BLOCK.TRANSACTION.OUTPUT. If output is zero it can be omitted. If transaction and output are both zero, they can be omitted. What emerges is something similar to Urbit's address space, where shorter identifiers are scarcer and more valuable.

Atom Traits

Atoms have traits. There are many traits, some interesting, some not. More traits are being discovered at a breakneck pace.

Many traits are based on an atom's sire, the block in which an atom was crated. Some traits are based on hosts, the coins that have carried a specific atom.

Discovered traits:

• Domain: The sire's height
• Order: The index of the block in which the transaction creating the atom was created
• Species: The index of the output in which the atom was created
• Epoch: The sire's reward epoch
• Parity: Whether the sire's height is even or odd
• Difficulty: Sire's difficulty target
• Overkill: Sire's difficulty target - sire's hash
• Richness: The number of atoms moved in the sire in which the atom was mined
• BDD: For each previous host, the number of bitcoin days destroyed when that host was destroyed, summed together
• Worth: The highest value of all the hosts that the atom has been attached.
• Path: The list of block heights in which an atom was moved.

Hypothesized traits:

• Codepoint: Some mapping from serial number
• The unicode codepoint of the atom. The mapping of atoms to codepoints is currently unknown. There are 16 planes, so there would be some mapping of domain, order, and species to plane and then codepoint. Many atoms would have an unallocated codepoint, which is fine.
• Word: Given some list of words in a canonical order, it might be possible to associate a word with an atom. This would be hard. Could also have multiple words. This could be used as a username or a domain.

Avoid the word apportion

A little birdie told me that it sounds like the atoms are getting divided up.

Make sure what happens when subsidy and/or fees are underpaid in a block is well-defined

Trait for first satoshi of epoch and difficulty adjustment period

• Satoshi 0 of each block: shiny
• Satoshi 0 of each difficulty adjustment period: ?
• Satoshi 0 of each epoch: ?

Pick emoji

Test `ord list` with multiple output ranges

Currently, our tests only list outputs with single ranges. We should test that we can list outputs which have multiple ordinal ranges.

Don't crash on empty blocks

We currently crash on blocks that don't have a coinbase transaction. We shouldn't.

Project name, number names

sat-tracker isn't the most exciting name, and talking about "satoshi numbers" isn't great either. I'd like to come up with a slightly sexy name for the project, and a way of referring unambiguously to a satoshi's number. For the former, I have no idea, but for the latter I was thinking about calling them "ordinals" or "ordinal numbers". An ordinal number denotes the position of an item within a set, so seems perfect for this, which identifies the order in which a satoshi was created. The word "ordinal" isn't used anywhere else in Bitcoin, so it isn't ambiguous.

Shill

Allow find command to take slot

Test `ord list` fee assignment to coinbase

Write a test that shows that ord list correctly assigns ranges in fees to the coinbase transaction outputs.

Can we rely on the first block in the first blockfile being the genesis block?

This would be nice to avoid hard coding the genesis block in tests, and also make the ord command work with regtest, testnet, etc blockfiles without further configuration.

Print offset into output

Maybe call this a "sat point" or something.

TXID:OUTPUT:OFFSET

Does this damage Bitcoin's fungibility as a currency

If I have a wallet with multiple utxo's, I would have to be careful to not spend the utxo's associated with more valuable atoms, right?

List command

sat-tracker list OUTPOINT should print the list of satoshis on particular output.

Figure out transmutation algorithm

It should be possible to commit a 256 bit value to an atom. It's okay if this has happened to atoms historically, and random values have been committed to them, since you can also undo transmutation.

NFT signing

• It should be possible to sign NFTs with a hardware wallet
• It should be possible to derive different signing identities from the same hardware wallet seed, that can be used for different purposes

Name for project

The idea has been simplified and now atoms aren't a thing, it's all based on numbering and tracking individual satoshis. So bitcoin-atoms isn't the best name.

The project consists of:

• a BIP for numbering and tracking satoshis
• a command-line tool for tracking satoshis

Make list fast

Fix find command: use descending numbering scheme

Test `ord list` range splitting

Write a test which shows a subsidy range getting split and appearing in two different outputs.

Document use for stablecoins

A stablecoin issuer could agree to redeem certain satoshis for the value of $1 + 1 satoshi, thus issuing a stablecoin that could transact on base-chain bitcoin.

Test underpaying subsidy

Test that ord list produces the correct results even when a block destroys fees and underpays the subsidy.

Bech32m encoding for satpoint

Current name traits assigns short names to coins that will most likely never move

The current name trait produces short names at lower block heights. As a result, the shortest names were created in early blocks.

This is unfortunate, since it's very likely that early blocks will never move, so early names will never be available for use.

We could:

• Make it so that names start at the longest name possible, and get shorter as time goes on.
• Number satoshis in reverse, so that the first satoshi mined has number 2099999997690000 and the last satoshi to be mined has number 0. This is weird, but it fixes the problem for all traits, so the name trait doesn't have to be a special case.
• Just ignore the problem, and resign ourselves to the fact that short names are probably locked forever.

Index full mainnet blockchain

Add a command that prints out the number of coins per atom

Figure out best transfer algorithm

The current algorithm is biased towards assigning atoms to later outputs in a transaction.

For example, if transaction has as single input worth 10 carrying atom 0:

# inputs and outputs are `[satoshis, atoms]`
inputs = [[10, 0]] # one input carrying 10 sats and atom 0
outputs = [[5], [5, 0]] # an output carrying 5 sats and no atoms, and an output carrying 5 sats and atom 0

It seems like it would be a bit more "natural" to favor earlier outputs.

The ideal transfer mechanism would, when naively used, distribute atoms proportionally to satoshis, but could be abused to move atoms around more intentionally.

It could use something which is usually randomly distributed, like the last digit of the satoshi value of outputs, to perturb the allocation.

Reconsider descending numbering

I'm thinking that descending numbering is possibly a mistake. It's intended to fix the problem that satoshis with short, desirable names were mined in early blocks, which presumably won't ever move. We could fix this by defining the naming scheme to go from long to short, instead of reversing the numbering of all satoshis. I think this would be better, since ascending numbers feel more natural and are easier to explain. Using ascending numbers would mean that desirable numbers, like single-digit satoshis, were mined in the genesis block, which is still unfortunate. However, it might be worth the additional simplicity. After all, what's short doesn't really matter, what matters is what's rare, and short, low numbers will still be rare, they'll just be longer than otherwise. Additionally, it'll be exciting to see if early blocks suddenly move, which would lower the floor on the length of sat numbers.

Trait ideas

• Character trait: Map atom to a unicode character.
• Unlucky: all 13s
• Cursed: ???
• Blessed: ???
• Blast crater: the satoshis adjacent to the one which would have been which was destroyed in block 124724

Consider renaming back to atoms

😂

Bug: Handle multiple atoms per coin

My code assumes that there's at most one atom per coin, in particular:

let mut atoms: BTreeMap<OutPoint, u64> = BTreeMap::new();

It should be:

let mut atoms: BTreeMap<OutPoint, Vec<u64>> = BTreeMap::new();

Is it safe to rely on the `blocks` dir containing good blocks?

What assumptions can we make? I originally was using the JSON API, but that was slow and flaky, so I started reading the blocks files directly. If we don't get good guarantees from that, we might have to switch back to an API.

Test spending and transactions with the same transaction id

There are duplicate transactions in the bitcoin blockchain. Test that they can be indexed and spent.

Use bitcoin::Amount for all satoshi amounts

Discuss social legitimacy of NFTs

It isn't commonly articulated, but NFTs are judged based on social legitimacy, which is hard for people to grok.

If Bob mints an NFT using an original work of art, that NFT is highly legitimate, and may have value. If Bob mints an NFT with someone else's art without permission, that NFT is highly illegitimate.

Atoms are an attempt to create the most legitimate possible NFTs.

Make integration tests more specific

Currently, we use the same chain and transactions for all integration tests. Instead, use whatever chain and txs are needed for that specific test.

Make find fast

Remove superfluous traits

I should remove all traits that aren't pulling their weight.

Refactor into library

Ordinal-aware wallet derivation paths

Strongly suggest that ordinal-aware HD wallets use different derivation paths for all outputs, and to never mix ordinal-aware outputs and transactions with non-ordinal aware outputs and transactions.

Perhaps even come up with and suggest the use of a specific distinct derivation path.

Mutable traits

• Path: List of block heights in which a satoshi was moved, including the block in which it was mined
• Wealth: Value of the largest utxo a satoshi was contained by

Consider positive and negative impacts on the Bitcoin network

Allow invalid ordinals

I think statically checking that ordinals are in range is a bad idea. Ordinal range of post-subsidy blocks can't be represented, it makes the code messier, it forces starting_ordinal functions to return an option, etc. I think I should just do validation on the edges but not in the code.

Also make last name a and not ``, so that we can represent the ending range of names as [,)

Add test for SatPoint::from_transaction_and_offset

Add find command

New cursed sats in blocks that underpay the subsidy

How many sats destroyed determines how cursed.

Document use in lightning

Two lightning nodes could open a channel using only ordinals which were pledged to be NFTs and transact using it via lightning. You could thus transact with stablecoins, or even a wrapped alt-coin on lightning.

Test that index can handle out-of-order blockfiles