BSV as a dynamic ecosystem

Getting your Trinity Audio player ready...

One of the key features of Bitcoin SV which allows it to adapt and thrive without the need for administrators, core developers or benevolent dictators is the fact that it doesn’t try to do anything besides the basic task of being a public traceable indelible record keeper. All other features, needs, requirements, can be done outside of the protocol, and should be, through the process of entrepreneurial capitalistic free market services developed by individuals or corporates.

But first…

To compare BSV and the old BTC is already quite futile. They are no longer comparable. One is still a ‘cryptocurrency,’ appealing to the anti-establishment counter-culture crowd intermixed with a get-rich-quick scheme, with a dash of some old radical economic theory added for taste. The other is an innovative technology platform, vanilla, bland, but open to countless possibilities to those who recognize its power and potential.

The respective communities and narratives are already incomparable. While BTC chat forums team with those speaking about monetary sovereignty, and overthrow of the existing social-economic regime, BSV discussions are always about new business models and ways to capitalize on new micropayment applications. While BTC users talk about avoiding government control, BSV discussions center around the concern of potential non-compliance actors to existing laws which may hamper their businesses or industry reputation. It’s cliché to say they are like comparing apples and oranges now, it’s more like apples and iPhones.

But, as a price for scalability, BSV has adopted the original Bitcoin mantra of unbounded scaling, which means, no limits on the block size, and recently, the market has responded with such a flood of transactions and uses on BSV that the average size which used to be around 10MB, has risen to 135MB, while BTC remains at their self-imposed restricted world of 1.1MB. So what does it mean to have a blockchain 135x more energy efficient?

For node operators, it means there is a constant strain on the network while constantly investing to maintain the performance and keep users happy. This has recently shined a light on the worry that storing raw data on-chain will soon not be tenable, not at least without a new actor appearing on the economic stage in order to shoulder the increasing burden.

Data has historically been stored on provably unspendable outputs of bitcoin transactions. These are colloquially called “OP_RETURN” outputs. This is where most data protocols on BSV will put their data. But because these outputs are unspendable, there is no reason that miners will need to store these transactions perpetually. Not unless you paid them to, but there would be no way for one to collectively incentivize ALL mining nodes to store your data, because there is simply no way for you to pay all of them for it. Indeed, you only need ONE node to store it, why would anyone want to pay EVERYONE to store it? That makes little sense. (Though it is worth mention that in the crazy crypto world there ARE those who view society through such a distorted lens, that they do believe that somehow the miners are fully, fairly, collectively compensated for storing everyone’s data simply because the txn paid the initial fee… we tend to ignore these outlier voices). So it has been hypothesized many times in the past about what kind of business would pick up the slack of storing data on chain, acting as an ‘archival node service.’ In fact, I already wrote at length about it here. Go on, refresh your memory on that, I’ll wait.

Well, the time has come. It is no longer just theory. Blocks have gotten so large that unpaid indexing services (such as ElectrumX) that much of the community have relied upon until this point are starting to falter. They can no longer justify maintaining running their full nodes without some sort of compensation. This is fine. This is part of the Seldon…—ahem, Satoshi plan.

Recently in a Medium article by Long Li which introduced URCHAIN.com, a new block explorer for BSV, he mentioned how he would NOT store many OP_RETURN output formats, and in fact prune much of what is kept on their nodes, due to the size limitations. When I read that, I felt it was the signal of the turning point where theory becomes reality for the archive node business. As more block explorers wean themselves off the traditional naïve node implementations which store everything, there will be an overnight demand created by businesses that may have accidentally started business models where they assumed storing data on chain would be free forever (in short, they displayed ignorance of simple economic concepts such as Tragedy of the Commons) and will be in need of a bail out. Archive services can happily facilitate this bail out, for a price, of course. Vive Capitalism!

So how could you run an archive service? Would it require massive amounts of hardware? Development resources? Money? Not really. Storage is cheap depending on its accessibility profile. RAM or SSD storage is expensive, but HDD are cheaper, and tape drives even cheaper than that. So working out a system that would shunt most of the historical data of the BSV blockchain to cheap ‘glacial’ storage is a no brainer. AWS even has storage solutions that offer offline or slow storage for very reasonable prices. But how to earn profit by running an archive API as a service? Well, the simplest thing would just be to run existing block explorer APIs, but over API proxies such as Codugh, which allow for per-request payment for API servers. That way you can be paid for your txn archive service via a simple EC2 API server running on Amazon, with some txn filtering.

But if you really want to do it the ‘bitcoin’ way, you could write a library that would form any request for a historical transaction as a hash puzzle bounty transaction, which would embed some amount of bitcoins into this hash puzzle locking script. The hash puzzle is simply a hash match for a pre-image of the txn that you wish to retrieve from an archive service. Whoever on the network is listening to these archival txn requests, would see this request, retrieve the txn from storage, and post a new txn that pays themselves the bounty while embedding the requested data (the txn) as the unlocking script. The recipient then just sees and grabs the new txn with the historical txn attached. No business contract required. Pay per use. Micropayment business model!

If built into a simple library, any application would be able to both request or serve (and get paid for) retrieving historical txn data. This is the decentralized—nay, free market solution to the issue of miners not storing forever unspendable outputs on the blockchain. And the solution is beautiful, because it isn’t centrally planned, it isn’t a feature put in by protocol developers, it is simply the system participants as a whole reacting and dynamically adapting in a capitalist fashion to meet a new demand. All because there is profit incentive driving the development, and that is indeed the true innovation of Bitcoin.

There is one question though, how would clients recognize a archival txn request transaction among a sea of other transactions? There seems to be room for a txn template standard by which transaction types or templates can be recognized or designated. This is something that I have been working on myself, and there are some solutions that I may soon reveal. Or perhaps the ecosystem will discover a method without any help. That is the nature of an organic dynamic living breathing network. We all do our part, but the ecosystem is dependent on no one individual.