Technical Standards Committee publishes envelope specification for better data transactions on BSV

By Jamie McKane Published: September 8, 2021

The Bitcoin SV Technical Standards Committee (TSC) has published its envelope specification standard following a period of thorough public review. The publication of the envelope specification is crucial to expanding the efficient processing of data transactions on the BSV blockchain, allowing users to easily identify and decode various file and data formats written to the ledger. This is accomplished by wrapping each data record written to the public ledger in a standardised ‘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 TSC aims to improve interoperability within the growing BSV ecosystem by working with developers and stakeholders to develop common standards that are compatible across applications. It is important to note that the TSC does not determine standards – it provides the framework and process for the development of technical standards to improve interoperability and accelerate the adoption of the BSV blockchain.

Each standard published by the TSC undergoes a rigorous standardisation process, which includes consideration, drafting, internal review and public review phases before finally being published for adoption. The envelope specification is no exception – it has undergone numerous changes at each of these stages following feedback from reviewers, developers and industry stakeholders.

Work on the envelope specification will not cease following its publication, either – the standard’s adoption and real-world applicability will be assessed at regular intervals, following which the TSC may recommend it for widespread adoption.


What is the envelope specification?

The creation of the envelope specification aligns with one of the core principles of the TSC – that of improving interoperability between entities building on and using the BSV blockchain. It aims to solve a simple but widespread problem: the existence and identification of multiple types of data written to the public ledger.

‘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 TSC explains.

‘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 TSC envelope specification solves this by defining how data should be wrapped in an ‘envelope’ that easily allows users to determine the format of the data and interpret it. As data is commonly written to the BSV blockchain via the ‘OP_FALSE’ and ‘OP_RETURN’ opcodes, this standard is designed to integrate with these commands and a set of native Bitcoin Script opcodes that push set volumes of data to the stack before writing them to the chain via an unspendable output.


Protocol identifiers and data formats

The envelope specification uses push data opcodes which are native to the Bitcoin Script language to identify the data being written to the blockchain as using the wrapper protocol allows others to easily interpret the data contained within the envelope.

According to the standard, non-executable data is stored in a format which begins with a two-byte push data value that identifies the envelope protocol and the version being used. This is then followed by sections of data, which may also include their own sub-protocols. Each of these sections of data begins with a header that provides users with information about the data wrapped within that section.

An envelope specification header comprises the following fields:

  • A number that specifies the number of protocol identifiers.
  • Push data that specifies each of the protocol identifiers being used for the data stored within the section.
  • A number that tells decoders how many opcodes are encoded using the above protocols.
  • If any data is remaining, another envelope section is parsed by the decoder by inspecting the fields above.

This specification allows for the inclusion of multiple sub-protocols within each envelope, allowing multiple types of data to be written efficiently to the blockchain while still being decoded quickly and correctly. The data wrapped within the envelope described above is written as normal to the BSV blockchain – only now it is easier to identify and process by others who adopt the envelope specification standard.


Benefits of the envelope specification

There are many benefits that come with the interoperability provided by the envelope specification standard. Most importantly, the new standard promises to greatly improve interoperability on the BSV blockchain and within the ecosystem of companies building on the platform.

For example, certain types of digital tokens, such as NFTs representing digital art, can be easily identified by services such as exchanges when they are wrapped in the protocol described above without needing to be manually identified and listed on these platforms. Blockchain data can be easily filtered and curated by inspecting the protocols and sub-protocols included within the envelope specification headers, making it trivially simple to inspect the varieties of data objects stored on the BSV network.

The envelope specification is designed to be as simple and lightweight as possible, and its efficacy is not dependent on the way data is stored within Bitcoin Script, so long as it is wrapped in the standardised envelope protocol. This means it can support all types of protocols and protocol identifiers, including future data storage protocols, and it maintains its ability to enable simple and easy integration across various blockchain services.

The specification aids developers in their construction of data storage-related applications and platforms by making it trivial to expand support for additional protocols and combinations thereof.

‘For example, if you define a data format protocol, but want to support encryption or Metanet, you can simply use this specification to combine those protocols on top of your protocol without your protocol having to know anything about Metanet or encryption,’ the TSC states.

‘This helps on both sides. It helps the protocol developers to concentrate on the specific functionality they want to provide, and it also helps software developers to support more functionality by not having to implement specific support for combinations of functionality like Metanet, encryption, compression, and many other features for each protocol.’

To participate in the development of technical standards for Bitcoin SV, visit the TSC website to propose a new standard, provide feedback on draft standards in public review, or submit suggestions on the draft roadmap.