Nummerdämmerung

[casey]

Currently, tracking ordinal locations has a lot of downsides:

• The index takes a long time to sync, currently around 12 hours on fast machines with 64 GiB of RAM.
• Sync time appears to be increasing super-linearly with the number of blocks and transactions.
• The index takes a huge amount of disk space, somewhere between 55 and 120 GiB.

I think we should be cognizant of these downsides. I think they're significant, and could affect the long-term viability of the project:

• Such large resource and time requirements might turn off large numbers of users.
• It may be impractical to run an ord node on Raspberry Pi 4s, which would exclude large numbers of hobbyist node operators who use projects like Umbrel and RaspiBlitz.
• Even if the project is successful, then the resources required to run a full ord node might mean that many more users interact with ordinals and inscriptions using clients with reduced security, i.e. with a MetaMask-like security model where you connect to a third-party node and trust it to tell you the state of the blockchain.

What are the advantages of tracking all ordinal locations?

• We can use ordinals in our UI. If two inscriptions are on the same ordinal, we can identify the ordinal that they are attached to.
• People find ordinals quite charming and aesthetic. They like the idea of every sat having a serial number, and of being able to see them on the explorer.

What is an alternative to tracking ordinal numbers?

Instead of explicitly tracking ordinal locations, we could instead simply track the satpoint of each inscription. That is to say, we would still use exactly the same transfer algorithm, but we would no longer store, in the database, a mapping of UTXOs to ordinal ranges. On each inscription transfer, we would store the new satpoint it occupies and that's it.

Let's call the two modes "full" mode and "slot" mode. In full mode we track ordinal numbers, in "slot" mode we only track which "slot" inscriptions are in, but don't know the ordinal number in that slot.

Why should we think about this now? Can't we just add "slot" mode later where we don't track ordinal numbers explicitly?

• There might be a lot of code churn. Currently the wallet code expects to be handed ranges of ordinals in order to make decisions about how to split things. If we must support slot mode, then all this has to change to use satpoints.

• We have to make sure that we don't accidentally introduce dependencies on knowing ordinal numbers in the UI. For example, ord wallet send currently takes an ordinal number. We would have to check if the index was being run in "slot" mode and return an error if the user tried to send using ordinal numbers.

• User confusion. Have to explain the difference, and explain to users why their ord instance in slot mode, if that's the default, doesn't look like the ordinals.com instance.

• We might make design or protocol decisions that rely on knowing ordinal number, and then users in slot mode would face a degraded user experience.

• Retraining users on the new UI may be challenging.

Why don't we remove the transfer algorithm entirely, and use a UTXO-based scheme that doesn't rely on slots?

I actually think the ordinal transfer algorithm works well and has strong advantages. In practice, this seems to work well. We've done transfers on signet and mainnet, and users have successfully submitted bounties. A UTXO-based scheme would have to use some other mechanism for indicating how inscriptions in a transaction would transfer to outputs. The two options I've thought of are something based on the hash of the transaction, or using OP_RETURNs. Using the hash of the transaction would be quite weird, and would require grinding the transaction hash in order to get the inscription distribution you wanted. Using OP_RETURNS is an option, but I haven't come up with a scheme there that's obviously better than the existing transfer algorithm. Also, we've kind of come this far, so it would be way less work to try out slots and see how it goes than retool entirely.

The Proposal

Stop building the OUTPOINT_TO_ORDINAL_RANGES table by default, and rework ord such that it doesn't require that table to work. We could do this now, or we could do this after the production inscription milestone. Reaching the current milestone would give users a chance to fool with the project in its current state, and get more feedback on it. However, it might be a bit of a dead end.

What do you think @raphjaph @virtuallythere @WILDM4N? This would be a big change, so we shouldn't take it lightly. This is all thoughts I've been having over the last few days, so I'm not incredibly confident about any of this.