Routing Cryptocurrency with the Spider Network

Abstract

With the growing usage of Bitcoin and other cryptocurrencies, many scalability challenges have emerged. A promising scaling solution, exemplified by the Lightning Network, uses a network of bidirectional payment channels that allows fast transactions between two parties. However, routing payments on these networks efficiently is non-trivial, since payments require finding paths with sufficient funds, and channels can become unidirectional over time blocking further transactions through them. Today's payment channel networks exacerbate these problems by attempting to deliver all payments atomically. In this paper, we present the Spider network, a new packet-switched architecture for payment channel networks. Spider splits payments into transaction units and transmits them over time across different paths. Spider uses congestion control, payment scheduling, and imbalance-aware routing to optimize delivery of payments. Our results show that Spider improves the volume and number of successful payments on the network by 10-45% and 5-40% respectively compared to state-of-the-art approaches.

payGo: Incentive-Comparable Payment Routing Based on Contract Theory

“…In Figure 4, for example, P1 and P2 are $50 and $20, respectively, and, initially, nodes B and C each have $100 for deposit. Then, the µ e of P2 is 20 1D B,A , and thus C (B,C) is approximately $70 without dispute. The expected capacity will decrease to $55 if D B,A has an additional queueing delay D p pay,e = 3D.…”

“…Asymmetric PBT flows can lead to balance depletion in the channel; channel 2 of node n can support only one more payment for two tokens. Rebalance between the channels (for example, CH1 and CH2 of node n) requires blockchain access for closing and opening the channel again with new balances; otherwise, circular PBTs, introduced in Revive [30] and Spider [20], can be used to adjust the poorly balanced channels in a node without on-chain access. For atomic operation of a PBT, conditional BP or hashed time-locked contracts (HTLCs) are used in Bitcoin and Ethereum; this ensures that a payee will receive money in PCN where users distrust each other.…”

“…Several routing protocols previously proposed for PBTs (or even for computer networks) can be used to find candidate routes in payGo [15], [20], [21]. For example, in [21], the Edmonds-Karp algorithm [33] is used to find multi-paths from a payer to a payee in a PCN.…”

“…Also, Rayo and Fulgor [19] provided privacy and concurrency mechanisms in PCNs. Recently, Spider [20] and Flash [21] adopted atomic multi-path payments to increase throughput by maximizing network flows. RobustPay [22] is a payment routing protocol, achieving robust, efficient, and distributed PBTs for unresponsive and uncooperative users.…”

A Composable Security Treatment of the Lightning Network

“…Subsequent work on the topic dealt with either improving payment networks by utilising more expressive blockchains such as Ethereum [16], hardware assumptions, see e.g., [19], or extending its functionality beyond payments, to smart contracts, [15] or finally enhancing their privacy, see e.g., [14], [20], [21]. Additional work looked into developing supporting protocols for the payment networks such as rebalancing [22] or finding routes in a decentralised fashion [23], [24]. With respect to idealising the payment network functionality in the UC setting, a number of previous papers [13], [14], [15], [16] presented ideal functionalities abstracting the concept, but they did not prove that the lightning network realises them.…”