Coordinate Routing in the Lightning Network
Total Page:16
File Type:pdf, Size:1020Kb
Coordinate Routing in the Lightning Network Shivanand C Kohalli Student Number: 4751116 Coordinate Routing in the Lightning Network Master’s Thesis in Embedded Systems Distributed Systems group Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology Shivanand C Kohalli 23rd September 2019 Author Shivanand C Kohalli Title Coordinate Routing in the Lightning Network MSc presentation Sep 30, 2019 Graduation Committee Dr.ir.J.A. Pouwelse Delft University of Technology Dr. S. Roos Delft University of Technology Dr. M. Nasri Delft University of Technology Abstract Blockchains such as the Bitcoin facilitate the online transaction between users without an intermediate financial institution and can serve as a global currency. However, at the moment, blockchain solutions are suffering from low transaction throughput and high delays. For instance, the bitcoin network processes at most 7 transactions per second. Blockchain second layer solutions aim to solve this transaction scaling problem with the idea of creating off-chain transactions using payment channels. For a payment channel, the blockchain network is only required to initialize and terminate the channels. Otherwise, they can finalize transactions between pairs of users instantly without using the blockchain network. The Light- ning Network is one such payment channel solution that creates an overlay network on top of the blockchain and routes payments across users. Currently, the Light- ning network uses source routing to route payments from a source to a destination. However, source routing does not scale to large networks. In this thesis, we begin by establishing the requirements for routing in the Light- ning Network. Next, we analyze generic payment routing algorithms based on the set requirements and understand their limitations. Further, we design a routing al- gorithm for the Lightning Network that builds upon the key ideas found in the pre- vious work. We, in particular, provide design solutions for computing transaction fees and communicating errors in a privacy-preserving manner. These problems were not addressed in any earlier works. Finally, we implement our algorithm in an active Lightning Network codebase. We evaluate it with regard to security, pri- vacy, and performance requirements and also compare the same with the existing solution. 2 Acknowledgments I would like to thank my supervisor, Stefanie, for providing a wonderful opportun- ity to work on this research topic. Thank you, for steering me in the right directions when I faced obstacles, for all the weekly meetings and the valuable feedback. I also want to thank Oguzhan for the cryptography discussions we had. I made many good friends in Delft during my studies, would like to specially thank Amitabh, Umeer and Bhavya for being a source of motivation when needed. I would like to express my heartfelt gratitude to my parents, for providing uncondi- tional support to all my decisions and believing in me. This dream would not have been possible without them. While I was pursuing my Masters in Netherlands, I lost a dear one, my grandpa (Ajja), back in my hometown. Ajja, you have always been an inspiration to me, I will always try to inculcate the values learned from you. This work is dedicated to you. Shivanand C Kohalli Delft, The Netherlands 23rd September 2019 3 4 Contents Preface 3 List of Figures 1 1 Introduction 3 1.1 Blockchain . .3 1.2 Payment Channels . .4 1.2.1 Lightning Network . .5 1.3 Motivation . .6 1.4 Problem statement and research objectives . .6 1.5 Contributions . .7 1.6 Thesis Outline . .8 2 Background 9 2.1 Bitcoin . .9 2.2 Lightning Network . 10 2.2.1 Multi-hop payments . 11 2.3 Routing in the Lightning Network . 12 2.4 Gossip protocol . 12 2.4.1 Node discovery . 12 2.4.2 Channel discovery . 13 2.5 Onion Encryption . 15 2.5.1 Encryption/Decryption scheme . 16 2.5.2 Onion packet construction . 18 2.5.3 Encrypting Errors . 22 3 Requirement Formalization 23 3.1 Characteristics of the Lightning network . 23 3.2 Requirement for routing . 23 4 Literature review 25 4.1 Spider . 25 4.2 Flash . 26 4.3 Flare . 27 5 4.4 Ant . 28 4.5 SilentWhisphers . 28 4.6 SpeedyMurmurs . 29 5 Routing in SpeedyMurmurs 31 5.1 Gathering Fee and CLTV . 32 5.1.1 Security Goals . 32 5.1.2 Adversary Model . 33 5.1.3 Design . 33 5.1.4 Design analysis with respect to security goals . 39 5.2 Forwarding payments . 41 5.2.1 Comparison with the Lightning network . 42 5.3 Returning Error Messages . 43 5.3.1 Security Goals . 43 5.3.2 Design . 43 5.3.3 Design analysis with respect to security goals . 48 5.3.4 Comparison with Lightning network . 50 5.4 Root Election and Spanning Tree construction . 50 5.4.1 Spanning tree algorithm . 51 5.4.2 Coordinate gossip . 52 6 System Setup 53 6.1 General Network Architecture . 54 6.1.1 Lightning Node . 54 6.1.2 Bitcoin Full Node . 56 6.1.3 Lightning Client . 56 6.2 Emulation Network Architecture . 57 6.2.1 Bootstrapping the emulation network . 57 6.3 Integration in the LND . 59 7 Evaluations and Results 61 7.1 Performance Metrics . 61 7.2 Parameters . 62 7.3 Execution environment . 63 7.4 Results and Discussion . 65 7.4.1 Success Ratio . 65 7.4.2 Success Volume . 65 7.4.3 Path Length and Delays . 66 7.4.4 Network stabilization . 66 7.4.5 Transaction overhead . 67 7.4.6 Stabilization overhead . 68 6 8 Conclusion and Future Work 71 8.1 Conclusion . 71 8.2 Future Work . 72 7 8 List of Figures 1.1 Growth in the Lightning network [18] . .5 2.1 An example of a multi-hop payment . 11 2.2 ECIES scheme encryption process . 17 4.1 Example of neighbouring and beacon nodes in Flare . 27 4.2 Example of a route between two nodes in SilentWhisphers . 29 4.3 Example of the assignment of network embedding in SpeedyMur- murs . 30 5.1 Intermediate node public keys that must be hidden from sender and the recipient . 33 5.2 Sender acquiring the total amount to be paid on a route . 38 5.3 Key distribution in a non-adversarial scenario . 46 5.4 Key distribution in an adversarial scenario . 47 5.5 Ephemeral key distribution during the upstream traversal of message 48 5.6 Ephemeral key distribution during the downstream traversal of mes- sage . 48 6.1 Architecture of components interacting in Lightning . 54 6.2 Emulation Network Setup . 58 7.1 Channel topology for 50 nodes . 64 7.2 Success ratio of SpeedyMurmurs and Source routing . 65 7.3 Success volume ratio between SpeedyMurmurs and Source routing 66 7.4 Average path length and transaction delays for 50 node network . 67 7.5 Average path length and transaction delays for 100 node network . 67 7.6 Number of MegaBytes transferred for the network stabilization . 67 7.7 Number of MegaBytes transferred for all the transactions . 68 7.8 Number of KiloBytes transferred during the network stabilization 69 1 2 Chapter 1 Introduction 1.1 Blockchain Blockchain is a technology which promises to revolutionize the current payments system. In the past decade, many prominent blockchain protocols like Bitcoin [49], Ethereum [61] and Ripple [23] have come into existence. People have already started to use this technology for their financial needs. In the month of July 2019, the Bitcoin network witnessed at least 270,000 transactions per day [2] and its net market cap as an asset class was worth over $200 Billion. The blockchain can be described as a decentralized, immutable public record of transactions. Every transaction in a blockchain network is broadcast to all the participating nodes in the network. The nodes validate this transaction and add it to a pool of transactions called a block. At the core of any blockchain protocol, a consensus algorithm decides the next block that will be added to the blockchain. Subsequently, the next block will be linked to the previous record of blocks forming a virtual chain of blocks, hence the name blockchain. Anyone can read and verify the correctness of the data on the blockchain but cannot tamper or delete it. Such an architecture has a vital implication that even untrusted entities can directly interact with each other without requiring the presence of a trusted intermediary. These properties are relevant to financial institutions, banks and even common people who would want to avoid the middleman costs for different operations. In spite of the attractive properties the blockchain provides, there are still some hurdles to overcome for widespread adoption of this technology. Performance of the blockchains is one such factor that requires significant improvements. For instance, the bitcoin blockchain currently can handle around 7 transactions per second [28]. On the contrary, Visa which facilitates electronic fund transfers all over the world can processes around 1700 transactions per second on an aver- age [20]. This is not only pertaining to Bitcoin, but a general issue of block- chains [38]. This is an important bottleneck that needs to be resolved for block- chains to be considered viable mechanisms for day-to-day payments. According to recent works, the solutions to reduce the bottleneck in blockchains 3 can be classified into two general approaches namely: 1. Layer-one solutions: These solutions focus on improving the core com- ponents of the blockchain. This maybe dealing with the consensus proto- cols [49, 26, 43, 24], modifying the block sizes or sharding [44, 37]. 2. Layer-two solutions: Also called as off-chain solutions, are built on top of the blockchain network, but still rely on the securities of the underlying blockchain.