Toolbox Overview

What is LiteClient Toolbox?

LiteClient Toolbox (LCT) is a suite of modular components that allows users and service providers interact with Bitcoin in a scalable way. LCT is infrastructure that implements the Simple Payment Verification (SPV) model for users to interact with Bitcoin, as outlined in the Bitcoin Whitepaper.
The main components of LCT include:


A core part of the Bitcoin design is that it supports both nodes and users while separating their roles and capabilities.
Satoshi Nakamoto envisioned a clear distinction between nodes, operating as "big sever farms", and users, which "only do transactions and don't generate [blocks]".
Satoshi Nakamoto designed a system for Bitcoin that supported both nodes and users playing different roles. He envisioned nodes as "big server farms" and users as "client nodes [or LiteClients] that only do transactions and don't generate [blocks]". As a result of the Bitcoin system being subject to artificially imposed limits in the first decade of its existence, this distinction was not very clear and did not make its way into the infrastructure which remained very fragile and unscalable for far too long.
LCT provides reference implementations of the modules which make up the SPV infrastructure as initially described in the Bitcoin Whitepaper, along with a few extensions and additional features. All components are designed to be very modular so that different people can use different components of the toolbox depending on their needs, as well as easily replace or upgrade separate components.
Unfortunately, there have been many misconceptions around SPV over the years and the ability to scale Bitcoin the way it was originally designed. Earlier implementations of "SPV nodes" or LiteClients heavily relied on bloom filters. They would connect to nodes and basically ask to forward them transactions that they're interested in using bloom filters as a method to obscure the transactions they're interested in for privacy reasons. However, take a step back and ask yourself why do we even need bloom filters in the first place? The answer is pretty much that we do not. The entire communication process involved in the earlier implementations is far from ideal but that does not mean that the entire system is flawed or unscalable.
Instead of the sender broadcasting the payment transcation to the Bitcoin network and then forcing the receiver to run a fully indexing node, that downloads every single transaction on the network, or query a node to get specific transactions (through a bloom filter); why doesn't the sender connect directly to the receiver and send them the payment directly? This is the essence of SPV and how Bitcoin can scale indefinitely without affecting the users of the network who want to send and receive payments. Users of the Bitcoin network don't need to care much more than about the transactions they're interested in. Users don't have to download every single transaction ever on the network if they only want to recieve one simple payment transaction, "[t]hat would be like every Usenet user runs their own NNTP server."

Cheque analogy

To give a simple analogy, consider payments using cheques. If I wanted to pay you using a bank cheque, would I post the cheque to the bank then have you run to the bank and ask around searching for the cheque? Especially when there are millions of cheques being sent around every minute? Doesn't make sense does it?
Instead, I would hand you the cheque directly. Then it is your responsibility to go and deposit the cheque and the bank and make sure it clears. It is not my responsibility to cash your cheque for you and I would be more than happy if you fail to cash it yourself because the money will stay in my account.
Linking back to Bitcoin, if I wanted to pay you, I would first have to find your device which will receive the payment (Paymail can be used to aid with that process). Once I have discovered the service endpoint, my payment device would need to speak the same language as yours (this is where the DPP comes in) in order for your device to dictate the exact terms and requirements of the payment and then for my device to craft that payment properly and send it back to you. Once you receive the payment, it is your job to validate that it fulfils your requirements and then get that settled on the Bitcoin network. Once the payment transaction has been settled, you can easily verify that the transaction has been included in the blockchain (the longest valid chain) with a low amount of data regardless of how big block sizes get - you only need the Merkle Proof of the transaction as well as the chain of block headers (which is only 4.2MB per year).


Currently, the Bitcoin SV Blockchain node requires extensive resources in terms of storage capability and its operational costs keep increasing with time. With large block sizes, businesses face the challenges of running, synchronising and maintaining a full node for the BSV Blockchain. It requires them to not only review their system capabilities but also come up with extra solutions to ensure resilience and availability of BSV based services.
The LiteClient infrastructure aims to fill that gap where enterprises who do not mine can move away from hosting a full node to a focused SPV infrastructure which allows them to just store and run Bitcoin SV blockchain based services, according to their needs. The provision of LiteClient support will largely depend on the specific use case requirements of the business.
Typical businesses that can adopt LiteClient infrastructure are:
  1. 1.
    Wallet providers
  2. 2.
    Exchanges who use payment capabilities
  3. 3.
    Applications using BSV as a payment method
  4. 4.
    Individuals who are interested in Peer to Peer capabilities and want to run their payment infrastructure (for BSV payments)
  5. 5.
    SME's who are interested in subsets of BSV Blockchain transactions (payment, data) who can also leverage this for transaction verification on blockchain.
The above list is a suggestion, but in reality, any business interacting with Bitcoin SV Blockchain will be able to replace the work done via a full node with the LiteClient infrastructure. A typical SPV based LiteClient architecture is shown in the diagram below:
SPV Architecture for Application Development
It describes an application which uses a Block Headers Client and verifies the presence of a transaction that it is interested in, via a SPV Check. This transaction could be a payment or a data transaction which is dependent on the specific application usage.
SPV is described in the Bitcoin Whitepaper as a method for constructing a payment verification process which does not involve running a full node software which miners typically run.
“Simple Payment Verification (SPV), is a system outlined in the Bitcoin Whitepaper that enables clients like wallets to verify that a transaction has been included in a block and therefore a payment has been made and accepted by the network.”
This is possible because the Merkle tree structure stores the transactions in each block. The structure of a Merkle tree means that we only need to know the Merkle root/top hash and a small branch of the tree to verify if a transaction is part of the tree, whether it has been included in a Bitcoin block. This is done by taking the nodes that are in the path that connects the Merkle root with one of the bottom transactions and bundling them together to create a proof.
Running a node requires downloading the entire blockchain, but a Bitcoin user can use Merkle proofs and only needs to know the header of each block which includes the Merkle root, in order to verify any transaction in that block, so we only have to store 80 bytes per block, instead of the entire block required for nodes.
Note: See Bitcoin Wiki - SPV for more details.
The steps for performing SPV Check are as follows:
  1. 1.
    Receive Raw Tx and the Merkle proof
  2. 2.
    For each of the UTXO being spent, follow the steps below:
    a. Get the Prev Tx Id and its block hash
    b. Query block hash and get the block header
    c. Extract the Block’s Merkle root from the Block header
    d. Follow the process for constructing Merkle root from the Prev Tx ID of the said UTXO
    e. Validate the constructed Merkle root value to be same as the Merkle root obtained from the Block header.
    f. If both values match, the UTXO is valid and can be spent.
    g. Return Valid SPV check result
    h. Go to the next UTXO in Tx and start from step a.
  3. 3.
    If all of the input UTXOs are valid, pass the Tx to be valid
An application running a LiteClient can effectively perform all functions as provided by a full node using this effectively removing the need to run expensive infrastructure. Such (Lite)Clients are key for scaling bitcoin because they allow you to build applications using the Bitcoin network without hosting expensive node infrastructure.