BSV Merkle Proof Standard published—but what does it mean?

One of the most significant developments to emerge from the CoinGeek Conference in Zurich was the publication of the new Bitcoin SV Merkle proof technical standard, which has passed the full process from drafting to publication under the OpenBSV licence through the Bitcoin SV Technical Standards Committee. The new standard was announced at the event by TSC chairman Steve Shadders and TSC founding member Alex Fauvel.

The Merkle Proof Technical Standard is important because it allows for easier interoperability in BSV payments, as well as providing a utility-driven platform for simple payment verification (SPV) services on the BSV blockchain. The standard brings into line the technical capabilities of BSV with the original vision in the Satoshi whitepaper for the use of SPV to allow users to validate payments without running a full Bitcoin node.

This means, thanks to the standardised format for Merkle proofs, there is no need to download the whole blockchain in order to receive or validate payments. Transactions come with a reliable block header attached, which carries details of the transaction from a trusted node. The header contains the Merkle root, which is an encrypted hash of all the transactions detailed within the specific block to which it relates.

The Merkle root is the top level of the Merkle tree data structure that organizes transactions on a block, containing the proof of each transaction that is contained on the block. This means it’s possible to determine whether a transaction exists on the blockchain using the transaction ID and the Merkle proof.

Shadders explained that a Merkle proof allows confirmation that a transaction is connected to a specific block, without the need for running a full-scale Bitcoin node.

“Aside from a Bitcoin block header, a Merkle proof is probably one of the most fundamental data structures in Bitcoin. It’s what allows you to prove that a transaction is connected to a block, i.e., prove that miners have accepted that transaction, so there are a lot of different reasons why you would want to exchange a Merkle proof between parties.”

“It is critical to peer-to-peer interaction because part of that interaction means sending bits of information with Merkle proofs attached, so that means many different wallets need to support it. So, if everyone is implementing it in a different way, then every time you want to attach to a service, you’ve got to work out a new way of doing it.”

The Merkle proof standard is the first to emerge from the Technical Standards Committee to reach the publication stage. Shadders said this process was vital to ensuring accessibility and interoperability within the BSV environment.

“Let’s say I had a Sony DVD player and I buy a Samsung DVD player. Imagine if they had different formats – I’d have to go out and buy a whole new DVD collection to replace all my existing ones. [This standard] basically solves that problem,” Shadders told the audience.

“Every wallet can implement the existing standard for Merkle proofs – that means they are able to instantly communicate with all of the other wallets that have implemented it, some of which they might not even have thought of. That includes wallets that do not exist yet and may be built in the future.”

The standard is expected to make it easier for developers and services building on the BSV enterprise blockchain to run payment services without relying on the full node, allowing for more lightweight implementations of the technology.

With more standards in development expected to progress through the stages to publication soon, the Technical Standards Committee is hoping for more wins like the Merkle proof standard, in bringing about a commonality of rules for building on BSV.

Watch: BSV Technical Standards Committee lays out roadmap for interoperable blockchain

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]