At block height 783,968, the BSV community started creating 1 Satoshi Ordinals (1SatOrdinals), which are essentially non-fungible tokens (NFTs) with a globally recognized serial (inscription) number. Former FYX Gaming CTO David Case has been at the forefront of building infrastructure for 1SatOrdinals. I caught up with him to ask some questions about the protocol, APIs, and the excitement around the new token protocol.
Why implement Ordinals on BSV?
Although there have been, and are still, some frustrations with building on BSV, it remains the only option when looking at how to build a scalable public, proof-of-work (PoW) blockchain solution. Satoshi knew what he was doing, and BSV is the Bitcoin implementation that truly embraces the scope of providing Bitcoin on the scale required to support all of humanity.
As someone who has had the most hands-on development with RUN, how does 1SatOrdinals compare?
1SatOrdinals tries to accomplish much less than RUN does. RUN provides a means for defining complex rules of how the state of a token is transformed. A RUN jig can apply nearly any state change rules you can desire. It does so by encoding a data structure into every transaction. If you understand the encoding, you can replay a set of transactions to validate the object’s state history. It does this with a JavaScript-based virtual machine, which is very powerful but heavy and requires a complex, layer-2 indexer to make sense of any data stored within the jig.
1SatOrdinals, on the other hand, is much simpler. You can inscribe data onto an existing satoshi and transfer ownership of that satoshi to another individual in the same fashion that you can transfer any other bitcoins. It relies on the immutable characteristics of Bitcoin to allow for more complex use cases, but with much simpler indexing requirements.
I think its funny watching things play out. BSV devs held their nose implementing inscription numbers on @1SatOrdinals. Check the date 😂 @shruggr pic.twitter.com/xShvFYWKJD
— Luke Rohenaz (@wildsatchmo) April 11, 2023
You have publicly stated that Inscription Numbers are dumb. Can you elaborate?
Ordinals are defined by the fact that if you follow a chain of Bitcoin spends back in time, you will eventually find a point where the satoshi you are tracking came into existence. That value is Satoshi’s Ordinal Number. This is a provable value that can be calculated for every satoshi individually, without any other context than that one satoshi’s recorded history of spends.
On the other hand, an Inscription Number is a sequence number of when a single satoshi was inscribed in relation to when all other inscriptions exist. This becomes a complicated thing to measure, and will only become more problematic as the blockchain grows. It requires an exact and concrete definition of what counts as a valid inscription.
Any ambiguity at all allows for different indexers to determine different counts based on how they’ve implemented handling of edge cases and doesn’t allow for future clarification of the interpretation of those rules without renumbering the entire set of inscriptions. Fixing indexing bugs renumbers all inscriptions. Even without edge cases and bugs, it is still dependent on indexing the entire blockchain throughout all of history in order to validate the Inscription Number is correct.
If there is a need to rank inscriptions by how OG they are, there is a much better measurement to use, which will never change, and that is the block height of when it was mined and what index the transaction can be found in that block. This value will never change, no matter if rules are updated to include a transaction which had been excluded previously, but it provides absolute sequencing for which ordinals were inscribed first.
What is OrdinalLock?
OrdinalLock is a Bitcoin script I wrote in sCrypt to allow on-chain listings of Ordinals for sale. It was heavily influenced by the OrderLock script written by RelayX for use with RUN tokens.
An ordinal is transferred from a user’s wallet to be owned by an OrdinalLock Bitcoin Script. This script is constructed which allows the output to be spent in one of two ways:
- Spending the output in a transaction that pays a specified amount of satoshis to a specified recipient, thus completing the sale.
- The user who initially listed an item can choose to un-list it anytime.
With this approach, the listing user does not need to sign off for a sale to be completed, but it also allows the user to cancel a sale at any point, up until the point where the sale is fulfilled.
BTC is leveraging PSBT (Partially Signed Bitcoin Transactions) in their marketplace implementation for Ordinals. How do these compare to Ordinal Lock, which is implemented directly in Bitcoin Script?
They are very similar in what they accomplish, and even how they accomplish it. The main difference is that OrdinalLock is created in a finalized Bitcoin transaction that has been broadcast to the network. This allows a fully decentralized exchange, in that anyone who crawls the blockchain and finds this transaction has everything they need to complete the sale of the item.
PSBTs are different in that the listing transaction and the purchase transaction are the same transactions, but at the time of listing, it is not yet a valid, finalized transaction. The transaction is not broadcasted on chain, and it requires an off-chain layer to publish these listings and for other people to find them and execute the sale. This leads to a potential fragmentation of market inventory as different marketplaces may use different means of sharing and aggregating listings.
I’ve actually gone back and forth as to which of these technologies is actually better, as they are very similar, but there is definitely a strong desire for a public-by-default approach to a marketplace in the community. I’ve been working on OrdinalLock to facilitate that desire.
What has been the biggest challenge in implementing an indexer for Ordinal transactions?
The biggest technical challenges come from the unlimited nature of BSV. By far, the most complex logic of calculating ordinal numbers occurs when Satoshi has been used to pay transaction fees for a transaction earlier in its life. In a worst-case scenario, calculating this requires performing analysis on every transaction in a block and every one of those transaction input transactions. If the block is limited to 1MB in size, this is a trivial process, but when blocks can be 4GB in size, it requires an entirely different approach, and a 1TB block will likely require a different approach.
These problems can be greatly alleviated if certain information is indexed for all blockchain transaction history. With a few exceptions, this data is the same data a block explorer already indexes, such as the amount of fees each transaction has paid.
This full indexer is still a work in progress, but luckily, there are some shortcuts available on BSV which also give us the ability to have performant indexing of Ordinals without the full indexer, and one of those is the root of the name 1SatOrdinals. Unlike other UTXO-based chains, BSV allows for outputs of 1 Satoshi.
By limiting the current indexer to only indexing 1 Satoshi outputs, we can greatly reduce the amount of data we need to process to prove that multiple spends of a Satoshi are indeed the same Satoshi. We do not yet calculate WHICH ordinal number, but we prove that multiple spends apply to the SAME ordinal. This allows us to fully interact with the ordinals before we can actually calculate which ordinal you are interacting with.
How has GorillaPool’s JungleBus helped index Ordinal transactions?
JungleBus provides an easy feed of all transactions containing an inscription and a feed of all transactions with 1 Satoshi output. This allows the indexer to filter down the data, which must be processed by several orders of magnitude.
To help out those who don’t understand Bitcoin ordinals. Imagine literally owning your web site, social media pages. You make updates by spending the asset and updating with new content.
— David Case shruggr @114 (@shruggr) March 19, 2023
The concept of re-inscribing a Satoshi seems fascinating. Why is this better implemented with Ordinals vs. MetaNet, RUN, or other token protocols?
This is probably the area I’m most excited about. Owning and managing your on-chain file system by simply spending the Bitcoin in your wallet and inscribing files containing links to other inscriptions is very intriguing. You can use updatable ordinals to implement publishing and subscriptions. You can implement permissioned publishing. You can implement source control systems. You can implement RUN-like state machine systems. The applications are endless, and the groundwork is already in place to accomplish these things.
I’ve already built out tooling to allow a user to point a tool at a directory on their computer and have every file and sub-directory contained within that folder to be inscribed on-chain in such a way that another user can download that same data by simply pointing to the root ordinal of the directory. With just a bit more work, filesystem syncing becomes a reality. From there, publishing updates is as easy as editing a regular file with regular applications on a regular computer.
All three of these token approaches could allow this functionality. The advantages of doing so with Ordinals is mostly due to the lack of publicly available indexers for the other technologies and the more complex and costly infrastructure required to do so.
With RUN, transactions can’t really be indexed in isolation, and it ends up requiring the indexing of all RUN transactions that have ever been to determine the state of a single transaction.
Additionally, RUN can generate significantly larger amounts of state data than those contained in the transactions themselves. This data needs to be persisted, and transactions can be constructed in such a fashion to act as a DOS attack against anyone attempting to maintain a global index. These issues make it very cost-prohibitive and risky to run public infrastructure.
Other than lack of adoption, the MetaNet protocol’s drawback to handling updatable inscriptions is that order of operations with MetaNet transactions is not really compatible with zero-conf. If multiple transactions are made interacting with the same MetaNet node in the same block, the order of those operations cannot be determined until after the transactions have been mined and they are deep enough in the chain to avoid the risk of chain reorgs.
Until then, knowing which transaction will be mined first is impossible. If you make a mistake you want to correct, it will take an hour or so before you can feel confident that your correction will indeed happen AFTER the mistake. Otherwise, there is a risk that the fix could be mined before the mistake, and you will still need to correct it again.
What is the top lesson you have learned over the past month being heads down developing with 1SatOrdinals?
This is not a new lesson, but it reinforced how complicated it is to work on multiple endeavors at the same time. There are many powerful ways to utilize ordinals as a token standard, and many things I’d like to build which are really cool and I think would be very interesting to the community, but all those things compete with each other for love and attention. The risk of focusing on the wrong things and wasting time on something no one will ever use is easy to do.
What feature or application do you think the non-technical BSV users need the most about 1SatOrdinals?
All the things which can be accomplished with updatable ordinals. This holds the power to revolutionize everything from podcasts to publishing to web hosting to social media. Owning your data, your website, your feeds, your bookmarks, and subscribing to those of friends. In my mind, this is the killer feature.
Thank you, David, for taking the time to answer my questions. I hope the readers learned more about 1SatOrdinals. Check out the protocol documentation and get your free wallet today at 1satordinals.com.
This article was lightly edited for grammatical and clarity purposes.
Watch: Ordinals on BSV! Luke Rohenaz explains their Utility and Value on the CoinGeek Weekly Livestream
width=”560″ height=”315″ frameborder=”0″ allowfullscreen=”allowfullscreen”>
New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.
