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 that ord list produces the correct results even when a block destroys fees and underpays the subsidy.

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

😂

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();

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

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.

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.

How many sats destroyed determines how cursed.

• 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

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

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.

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

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 [,)

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?

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.

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.

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

Maybe call this a "sat point" or something.

TXID:OUTPUT:OFFSET

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

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

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.

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

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.

• 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

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.

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

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.

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.

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

• 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

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.

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.

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