The CLoTH Simulator for HTLC Payment Networks with Introductory Lightning Network Performance Results
Abstract
:1. Introduction
- The CLoTH simulator. It is a discrete-event simulator that simulates payments on HTLC payment networks. It takes as input parameters defining an HTLC network (e.g., number of peers and number of channels per peer) and parameters of the payments to be simulated on the defined HTLC network (e.g., the payment rate and payment amounts). It generates performance measures in the form of payment statistics, e.g., the probability of payment failure and the mean payment complete time. To the best of our knowledge, CLoTH is the first available simulator of HTLC payment networks.
- Simulation results produced using a recent snapshot of the HTLC payment network of LN. Such simulations allowed us to discover interesting cases when a payment is more likely to fail than to succeed on such network. Two such cases are the following: (1) when we set the payment rate to 100 payments per second, the network experienced 56.12% probability of payment failure; and (2) when we simulated payment amounts whose order of magnitude is between 1 millisatoshi and 0.0001 BTC (being worth less than $1 at the time of writing), the network experienced 53.87% probability of payment failure.
2. Background
2.1. Bitcoin and the Blockchain
2.2. Off-Chain Scaling Approaches
2.2.1. Payment Channels
2.2.2. Payment Network
2.3. The Lightning Network
2.3.1. LN Payment Channel Lifecycle
2.3.2. Hashed Timelock Contract (HTLC)
2.4. Brief Literature
3. Preliminary Analysis
- HTLCAdd: sent from to ℜthrough ℌ, for the establishment of HTLCs among the peers;
- HTLCFulfill: sent from ℜ to through ℌ, for the fulfillment of the HTLCs; and
- HTLCFail: sent in case of failures, for failing the HTLCs.
4. Simulator Design
4.1. Assumptions
4.2. Software Architecture
4.2.1. Computation Flow
4.2.2. Data Structures
4.3. Workflow and Usability
4.3.1. Simulation Phase
- The detailed list of payments to be executed with their attributes (File 6 in Figure 4, payments.csv), specifying sender, receiver, payment amount and triggering time.
- the end instant of the payment;
- the result of the payment: success or failure;
- the number of times the payment was attempted;
- whether the payment encountered an uncooperative peer; and
- the route traversed by the payment, if present.
4.3.2. Pre-Processing Phase
- tunes the presence of hubs in the network topology. It is the width of the Gaussian distribution which defines the probability of connection among peers. In particular, for each peer, this Gaussian probability distribution is used for choosing the other endpoint of one of the peer channels. Therefore, if the width of this Gaussian is zero, all peers have one channel open with the same peer, which, consequently, will be an hub. On the contrary, if the Gaussian width is infinite, any peer has the same probability to be connected to any other, thus producing a totally decentralised network.
- tunes payment amounts. It is the width of the Gaussian distribution whose tail is used to choose the orders of magnitude of payment amounts. The greater this width is, the longer the Gaussian tail is, and the higher the payment amounts.
- is the fraction of the total payments directed toward the same recipient. Such parameter allows modelling the use case of many small payments sent to the same destination peer, e.g., to a provider of video-streaming services which is paid for each short segment of video streaming.
4.3.3. Post-Processing Phase
- is the probability that a payment fails due to the absence of a route connecting sender and receiver.
- is the probability that a payment fails because a channel in the route was unbalanced and an alternative route is not found.
- is the probability that a payment fails because a peer in the route was uncooperative and an alternative route is not found.
- represents the remaining fraction of payments for which we do not know whether they failed or succeeded, as they ended after the time validity window of our simulation. For example, this category can encompass payments delayed after a long timelock, as a peer was uncooperative after establishing the HTLC for the payment.
- T is the mean time for a successful payment to complete.
- is the mean number of times a payment is re-attempted.
- is the mean route length traversed by a successful payment.
4.4. Formal Model
- for is the payment for which a route has to be found: and are the sender node and the receiver node of the payment, for and ; and is the payment amount.
- is the graph of nodes for connected by payment channels. The subscript k indicates the state of the graph at the moment in which is processed, with the available nodes and channels and their attributes at that moment.
- is the blacklist of possible nodes and channels excluded when searching for a route for (cf. Section 3).
4.5. Performance
5. Simulation Experiments Design
- Simulations on the LN mainnet. In this set of simulations, we gave as input to the simulator peers and channels taken from a recent snapshot (downloaded on 14 June 2018 at 14:32 from LN explorer recksplorer) of the Lightning Network running on top of the Bitcoin main network (called mainnet, in the Bitcoin jargon). The goal of this set of simulations was to discover the cases (if any) in which a payment is more likely to fail than to succeed on the LN mainnet.
- Simulations on synthetic networks, i.e., HTLC networks generated by the network generator included in CLoTH (cf. Figure 4). The goal of these additional simulations was to study the impact of each individual input parameter on HTLC network performance. Therefore, this set of simulations took into account also the parameters defining the HTLC network, which were by definition fixed in the simulations of the LN mainnet.
5.1. Parameter Tuning
Variation Intervals
- Number of peers . A network with fewer than 100 thousands peers is too small, since the LN is supposed to scale Bitcoin. Regarding the upper limit, as shown in Section 4.5, a simulation with 1 million peers lasts more than four days, which is incompatible with the time constraints of our research activities (to be addressed in future research).
- Average number of channels per peer . With the tuning simulations, we noticed that with fewer than three channels per peer all payments fail, since the network is not properly connected. With 11 channels per payments, instead, no payments fail for absence of route, so performance would not improve with more than 11 channels.
- Topology tuner . The two limits, infinite and zero, correspond to the two opposite cases: totally decentralised and one single hub, respectively. The values in between are used to generate networks with some scattered hubs.
- Uncooperative peers probability before HTLC establishment . Regarding the choice of the upper limit, we deemed that a probability that a peer is uncooperative more than once every 10 times is unrealistic.
- Uncooperative peer probability after HTLC establishment . Payments failing for such uncooperative peers are not captured by our simulation since they end after the simulated time interval (because of the timelock). However, it is realistic to have this value different from zero, as it may happen with a certain small probability that a peer experiences a fault and goes offline after establishing an HTLC.
- Channel capacity . A channel capacity lower than 100 satoshis (which corresponds to $0.001 at writing time) would mean that the channel is unable to transfer anything but so-called dust payments. The upper limit is chosen in order to support the maximum payment amount and corresponds to one order of magnitude greater than such maximum.
- Gini index G. The Gini index is by definition a value between 0 and 1.
- Average payment rate . A payment rate lower than 10 payments per second is not realistic for a world-wide payment system as LN aspires to be. The highest value is the average rate supported by mainstream traditional payment systems.
- Number of payments . The values of this interval depend on the average payment per second, and on the fact that we force a simulation to last around 15 min (cf. Section 4.1).
- Payment amount tuner . The lowest value produces only small payments, but not lower than 1 millisatoshi (corresponding to $ at writing time), to avoid dust payments (cf. Table 6). The highest value is to produce a certain fraction of high payments, however not higher than 0.001 BTC (less than $10), as the Lightning Network at least at this stage is not supposed to support large payments.
- Fraction of same-recipient payments . We consider unrealistic to send to the same recipient more than half of the total payments during a single simulation.
5.2. Simulations on the LN Mainnet
- Non-stressing value: A value of the variation interval which is not supposed to negatively impact performance. For example, the non-stressing value for the uncooperative peers probability is zero, as in this case all peers are cooperative and do not cause payment failures.
- Stressing value: A value of the variation interval which is supposed to negatively impact performance. For example, the stressing value for the probability of uncooperative peer is 10%, as it is the highest probability of uncooperative behaviour specified in the variation interval.
- We started from the non-stressing simulation, where all variables are set to their respective non-stressing values.
- We stressed one individual independent variable at a time, thus forming a branch for each simulation with one stressed independent variable.
- If the simulation with the stressed variable produced a non-operative case, we stopped; otherwise, we continued examining that branch, stressing additional variables.
Algorithm 1 Branch-and-bound-like strategy. |
|
5.3. Simulations on Synthetic Networks
- Number of peers . We did not choose a higher value because of the limited maximum execution time of the simulator; however, we performed a set of simulations varying the number of peers in the variation interval, to show the results for different values of such variable.
- Number of channels per peer . We used the value suggested by the LN developers [20].
- Network topology tuner . The chosen value produces no hubs in the topology, since the LN, as Bitcoin, is supposed to work in a decentralised topology.
- Uncooperative peers probability and . The chosen values represent a realistic probability that a peer goes down for a fault.
- Channel capacity . The chosen value is higher than the maximum payment amount we used in the simulations.
- Gini index G. The chosen value produces a uniform distribution of bitcoins in the channels. In this way, performance is not influenced by an unbalanced distribution of bitcoins, where some channels have an high capacity and the others have a low one.
- Average payment rate . It was set to the middle of the variation interval, neither too high nor too low.
- Number of payments . It depends on the average payment rate, to ensure that the simulation does not last more the maximum duration allowed (15 min).
- Payment amount tuner . It was set to the lowest level possible in our interval, to avoid the performance being influenced by high amount payments, when the effect of payment amount is not under observation.
- Fraction of same-recipient payments . It was set to zero to avoid that such payments influence the performance in simulations in which their effect is not under observation.
6. Results and Discussion
6.1. Simulations on the LN Mainnet
- Number of peers: 1221.
- Number of channels: 5167.
- Average degree (number of open channels per peer): 9.92.
- Average channel capacity: 381.35 satoshis.
- Gini index (concentration of bitcoins in channel capacities): 0.85.
6.1.1. Branch: Payment Amounts
6.1.2. Branch: Payment Rate
6.1.3. Branch: Same-Recipient Payments
6.1.4. Branch: Uncooperative Peers Probability
6.1.5. Discussion of the Main Findings
6.2. Simulations on Synthetic Networks
6.2.1. Channels Per Peer
6.2.2. Uncooperative Peers
6.2.3. Network Topology
6.2.4. Same-Recipient Payments
6.2.5. Discussion of the Main Findings
7. Conclusions
Author Contributions
Funding
Acknowledgments
Conflicts of Interest
Abbreviations
LN | Lightning Network |
HTLC | Hashed Timelock Contract |
Appendix A. Reference Code Explanation
- SendPayment. As shown by the numbers in the arrows, which represent the order of function calls, this function first tries to find possible routes to transfer the payment to the receiver and then tries to send the payment through one of the routes found. If the payment fails, it re-attempts the payment through one of the other viable routes found.
- FindRoutes. It attempts to find candidate routes which can route the payment to the receiver.
- findPaths. It runs the Yen’s algorithm to find some paths to the payment receiver. A path is a set of channels which connect payment sender and payment receiver. In each internal iteration, to find a single path, it calls findPath. (We did not implement this function in CLoTH, as, in a recent version of lnd, it has been replaced by the blacklist-based routing we described in Section 3).
- findPath. It runs the Dijkstra’s algorithm, using timelock as distance metric. In fact, each channel endpoint has a policy which defines the timelock that will be applied to any HTLC established forwarded by that endpoint. The higher is this timelock in the endpoint policy, the higher is the distance.
- newRoute. It attempts to transform a path into a route. A route is a path which connects sender and receiver and which can also transfer the payment. A path is considered capable of transferring a payment if all channels in the path have a capacity greater than or equal to the payment amount, considering also fees. Fee is the amount of funds a channel endpoint withholds as a reward for forwarding a payment through that channel. In addition, fees are defined in the channel policy.
- SendToSwitch. It encodes the HTLCAdd message for the payment initiated and sends it to the first hop of the route, which is the local peer that initiated the payment.
- SendHTLC. It sends the HLTCAdd message to the Switch.
- forward. It directs an HTLC message to the proper function of the Switch.
- handleLocalDispatch. Function of the Switch that processes HLTCs relative to payments initiated by the local peer. If it receives an HTLCFail or HTLCFulfill message, which represent the result of a payment initiated by the local peer, it propagates back the result to SendPayment. If the payment failed due to changes in the topology (e.g., a channel that was closed), topology information of the local peer is updated. This function returns an error if there are no channels to the next hop with enough balance to forward the payment.
- handlePacketForward. Function of the Switch that processes HTLCs of payments initiated by other peers and to be forwarded by the local peer. It produces an HTLCFail if no channel to the next route hop has enough balance to forward the payment. The HTLCFail message is then sent back to the payment sender, as shown by the arrow with an empty dot.
- HandleSwitchPacket. It directs an HTLC from the Switch to the Link relative to the channel over which the payment will be forwarded.
- handleDownStreamPkt. Function of the Link which processes HTLCs coming from the Switch. It produces an HTLCFail if the channel does not have enough balance to forward the payment.
- handleUpStremMsg. Function of the Link, the first called by a peer upon the reception of an HTLC message by another peer.
- SendMessage. Function to send over the network an HTLC message from a peer to another.
- processLockedInHTLCs. It processes an HTLC to decide whether to forward, fail or fulfill it. It returns an error if the local peer policy is not respected by the HTLC.
- AddHTLC, SettleHTLC, ReceiveFailHTLC. Functions called by handleUpStreamMsg or handleDownStreamPkt to update the local peer balance according to the HTLC received.
References
- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 31 August 2018).
- Sompolinsky, Y.; Zohar, A. Accelerating Bitcoin’s Transaction Processing. 2013. Available online: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.433.6590&rep=rep1&type=pdf (accessed on 31 August 2018).
- Gervais, A.; Karame, G.O.; Wüst, K.; Glykantzis, V.; Ritzdorf, H.; Capkun, S. On the security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, 24–28 October 2016; pp. 3–16. [Google Scholar]
- Poon, J.; Dryja, T. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. 2016. Available online: http://www.cva-blockchain.org/wp-content/uploads/2017/08/lightning-network-paper.pdf (accessed on 31 August 2018).
- Decker, C.; Wattenhofer, R. A fast and scalable payment network with bitcoin duplex micropayment channels. In Symposium on Self-Stabilizing Systems; Springer: Cham, Switzerland, 2015; pp. 3–18. [Google Scholar]
- Miller, A.; Bentov, I.; Kumaresan, R.; McCorry, P. Sprites: Payment Channels that Go Faster than Lightning. arXiv, 2017; arXiv:1702.05812. [Google Scholar]
- Raiden Network. Available online: https://raiden.network/ (accessed on 31 July 2018).
- Burchert, C.; Decker, C.; Wattnhofer, R. Scalable Funding of Bitcoin Micropayment Channel Networks. In International Symposium on Stabilization, Safety, and Security of Distributed Systems; Springer: Cham, Switzerland, 2017. [Google Scholar]
- Khalil, R.; Gervais, A. Revive: Rebalancing Off-Blockchain Payment Networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, Dallas, Texas, USA, 30 October–3 November 2017. [Google Scholar]
- Prihodko, P.; Zhigulin, S.; Sahno, M.; Ostrovskiy, A.; Osuntokun, O. Flare: An Approach to Routing in Lightning Network. 2016. Available online: https://bitfury.com/content/downloads/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf (accessed on 31 August 2018).
- Vu, B. Exploring Lightning Network Routing. Available online: https://blog.lightning.engineering/posts/2018/05/30/routing.html (accessed on 31 July 2018).
- Bonneau, J.; Miller, A.; Clark, J.; Narayanan, A.; Kroll, J.A.; Felten, E.W. Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In Proceedings of the 2015 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 17–21 May 2015; pp. 104–121. [Google Scholar]
- Croman, K.; Decker, C.; Eyal, I.; Gencer, A.E.; Juels, A.; Kosba, A.; Miller, A.; Saxena, P.; Shi, E.; Sirer, E.G.; et al. On scaling decentralized blockchains. In Proceedings of the International Conference on Financial Cryptography and Data Security, Christ Church, Barbados, 22–26 February 2016; pp. 106–125. [Google Scholar]
- Maximum Transaction Rate. 2016. Available online: https://en.bitcoin.it/wiki/Maximum_transaction_rate (accessed on 31 July 2018).
- Payment Channels. Available online: https://en.bitcoin.it/wiki/Payment_channels (accessed on 4 August 2018).
- C-Lightning. Available online: https://github.com/ElementsProject/lightning (accessed on 31 July 2018).
- Eclair. Available online: https://github.com/ACINQ/eclair (accessed on 31 July 2018).
- Lightning Network Specifications. Available online: https://github.com/lightningnetwork/lightning-rfc (accessed on 31 July 2018).
- Jain, R. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling; John Wiley & Sons: Hoboken, NJ, USA, 1990. [Google Scholar]
- Vu, B. Lightning User Experience: A Day in the Life of Carol. Available online: https://blog.lightning.engineering/posts/2018/05/02/lightning-ux.html (accessed on 31 July 2018).
- Osuntokun, O. AMP: Atomic Multi-Path Payments over Lightning. Available online: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html (accessed on 31 July 2018).
Simulator Function | Description | Simulated Functions | Peer | Message |
---|---|---|---|---|
find_route | Search for a payment route | SendPayment, FindRoutes, findPath, newRoute | Sender | - |
send_payment | Send a payment | SendToSwitch, SendHTLC, forward, handleLocalDispatch, HandleSwitchPacket, handleDownstreamPkt, AddHTLC, SendMessage | Sender | HTLCAdd |
forward_payment | Forward a payment | handleUpstreamMsg, processLockedInHtlcs, forward, handlePacketForward, HandleSwitchPacket, handleDownstreamPkt, AddHTLC, SendMessage | Hop | HTLCAdd |
receive_payment | Receive a payment | handleUpstreamMsg, processLockedInHtlcs, SendMessage, SettleHTLC | Receiver | HTLCAdd |
forward_success | Forward the successful result of a payment | handleUpstreamMsg, processLockedInHtlcs, forward, handlePacketForward, HandleSwitchPacket, handleDownstreamPkt, SettleHTLC, SendMessage | Hop | HTLCFulfill |
forward_fail | Forward the fail result of a payment | handleUpstreamMsg, processLockedInHtlcs, forward, handlePacketForward, HandleSwitchPacket, handleDownstreamPkt, ReceiveFailHTLC, SendMessage | Hop | HTLCFail |
receive_success | Receive the successful result of a payment | handleUpstreamMsg, processLockedInHtlcs, forward, handleLocalDispatch | Sender | HTLCFulfill |
receive_fail | Receive the fail result of a payment | handleUpstreamMsg, processLockedInHtlcs, forward, handleLocalDispatch, ReceiveFailHTLC | Sender | HTLCFail |
Type | Symbol | Definition |
---|---|---|
Network | Number of peers | |
Average number of channels per peer | ||
Tuner of network topology | ||
Uncooperative peers probability before HTLC establishment | ||
Uncooperative peers probability after HTLC establishment | ||
Average channel capacity | ||
G | Gini index of channel capacity | |
Payments | Average payment rate | |
Number of payments | ||
Tuner of payment amounts | ||
Fraction of same-recipient payments |
Symbol | Definition |
---|---|
Probability of payment success | |
Probability of payment failure for no route | |
Probability of payment failure for unbalancing | |
Probability of payment failure for uncooperative peers | |
Probability of unknown payments | |
T | Payment complete time |
Number of payment attempts | |
Payment route length |
(a) | |
Peers | Execution Time (h) |
100,000 | 6.64 |
200,000 | 15.92 |
500,000 | 49.25 |
700,000 | 64.68 |
1,000,000 | 104.15 |
(b) | |
Dijkstra Calls | Execution Time (h) |
58,927 | 4.98 |
303,374 | 28.3 |
Variable | Interval | Unity of Measure |
---|---|---|
[100,000 200,000 500,000 700,000 1,000,000] | - | |
[3 5 8 11] | - | |
[0 1 10 inf] | - | |
[0 0.01 0.1 1.0 10.0] | % | |
[0.01] | % | |
[100 1,000 10,000 100,000 1,000,000] | satoshi | |
G | [0.0 0.1 0.2 0.4 0.6 0.8] | - |
[10 100 1000] | payments per second | |
[10,000 100,000 1,000,000] | - | |
[1 2 3 4 5] | - | |
[0 10 20 40 50] | % |
Order of Magnitude (Satoshi) | |||||
---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | |
67.83% | 35.26% | 26.33% | 20.38% | 18.00% | |
27.61% | 29.57% | 23.76% | 19.85% | 17.43% | |
4.3% | 18.80% | 18.40% | 17.14% | 15.53% | |
2.6% | 8.81% | 13.79% | 13.88% | 14.14% | |
0.0% | 3.32% | 8.80% | 11.48% | 11.49% | |
0.0% | 0.98% | 5.08% | 8.19% | 9.69% | |
0.0% | 0.20% | 2.58% | 5.55% | 8.19% | |
0.0% | 0.06% | 1.26% | 3.53% | 5.51% |
Variable | Non-Stressing Value | Stressing Value |
---|---|---|
10 | 100 | |
10,000 | 100,000 | |
1 | 5 | |
0% | 50% | |
0% | 10% |
Variable | Default Value |
---|---|
100,000 | |
5 | |
inf | |
0% | |
0.01% | |
100,000 | |
G | 0.0 |
100 | |
100,000 | |
1 | |
0% |
Input Parameters | Output Measures | ||||||
---|---|---|---|---|---|---|---|
10 | 1 | 0.0% | 0.0% | 65.43% | 24.40% | 10.11% | 0.0% |
10 | 5 | 0.0% | 0.0% | 46.13% | 46.11% | 7.72% | 0.0% |
Input Parameters | Output Measures | ||||||
---|---|---|---|---|---|---|---|
10 | 1 | 0.0% | 0.0% | 65.43% | 24.40% | 10.11% | 0.0% |
100 | 1 | 0.0% | 0.0% | 43.88% | 25.17% | 30.92% | 0.0% |
Input Parameters | Output Measures | ||||||
---|---|---|---|---|---|---|---|
10 | 1 | 0.0% | 0.0% | 65.43% | 24.40% | 10.11% | 0.0% |
10 | 1 | 50% | 0.0% | 69.54% | 18.81% | 11.61% | 0.0% |
10 | 1 | 50% | 10.0% | 57.10% | 18.80% | 9.21% | 14.84% |
Input Parameters | Output Measures | ||||||
---|---|---|---|---|---|---|---|
10 | 1 | 0.0% | 0.0% | 65.43% | 24.40% | 10.11% | 0.0% |
10 | 1 | 0.0% | 10.0% | 55.21% | 24.31% | 8.51% | 11.92% |
10 | 4 | 0.0% | 10.0% | 38.27% | 46.10% | 6.47% | 9.13% |
3 | 59.61% | 23.34% | 16.77% |
5 | 99.34% | 0.31% | 0.13% |
8 | 99.82% | 0.01% | 0.0% |
11 | 99.86% | 0.0% | 0.0% |
0.0% | 99.36% | 0.0% |
0.01% | 99.34% | 0.0% |
0.1% | 99.27% | 0.1% |
1% | 98.32% | 1.04% |
10% | 87.47% | 11.84% |
T (ms) | (hops) | ||
---|---|---|---|
0 | 99.88% | 333.16 | 2.90 |
1 | 99.85% | 536.83 | 4.13 |
10 | 99.83% | 695.73 | 5.56 |
inf | 99.34% | 1391.92 | 10.34 |
0% | 0.13% |
10% | 0.13% |
20% | 0.12% |
40% | 0.10% |
50% | 16.06% |
© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Conoscenti, M.; Vetrò, A.; De Martin, J.C.; Spini, F. The CLoTH Simulator for HTLC Payment Networks with Introductory Lightning Network Performance Results. Information 2018, 9, 223. https://doi.org/10.3390/info9090223
Conoscenti M, Vetrò A, De Martin JC, Spini F. The CLoTH Simulator for HTLC Payment Networks with Introductory Lightning Network Performance Results. Information. 2018; 9(9):223. https://doi.org/10.3390/info9090223
Chicago/Turabian StyleConoscenti, Marco, Antonio Vetrò, Juan Carlos De Martin, and Federico Spini. 2018. "The CLoTH Simulator for HTLC Payment Networks with Introductory Lightning Network Performance Results" Information 9, no. 9: 223. https://doi.org/10.3390/info9090223