TSC envelope specification targets better data transactions on BSV

Getting your Trinity Audio player ready...

The Bitcoin SV Technical Standards Committee (TSC) has published a new technical standard, detailing the envelope specification that wallets and data services could ultimately use to read and write transactions.

The latest technical standard to be published by the TSC, the envelope specification has moved through the various stages to publication, where it will now be considered before potentially passing to recommendation.

The envelope specification aims to address the problem of inconsistent data file formats, which each require their own compatible software to open, decode, and process. Without a uniform standard, trying to access certain specific data on chain would require opening irrelevant files with their own particular compatible software, in order to find the needle in the haystack you are looking for.

The envelope specification, if adopted, would have each type of data file wrapped in a consistent envelope, or wrapper protocol, which would allow software to more easily identify how data is formatted, and present it in a consistent way to end users. 

James Belding, CEO of Tokenized and TSC sponsor of the proposed envelope specification, said the specification would help people find the data they were looking for on the blockchain much more readily.

“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,” Belding explained.

“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.”

Pressed on the value this technical standard will bring to the Bitcoin SV ecosystem, Belding was unequivocal in suggesting it would unleash the full potential of BSV for handling mass volumes of data in a practically usable way.

“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,” he said.

“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.”

Asked whether the format of transaction metadata would be standardized, Belding said no, in order to retain the levels of flexibility required in the system.

“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,” Belding said.

“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.”

During the review process, a number of key points of consensus were established, which will ultimately guide and shape the response.

• That the protocol should be as simple as possible since it may have many implementations.
• The protocol should be more agnostic and rather than supporting extensions it should be possible to “layer” sub-protocols to enable more advanced usage. This enables sub-protocols to enable data transformation and other functionality without specific protocol support.
• The protocol should not use the Protocol Buffers protocol for encoding protocol level data, but use a more Bitcoin script friendly encoding. This was partially to remove any implementation dependencies and also to make it more Bitcoin developer friendly.

The above points of consensus were reached through a combination of internal and public review, and have been brought into consideration when drafting the standard.

According to the documentation accompanying the standard, the aim is “to provide a framework for specifying and combining different protocols embedded in Bitcoin transactions.”

The standard also “aims to be agnostic to the way the data is stored within Script, and equally supportive of all types of protocols and protocol identifiers.”

“The protocol needs to be as simple and lightweight as possible, to enable easy integration with various services, and to be efficient regarding processing speed, to support high throughput systems, and its storage footprint, to keep mining fees as low as possible.”

As per the Technical Standards Committee’s established process for implementing new standards, there will now be a period of consideration and review, before the technical standard can be officially recommended for adoption. Even at this stage, the standard will only crystallize when it is adopted within the BSV ecosystem, to ensure it is relevant and appropriate to real world use cases.

The Envelope Specification is only the latest standard to reach this stage of the process, part of the Technical Standards Committee’s roadmap for building out a series of baseline standards for the BSV blockchain ecosystem.

Watch: CoinGeek Zurich panel, BSV Technical Standards: Roadmap for an Interoperable Blockchain Future