Papers Relating to Bitcoin and Related Subjects in Law: Part XIII

by James · May 11, 2023

This article was first published on Dr. Craig Wright’s blogand we republished with permission from the author. Read Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9, Part 10, Part 11 and Part 12.

Simplified Payment Verification (SPV) was first discussed in the Bitcoin White Paper (Wright, 2008), and was taken up by other authors, such as Palai et al. (2018). Such authors present a method which they refer to as block summarisation. Nevertheless, the authors maintain an underlying premise: that all parties must carry out the validation of all transactions in a blockchain. For example, in proposing a solution, Palai et al. (2018, p. 3) note that “the inability of light nodes to validate transactions is due to the lack of access to the entire blockchain.” Nevertheless, the underlying assumption that all users of the system must validate all transactions remains part of the argument’s underlying premise.

Nadia et al. (2018) have an approach similar to Palai et al. (2018), looks at methods related to compression and summarization of the distribution of a blockchain. In this analysis, the authors briefly mention SPV, but only in relation to an alternative process called VerSum, which outsources the analysis of blocks to third parties. Similarly, as with Palai et al. (2018), Nadiya et al. (2018) assume that all nodes must validate all transactions. Such an assumption falsely incorporates the notion that all systems must globally validate all other systems to maintain security and honesty in a financial network.

Ozyilmaz et al. (2018) again follows the definition of ‘full nodes’, ‘light nodes’, ‘half nodes’ and other systems that do not participate in the consensus process under the definition of a blockchain node as nodes in the system. This allows them to refer to SPV as a “weak” system, where they argue that a lower level of security is maintained. In this, the authors fall into the common trap of believing that nodes that do not create blocks can somehow be part of the consensus methodology of a blockchain.

Annotated bibliography

Palai, A., Vora, M., & Shah, A. (2018). Strengthen lightweight nodes in blockchains with block summarization. 2018 9th IFIP International Conference on New Technology, Mobility and Security (NTMS), 1–5. https://doi.org/10.1109/NTMS.2018.8328735

Palai et al. (2018) note that all blockchains owe an origin to Bitcoin. This leads to the discussion of scalability. The authors face the description and understanding of scalability as it applies to a blockchain in the BTC Core Wiki article (Scalability – Bitcoin Wiki, n.d.). The wiki page falsely argues that Bitcoin has a scaling limit of around seven transactions per second without noting the artificial limit imposed by the BTC Core development team.

The authors rely on a definition of nodes that represent every user of the system. In this analysis, they present a “light node” and represent it as part of the consensus process in a blockchain system like Bitcoin. Unfortunately, the false definition of a node leads to the development of a block summarization process that the authors claim is novel, while ignoring the section of the Bitcoin White Paper documenting pruning. The analysis extends to developing a recursive tree designed to summarize transactions.

The development involves reducing the size of an aggregated block distributed over a blockchain network. Nevertheless, the trade-off is based on increased calculation rates that limit the ability to scale to significant volume. While the authors document a 50% reduction in the size of blocks, the authors fail to report the increased computation time and thus processing time associated with parsing and accepting transactions of blocks. Such a limitation is associated with the author’s attitude of pushing an agenda for decentralization – rather than transaction volume. The development of compression algorithms allows for smaller blocks, but the expense that the authors do not cover is the necessary increase in processing power.

Ozyilmaz, KR, Patel, H., & Malik, A. (2018). Split-Scale: Scale Bitcoin by partitioning the UTXO space. 2018 IEEE 9th International Conference on Software Engineering and Service Science (ICSESS), 41–45. https://doi.org/10.1109/ICSESS.2018.8663851

Ozyilmaz et al. (2018) propose a “shared” approach to validate industry bid blocks, and a distributed mempool process for storing unconfirmed transactions. The approach involves splitting a blockchain into multiple sub-chains to allow a distributed set of “home nodes” to operate (2018, p. 2) despite not participating in the consensus process with the primary nodes in the system. Such an approach divides the blockchain into several segments.

The system leads to the creation of derivative coins that the authors call “nuruBitcoins”. While this approach increases the number of nodes, the sharing of tokens between multiple chains removes the functionality of tokens, as some chains may be considered more or less secure than others. Additionally, such a subchain would require additional layers of interaction, to allow users to exchange assets. In part, this approach looks not at the pseudonymous nature of Bitcoin, but at promoting anonymity. Unfortunately, the process is based on several erroneous premises and is not technically feasible.

Nadia et al. (2018) circumvent pruning and the computational costs associated with compression and decompression to propose another methodology designed to shrink the size of blocks in the Bitcoin network and other blockchains. The method presented again saves storage space at the expense of calculation time. Yet, by limiting block sizes as BTC Core and Ethereum promote, such a strategy offers limited storage savings, coupled with increased computational costs.

The proposed solution includes the introduction of a compression and deflation algorithm. The authors note SPV, but discount it against alternative strategies such as VerSum. In this approach, the authors have an undisclosed goal of achieving widespread decentralization and do not consider the cost of using compression algorithms across large networks. While the experimental results show compression, the authors do not report the time spent compressing the blockchain, making the research far less valuable.

Additional references

Nadiya, U., Mutijarsa, K., & Rizqi, CY (2018). Block summarization and compression in the Bitcoin Blockchain. 2018 International Symposium on Electronics and Smart Devices (ISESD), 1–4. https://doi.org/10.1109/ISESD.2018.8605487
Ozyilmaz, KR, Patel, H., & Malik, A. (2018). Split-Scale: Scale Bitcoin by partitioning the UTXO space. 2018 IEEE 9th International Conference on Software Engineering and Service Science (ICSESS), 41–45. https://doi.org/10.1109/ICSESS.2018.8663851
Palai, A., Vora, M., & Shah, A. (2018). Strengthen lightweight nodes in blockchains with block summarization. 2018 9th IFIP International Conference on New Technology, Mobility and Security (NTMS), 1–5. https://doi.org/10.1109/NTMS.2018.8328735
Scalability—Bitcoin Wiki. (nd). Retrieved December 19, 2022, from https://en.bitcoin.it/wiki/Scalability
Wright, C. S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. SSRN electronic journal. https://doi.org/10.2139/ssrn.3440802

This article has been lightly edited for clarity

See: LiteClient: Scaling Blockchain with Simplified Payment Verification

New to Bitcoin? Check out CoinGeeks Bitcoin for beginners section, the ultimate resource guide for learning more about Bitcoin – as originally envisioned by Satoshi Nakamoto – and blockchain.