Merkle Trees and SPV

Find the full article on my personal blog here.

Merkle Trees

By now, it should be well understood that Bitcoin utilises the concept of a Merkle tree to its advantage; by way of background, we provide an explanation in this post. The following aids as a technical description and definition of similar concepts used more generally in Bitcoin and specifically within SPV; read the necessary background information here.

Such techniques form an important component in implementing SPV in an efficient and secure manner, allowing us to scale and effectively implement a verification solution that provides true peer-to-peer transactioning.

Simplified Payment Verification (SPV)

I’ll start by describing the base of any SPV system. In order to do so, we shall provide an overview of SPV verification techniques for ease of reference.

In what follows, we consider Alice (a customer) and Bob (a merchant) who wish to transact at the point of sale of some goods. We examine how the interaction takes place using simplified payment verification (SPV) using the traditional method, as outlined in the Nakamoto white paper (Bitcoin: A Peer-to-Peer Electronic Cash System, Craig Wright, [2008]). The same interaction is described later in respect of an illustrative embodiment of the present invention, in the section entitled Overview of the Invention. In both cases, we consider the role of three blockchain transactions (Txs). Two transactions have spendable outputs (UTXOs) owned by Alice:

  • Tx1– a transaction with a spendable output (vout-1)
  • Tx2– a transaction with a spendable output (vout-0)

The transactions Tx1, Tx2 will be referred to herein as input transactions, as a concise way of saying that they are transactions comprising outputs that are being spent by the inputs of some subsequent transaction, that is, a Tx3.

The third blockchain transaction is the payment transaction:

  • Tx3 — a transaction using vout-0 and vout-1 as its two inputs and one output paying to Bob. There are only two inputs and one output for simpler demonstration of the invention.

The three transactions, along with the Merkle paths which can be used to relate them to blocks (headers), are shown schematically in the following figure.

The basic concept of SPV has existed since I released the Bitcoin white paper, and the rudimentary concept, though not fully developed, was a part of the original Bitcoin protocol. In essence, SPV makes use of two properties of the Bitcoin blockchain:

  1. Merkle proofs that can be used to easily verify that a given transaction is included in a Merkle tree and represented by a Merkle root; and
  2. Block headers that represent blocks of transactions by including the Merkle root of a Merkle tree of transactions.

By combining the two properties, a lightweight Bitcoin client need only maintain a copy of the block headers for the entire blockchain — rather than blocks in full — to verify that a transaction has been processed by the network. To verify that a given transaction has been processed and included in a block, an SPV client requires only:

  • a full list of up-to-date block headers; and
  • the Merkle path for the transaction in question.

It follows from property 1 that the SPV user can verify that the given transaction is part of a Merkle tree — represented by a Merkle root — simply by performing a Merkle-path authentication proof as explained in the section above. It then follows from property 2 that the transaction is also part of a block in the blockchain if the SPV client has a valid block header that includes the Merkle root. Performing the same type of payment verification in Bitcoin will be referred to herein as performing an SPV check.

The SPV mechanism as specified by Nakamoto informs the existing method of SPV-client implementation, including at the point of sale. Importantly, the state of the art in SPV implementation is based on the paradigm whereby a user verifies that a payment has been received by confirming (to a suitable depth on the blockchain, e.g., 6 blocks) that it has been included in a block. In effect, it is a post-broadcast check on a transaction to verify that it has been mined.

In contrast, the present invention requires that the necessary SPV check be performed on a transaction’s inputs prior to its broadcast. The shift in emphasis greatly reduces the burden and traffic on the network in dealing with invalid transactions.

A second important paradigm in the existing SPV system is that an SPV client must query full nodes on the network to obtain the Merkle path required for the SPV check. It can be seen in the Bitcoin implementation where it has been noted that “the SPV client knows the Merkle root and associated transaction information, and requests the respective Merkle branch from a full node”.

SPV checks that remove such burden on the network, by stipulating the lightweight Bitcoin client where users keep, maintain, or at least have access to their own copies of Merkle paths pertinent to the unspent transaction outputs owned by them, allow Bitcoin to scale.

Find the full article on my personal blog here.

nChain

Craig Wright (Bitcoin SV is Bitcoin.)

Written by

My opinions are my own. Eternal student & researcher; plugging Bitcoin from as long as it was lawyer, banker, economist, coder, investor, mathematician, & stats

nChain

nChain

The global leader in advisory, research, and development of blockchain technologies

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade