Abstract

The Bitcoin lightning network (BLN), a so-called ‘second layer’ payment protocol, was launched in 2018 to scale up the number of transactions between Bitcoin owners. In this paper, we analyse the structure of the BLN over a period of 18 months, ranging from 12th January 2018 to 17th July 2019, at the end of which the network has reached 8.216 users, 122.517 active channels and 2.732,5 transacted Bitcoins. Here, we consider three representations of the BLN: the daily snapshot one, the weekly snapshot one and the daily-block snapshot one. By studying the topological properties of the binary and weighted versions of the three representations above, we find that the total volume of transacted Bitcoins approximately grows as the square of the network size; however, despite the huge activity characterising the BLN, the Bitcoins distribution is very unequal: the average Gini coefficient of the node strengths (computed across the entire history of the Bitcoin lightning network) is, in fact, ≃0.88 causing the 10% (50%) of the nodes to hold the 80% (99%) of the Bitcoins at stake in the BLN (on average, across the entire period). This concentration brings up the question of which minimalist network model allows us to explain the network topological structure. Like for other economic systems, we hypothesise that local properties of nodes, like the degree, ultimately determine part of its characteristics. Therefore, we have tested the goodness of the undirected binary configuration model (UBCM) in reproducing the structural features of the BLN: the UBCM recovers the disassortative and the hierarchical character of the BLN but underestimates the centrality of nodes; this suggests that the BLN is becoming an increasingly centralised network, more and more compatible with a core-periphery structure. Further inspection of the resilience of the BLN shows that removing hubs leads to the collapse of the network into many components, an evidence suggesting that this network may be a target for the so-called split attacks.

Highlights

  • The gain of popularity of Bitcoin [1] has manifested the problems related to the scalability of the technology upon which it is based: only a limited amount of transactions per second—whose number is proportional to the size of a block and its release frequency—can be processed by Bitcoin

  • By studying the topological properties of the three representations above, we find that the total volume of transacted bitcoins approximately grows as the square of the network size; despite the huge activity characterising the Bitcoin lightning network (BLN), the bitcoins distribution is very unequal: the average Gini coefficient of the node strengths is, 0.88 causing the 10% (50%) of the nodes to hold the 80% (99%) of the bitcoins at stake in the BLN

  • We have tested the goodness of the Undirected Binary Configuration Model (UBCM) in reproducing the structural features of the BLN: the UBCM recovers the disassortative and the hierarchical character of the BLN but underestimates the centrality of nodes; this suggests that the BLN is becoming an increasingly centralised network, more and more compatible with a core-periphery structure

Read more

Summary

Introduction

The gain of popularity of Bitcoin [1] has manifested the problems related to the scalability of the technology upon which it is based: only a limited amount of transactions per second—whose number is proportional to the size of a block and its release frequency—can be processed by Bitcoin. This shortcoming may prevent the adoption of this payment network at a global scale, especially when considering that classic payment mechanisms (e.g. traditional credit cards) are able to achieve tens of thousands of transactions per. A naïve (and short term) solution would be represented by an increase of the block size: larger blocks, would require larger validation time, storage capability and bandwidth costs, in turn favouring centralisation, as fewer entities would become able to validate the new blocks that are appended to the Blockchain; centralisation in the validation process would make the system less resilient, i.e. more prone to faults and attacks

Methods
Results
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call