Bringing Ordinal functions to the legacy BSV Java Script library

Getting your Trinity Audio player ready...

The 1 Sat Ordinals protocol now has over 37 million inscriptions as of writing on the BSV blockchain. Upon its launch in March 2023, the tools to build on the protocol were open-sourced to get other developers to build atop it. However, this tooling was released leveraging relatively new BSV blockchain development libraries such as bsv-wasm or go-bitcoin. Before the creation of these libraries, the bsv JavaScript library created by Ryan X. Charles and MoneyButton was widely adopted in the community due to its basis on the popular (at the time) bitcore library created by BitPay.

Another reason the BSV library was widely adopted was its ease of installation. Whether on the server side via NodeJS and NPM or in the browser by simply referencing it via a script tag, developers could easily use this library without any other custom or third-party tooling such as webpack. Recognizing this, I decided to write a helper library leveraging the BSV legacy library that implements the 1 Sat Ordinals functions.

I've implemented 1 Sat Ordinals and Global Order Book functions using the bsv legacy library – intended for Client side, Browser use.

Can checkout the code / library here: https://t.co/Npz09qhKnf

Any feedback is appreciated!

— shua (@cryptoAcorns) August 23, 2023

The intent is to simplify further and encourage developers to build atop this highly used protocol. Now, developers can simply open a few text files and start inscribing in the web browser. The oneSatOrdinals.js library includes functions to inscribe and send ordinals and pay for any type of Bitcoin transaction.

More importantly, each Ordinal Lock function interacting with the Global Order Book is implemented, abstracting the heavy workload of dealing with Bitcoin Script. Now, developers can call functions, specifying a few parameters to list, cancel, and purchase inscriptions on-chain.

These functions are designed to be used on client machines where private keys are stored locally in the browser. This method follows the trend of the 1 Sat Ordinals wallet, Aym, Twetch, RelayX as well as wallets and markets on BTC. Storing keys in the browser typically have the same security as storing them on the client device, where typically, the only means to hack are clicking links from attempted phishing attacks or compromising the device itself.

To get more innovation going more quickly, we do not want developers spending time on low-level functions that are tricky to deal with or to necessarily understand the nuances of solving custom Bitcoin Scripts. Ideally, we want the developers to use tested, abstract functions where they and their users still retain complete control of their coins and tokens via their private keys. This ownership model also de-risks the application from a security perspective in terms of custody of user funds.

Furthermore, we want to de-risk applications of third-party dependencies and vendor lock-in. Applications should interact directly with the blockchain, where if one blockchain API goes down (RUN, MatterCloud, Planaria), they can simply switch out the URLs (to JungleBus, WhatsOnChain, Bitails, or any new one that comes out) instead of re-tooling their entire application.

Like Bitcoin, we need to build applications that can stand the test of time. If one company goes bankrupt, yet Bitcoin still produces blocks, then the application that implements the protocol should still be operational. Unfortunately, many applications have died because of these risks and dependencies. While the BSV blockchain still remains in a severe bear market, survival is key as we never know when that can reverse, and a newcomer may find value in that alleged “dead” application.

CoinGeek Roundtable with Joshua Henslee: 1Sat Ordinals on Bitcoin