The future of blockchain services
This post originally appeared on Medium and we’ve republished it with permission from Roger Taylor. Read the full piece here.
We are in the early days of Bitcoin adoption, and it is not clear at this point what the long-term adoption will look like. One aspect of this can be seen in the blockchain services that application developers require to build their applications on.
The old approach
When Craig left Bitcoin to his own devices, development went in an impractical direction due to the technological appeal of the developers. Because the block size was small, it was possible to index the entire content of the blockchain, this meant that applications could ask an indexing service to tell them about the existence of transactions with payments they thought they might have made.
There were a lot of cool technological things about this approach. You can have seed words and use them to find all the payments you’ve ever received, and from those, find all the payments you’ve ever made. Not only did this act as a reliable form of backup, but by using the blockchain as a source of truth, you could have the same keys in use on different computers, and the applications on the different computers would be synchronized to have the same content. It was and is very user-friendly and practical, but it is unfortunately only possible on blockchains which prevent actual use and which can only be used for simple payments.
The legacy approach provides a user experience that is an illusion created by locking down the blockchain protocol and preventing both large blocks and the creation of free transactions. If the blocks get bigger, the indexers can no longer be run for free by anyone willing to cover the nominal cost. If payments can be freely made without conforming to the limited set of basic templates (represented by addresses), it will no longer be possible to search the blockchain for all your sent and received payments. If there are no free indexers and which indexers cannot be used to find all your payments, there is no magic backup or sync.
The Bitcoin Core developers had to break the Bitcoin protocol to make the old approach work. To have cool illusions, you must prevent adoption.
The approach of the future
Without full chain indexing, we now require blockchain services that serve the needs of a restored protocol. It is now widely accepted that payments should be peer-to-peer, and someone who pays should give the payment transaction directly to the person who gets paid. The party being paid should not monitor the blockchain to receive the payment transaction and should be the one broadcasting it, not the payer.
What does the future API for blockchain services look like? This comes back to the fact that it is not clear what long-term adoption looks like. I certainly can’t say for sure, but I have some thoughts on the subject that can be used as a starting point.
Transactions
This can be seen as the most direct form of full-chain indexing. If you offer a service that allows any broadcast and mined transaction to be retrieved upon request at a later time, you must keep all of those transactions in an easily accessible manner. How do you know what the important transactions are? I think it’s fair to say that 99.9% of them are irrelevant and will never be opened.
Let’s think through a recent concept, the idea that blockchain can be used for data storage. This was always a bad idea, but it was pushed by some parties, and software and services were developed based on it. It is still considered viable by some people! So the implications are that if a blockchain service offers an API to request the necessary transaction, developers and users will build on it expecting it to work in the future. And it’s not a finite future, it’s the unknown time in the future when they need a random transaction. If the service locks down the API at a later date, all those developers and users will find that all their usage is now broken or affected in some way, and may not even realize it until they go to use it as a user that API.
My prediction: An API that allows uncut access to transactions is a waste of time and resources. The viable future model for transaction access will be to pay a service to keep the transactions you know you might want to access in the future. You can even do this yourself by having a junior developer set them up with cloud storage and have the cloud manage replication. The easiest way to obtain transactions you need is for the other parties with a vested interest in those transactions to give them to you, and they must already have them.
Merkle proves
I liked what I perceived to be the MAPI model and think it makes a lot of sense. In theory you can get the coinbase transaction for each mined block and from these you can find the MAPI services. You can then get fee quotes from these endpoints and construct payments that meet the fee requirements. You can then broadcast to a miner’s MAPI service knowing that the transaction has been accepted and get a callback with the merkle proof.
The problem is that you can only get merkle proof for transactions you broadcast using a MAPI service. It is not a given that transactions you receive have not already been broadcast, or that a party you paid was reliably able to provide you with the token they received from the MAPI service they used to broadcast. This means that it is certain that at some point you will need to use a blockchain service that can provide you with merkle proof for specific transactions that you are interested in.
My prediction: An API to provide arbitrary merkle proofs is valuable and will be used. There is also a big opportunity here for you as a developer to consider whether you should use MAPI rather than following the lead of other developers or educational material and just using it. If you already have to use a blockchain service and get merkle proofs, then you might just want to connect to the P2P network and broadcast transactions there and use blockchain services to get the merkle proofs.
Script Hasher
A script hash is where you know the form a transaction will take and you take the SHA256 hash to an output script. It is used for two ancient purposes. Either you want to register it with an indexing service so you can detect when someone else broadcasts a payment to that output script. Or you want the indexer to search the entire chain archive and find all previous transactions that have a payment to that output script. This was why blockchain services used script hashes.
If the reason blockchain services use script hashes was to make the broken protocol model that Bitcoin Core enforced work, then we have to ask ourselves why we would continue to use them. ElectrumSV is a wallet that uses the ElectrumX indexing service to detect new payments and recover old payments using script hashes – but it drops this completely.
My prediction: This is a dead end. Finding transactions by knowing the entire output script is a limited technique and can easily be replaced by other more flexible approaches. A blockchain service that offers APIs based on script hashes will find itself wasting time and resources for developers who need to up their game and move on from legacy approaches.
An example to illustrate this is to consider how it prevents someone from adding an OP_PUSH/OP_DROP to an output script to mark it with useful data, this could be an identifying mark so that it can be located in the worst case, and so on it can be invoice-related data or anything else you can think of.
Addresses
All old payments were made to addresses. A default payment was made using what is called a P2PKH output script, and the public key hash in that script in the correct location was the address. A multi-signature payment was made using what is called a P2SH output script, and the script hash in that script in the correct location was the address. This enforced a limited accepted set of forms of payment, where they had to be these two things. They look random and are difficult to compare, and there is malware that replaces them when users cut and paste them from one application to another.
My prediction: These mysterious addresses as a common and standard concept is something that will fade away and become irrelevant. A blockchain service that offers APIs based on addresses will find itself wasting time and resources for developers who need to up their game and move on from legacy approaches.
Ends
There are many more nuances to this than can be touched on in this article.
There is a huge amount of work to be done by both blockchain service developers and blockchain application developers, and it serves us well if we look at what we are spending and ask ourselves if the resources involved were well spent.
Blockchain Services
What types of applications does a blockchain service aim to support? Is it a service that performs operations on behalf of its users, such as HandCash, MoneyButton or SimplyCash? Is it a P2P application that has no hosting service and where the user is in sole possession and control of their coins? Is it both? Is there anything else? Do they think there is one size fits all?
The last thing a blockchain service company is likely to do is find out that they have invested a huge amount of time, resources and effort into building APIs that just aren’t that useful compared to their competitors. This can be the difference between them not providing what application developers really need or not.
Application developers
How does a blockchain application developer know they are doing things right? There is a huge amount of Bitcoin Core-oriented development resources and even source code out there. Some of the Bitcoin SV resources are probably extrapolating from these resources rather than looking at what they should do on Bitcoin SV.
The last thing an application developer is likely to want is to find out that a blockchain service is dropping or charging more and more for an API they built on, and recommend switching to another API. Something that might have been avoided. Switching away from a poor choice in underlying technology can be the death knell for an application developer’s efforts, and it may not even have been their fault for adopting that approach. They may have followed commonly recommended approaches or sample code, and not known enough to think through whether they were the best things to use.
Last thoughts
What I want people to take away from this is that I think there is value in analyzing these APIs and saying who do they serve and will they continue to be relevant and offer value in the future? Is there another approach that is obviously more flexible and likely to be relevant and provide the future value? While there is an element of no one really knowing what form adoption will take, I’m pretty confident in my predictions.
At the very least, application developers should think through the consequences of using APIs that have no guarantee to exist in the future, and I certainly can’t see blockchain services ever guaranteeing that they will provide them. If you want to own your own data, you want to know you have access to it, and the best way to do that is to not rely on any model that breaks if APIs are changed or removed.
See: BSV Global Blockchain Convention panel, The Future World with Blockchain
New to Bitcoin? Check out CoinGeeks Bitcoin for beginners section, the ultimate resource guide for learning more about Bitcoin – originally envisioned by Satoshi Nakamoto – and blockchain.
