One of the most valuable features of Bitcoin is the ability to immutably record data on a time-stamped public ledger. This provides the ability to audit and prove the existence of data of all types, from financial transaction records to book manuscripts, mathematical formulae and even digital works of art. The problem is that data files come in many different formats, each requiring compatible software to decode, open and process. This means that if you were trying to find a specific type of data on the blockchain, you would have to go through the process of accessing all of the irrelevant data files to find the ones you were looking for.

The proposed TSC solution, which it arrived upon following feedback from industry experts and community members, proposes that each data record is wrapped in a standard ‘envelope’ or ‘wrapper’ protocol that allows software to easily determine how the data is formatted and how to either process it or display it to a user.

The scenario is similar to one wherein an A-Z wholesaler distributes a wide variety of imported goods to retail buyers, from books to musical instruments, clothing and even electronics. Within the wholesaler’s facility, all of these different items would be placed in similar shipping containers. 

So, how would a retail buyer know where to start looking for items they want to stock in their fashion outlet, book shop or musical instrument store? 

The solution would be to label each crate with a standardised classification system made up of a string of letters and numbers. The system determines that the first batch of characters would indicate what to expect from the next batch of characters, e.g., look for a four, five or six-character category code. 

The category code identifies the type of items in the container, such as an ISBN (i.e. a protocol identifier) to indicate books or a manufacturer’s name like Casio to indicate Casio electronics. 

Once this code has identified the category, the next batch of characters would delve into more detail about the items according to the manufacturer or industry’s own indexing system. An ISBN would identify the language that the books are published in and its literary genre. Casio’s model number would indicate the type of watch, which series it belongs to and any other relevant specifications.

Now that each shipping container is labelled to identify the general and specific details of its content, retail buyers can quickly scan only the first few characters of the label to identify the crates that are of interest to them.

The TTDR (Too Technical, Didn’t Read) breakdown of the Envelope Specification

In this edition of the TTDR blog, James Belding, CEO of Tokenized and TSC sponsor of the proposed envelope specification, details the proposed protocol and explains the implications of its standardisation on the BSV ecosystem.

TSC: What problem did you set out to solve with the proposed envelope specification?

JB: The envelope specification is to help people who are looking for a specific type of data on the blockchain. Without a specification that labels each ‘data envelope’ with its taxonomy, people would have to open each envelope to check its contents, which would be hugely inefficient. 

In blockchain terms, the envelope specification is an envelope that wraps around the transaction payload [data contained in the transaction] and labels it so that someone wouldn’t have to access the data contents unless it is relevant to what they’re looking for. 

TSC: What value does the Envelope Specification add to the Bitcoin SV ecosystem? 

JB: The BSV blockchain is designed to store large volumes of data of all varieties on its ledger. In effect, it is a giant, public database that anyone can store data to and read data from. This makes it different from BTC and BCH with their focus on monetary transactions, giving it a unique value proposition.

To unleash the potential of Bitcoin SV as a global public database, we have to make it as easy to use as possible. In the case of a private database, there would typically be fewer people accessing it and the content would be more narrowly focused. But still you would have to implement a protocol of sorts to help navigate the data. Within the Bitcoin paradigm, establishing a thorough data taxonomy is crucial. 

TSC: Which applications stand to be affected by the adoption of the envelope specification?

JB: The specification relates to any data that is stored on-chain, making it more accessible and interoperable. If you’re storing any kind of data payload that other entities will want to access and use somehow, this format will make it a lot easier for them to do so. 

TSC: Are you going to standardise the format in which transaction payloads (metadata) must be submitted? 

JB: No. The envelope specification will allow you to use any formalised data protocol in a permissionless manner. Our company, Tokenized, has its own protocol to identify our smart contracts, tokens and the like. We have a three-digit code, TKN, which is the equivalent of the ISBN acronym. In our case, the envelope specification would indicate that the next three characters act as protocol identifiers. If the specification didn’t indicate the number of characters to look for, it might be confused for another protocol code, for example, TKN100.

As long as the envelope specification identifies the number of characters in the protocol identifier, it could be any number of characters followed by data of any format or type. 

TSC: The envelope specification entered the public review stage on June 7. Who would you like to take notice and participate?

JB: Basically, all technical people interested in or already working on projects that store data on-chain. If you’re keen to comment on this standard or any others that are in the public review stage, please register as a contributor today.