1 Introduction
Cryptocurrencies such as Bitcoin [16] or Ethereum [1] have a serious throughput problem [6]. They can process tens of transactions per second, whereas nonblockchain systems (credit card companies, interbanking payment systems, paypal, etc.) can handle tens of thousands of transactions per second. Various proposals have been made in an attempt to solve this throughput problem, e.g., sharding [14, 13] or sidechains [4]. However, payment networks (also known as channels) [7, 17, 2] are widely accepted to be the most promising of these socalled “layer 2” solutions, since payment networks allow data to go offchain securely.
Duplex micropayment channels [7], Lightning [17] or Raiden [2] are fast and scalable payment networks, where transactions between two users are executed in offchain twoparty channels. The blockchain is involved when opening a channel, as the foundation of a channel must be registered with the blockchain. In exceptions, if the two parties of a channel are in disagreement, the blockchain may also be involved as a safety net when closing a channel.
While the efficiency of channels is undisputed, payment networks have a reputation to be capital hungry and as such difficult to deploy. In this paper we want to better understand this demand for capital, studying the issue from an algorithmic perspective. We want to know the complexity an operator of a payment network, a Payment Service Provider (PSP), will face when setting up a payment network.
1.1 From Payment Channels to Network Design
Consider a PSP wants to create a payment network. The PSP can open a channel between any two parties; technically this can be achieved using multiparty channels [5], where the two parties and the PSP join a threeparty channel funded only by the PSP.
Algorithmically speaking, a payment network is a graph, where each undirected edge is a payment channel between the parties . When a channel (an edge) is established, PSP capital is locked into the channel on each side of the edge. This capital can then be moved on the channel, from to or vice versa, much like moving tokens from one side of an abacus to the other. For example, if initially a capital of 5 is locked on each side of the channel, then a transaction with a value of 2 from to will reduce the capital on ’s side to 3, and increase the capital on ’s side to 7. Transactions can also be multihop, moving capital on each edge of the path, in the direction of the path of the transaction. The only constraint is that the capital on any side of any edge must be nonnegative at all times.
The PSP needs to decide how to design the network, i.e., which edges (channels) the PSP should establish. Moreover, the PSP needs to decide how much capital it should assign to these newly established edges, in particular how much capital on each side of every edge.
Establishing a new channel not only involves capital (which is going to be reclaimed eventually), but will also cost (since each newly established channel needs to be registered with the blockchain). We model this channel opening cost as a constant, given that the fee the blockchain asks is (more or less) constant. The total cost is then the number of open channels (the edges of the network) times this constant cost to open each channel.
Our goal is to define a strategy for the PSP regarding which transactions to execute in order to maximize profit (fees from transactions minus costs to set up channels) and minimize capital (cryptomoney that is temporarily locked into channels). Note that there is a tradeoff between profit and capital, as more capital may allow to accept more transactions, earning fees for each transaction, hence increasing profit In particular, we discuss the following questions: What is the minimum capital needed to be able to accept a given set of transactions? What is the maximum profit we can achieve with a given capital? These questions are at the heart of understanding the Paretonature of the tradeoff between profit and capital in payment networks.
1.2 Related Work
Current work on payment channels has mainly focused on designing routing algorithms for the implemented decentralized payment networks, such as the Lightning [17] and Raiden [2] networks. Prihodko et al. [18] present Flare, an efficient routing algorithm for the Lightning network by collecting information on the network’s local topology. Malavolta et al. [15] introduce the IOU credit network SilentWhispers where they use landmark routing to discover multiple paths and multiparty computation to decide the amount of capital to be locked on each path. Roos et al. [19] propose SpeedyMurmurs, a routing algorithm for payment networks that uses embeddingbased path discovery to find routes from sender to receiver. However, all these protocols assume a network structure created by the individuals participating in the network. The goal is to discover the network topology and possible routes from sender to receiver of every transaction. Our objective is to design the optimal network structure assuming a central authority, the PSP.
An active line of research on payment channels is the construction of secure and private systems that can act as payment hubs. Heilman et al. [9] propose a Bitcoincompatible construction of a payment hub for fast and anonymous offchain transactions through an untrusted intermediary. Green et al. [8] present Bolt (Blind Offchain Lightweight Transactions) for constructing privacypreserving unlinkable and fast payment channels. However, they do not analyze how expensive the construction of a payment hub is for a PSP. In this work, we answer the following questions: is a payment hub a good solution for a PSP? How much capital is required to build a payment hub compared to the capital of a capitaloptimal network? These answers are highly relevant to the economic viability of a payment hub as a practical solution for payment networks, and ultimately whether payment networks can solve the eminent throughput problem of cryptocurrencies.
Our paper can be seen as a cryptocurrency variant of classic work on network design. It is as such somewhat related to fundamental work starting in the 1970s. For example, Johnson et al. [11] prove that given a weighted undirected graph, finding a subgraph that connects all the original vertices and minimizes the sum of the shortest path weights between all vertex pairs, subject to a budget constraint on the sum of its edge weights is NPhard. Another similar problem is the optimum communication spanning tree problem [10], whose input is a set of nodes, the distances and requests between them, and the goal is to find the spanning tree that minimizes the cost of communication (for each pair, the request multiplied by the sum of distance). Our channel design problem seems similar to these problems since the routing of a transaction matters, and our objective is to minimize the capital on the channels (like the original network design work wants to minimize the sum of the distances). However, in contrast with traditional network design, in payment networks the order of transactions matters, as the capital moves from one side of the channels to the other. Moving capital gives network design a surprising twist, as classic techniques do not work anymore. With the anticipated importance of payment networks, we believe one should have a fresh look at network design.
1.3 Our Contribution
We introduce an algorithmic framework for the channel network design problem. First, we study the offline problem, i.e., we are given the future sequence of transactions. We show that maximizing the profit given the capital assignments is NPhard, even for a single channel. Then, we present a fully polynomial time approximation scheme for the single channel case. Later, we consider the case where the PSP wants to maximize its profit and thus execute all profitable transactions. We prove that a hub (a star graph) is a approximation with respect to the capital. Moreover, we show the problem is NPcomplete under graph restrictions.
In addition, we examine online variants. First, we examine the online single channel case assuming the PSP wants to maximize its profit under capital constraints. We show that there is no deterministic competitive algorithm for adaptive adversaries. Later, we study the online channel design problem assuming all profitable transactions are executed. We show that the star graph yields an competitive algorithm, where denotes the optimal capital.
Omitted proofs are included in the Appendix.
2 Notation and Problem Variants
We assume the fee of a transaction on the blockchain to be constant, without loss of generality simply . The fee of a transaction in the payment network cannot be higher than the fee on the blockchain, or a potential user may prefer the blockchain over the payment network. A rational PSP will ask for a transaction processing fee which is as high as possible but lower than the blockchain fee, hence for . In our analysis we will usually assume that .
Let us now formally define the problems we will study.
Problem (General Payment Network Design).
Input: Capital , profit , the sequence of transactions with , each containing the sender node , the receiver node and the value of the transaction .
Output: Strategy
, a binary vector where the
position is if we choose to execute the transaction of the input and else. The graph is the network we created to execute the chosen transactions, where is the set of senders and receivers that participate in any transaction, is the set of channels we open and the capital on each side of each edge. Each transaction can be routed arbitrarily in , denoted by , i.e., (or ) if transaction is routed through edge from left to right (from right to left, respectively) and if transaction is not routed through edge .Our goal is to return (if it exists) a strategy , a graph and a routing subject to the following constraints:
The first inequality guarantees that the fees of the accepted transactions minus the cost of opening the channels is at least as high as the intended profit. The second inequality makes sure that at any time the capital on each side of each channel is nonnegative. The third inequality ensures that the used capital on the channels and the cost of opening the channels is at most the available capital.
Problem 2 in all its generality is difficult, as it features many variables. Consequentially, we mostly focus on the most interesting special cases of Problem 2: We consider transactions on a single channel between just two nodes. And we consider minimizing the capital assuming all profitable transactions are executed. Formally the problems we examine are the following.
Problem (Single Channel).
Given a sequence of transactions , where and are the nodes of the single edge , a capital assignment , and a profit , decide whether there is a strategy such that and .
Problem (Channel Design for All Transactions).
Given a sequence of transactions , return the graph that achieves maximum profit with minimum capital .
Problem (Capital Assignment and Routing).
Given a graph , a sequence of transactions and a capital , determine whether all transactions can be executed in with the given capital .
3 Offline Channel Design
In this section, we study the offline channels network design problem, i.e., we assume we know the future transactions (for the next period). First, we explore the network topology for the general problem. Then, we examine the case where we are given a specific capital (or even a capital assignment) and we aim to maximize the PSP’s profit, hence execute as many transactions as possible. We focus on solving the problem for a single edge of the network, since even in this simple case the problem is challenging. Later, we focus on minimizing the capital given the PSP wants to execute all the profitable transactions.
3.1 Graph Topology
We first prove some observations concerning the optimal graph structure. We consider as optimal the solution that maximizes the profit while respecting the capital constrains (optimization version of Problem 2). The graph of the optimal solution does not contain any node that sends and receives less than two transactions. Thus, during preprocessing we can safely remove all transactions that contain a node that is only sender or receiver of a transaction in this one transaction. The time complexity of this procedure is linear in the number of transactions. The optimal graph is not necessarily a tree (or forest).
Due to the complexity of the problem we focus on a single channel. It turns out that even for this degenerate case, the problem is far from trivial.
3.2 Single Channel
We now focus on a single channel. We prove that even in this case the problem of choosing the transactions that maximize the profit given capital assignments is NPhard and present an FPTAS.
Specifically, we are given a sequence of transactions on a single edge of a network and their values, the capital assignment on the edge and a target profit. Our goal is to decide whether we can execute at least as many transactions as the given target profit while respecting the capital constraints. Since the number of edges is fixed and equal to the profit now is the number of executed transactions (Problem 2). The problem is equivalent to a variant of the knapsack problem where each transaction represents an item. Each item has profit and either positive or negative size (values). The capacity of the knapsack is represented by the capital assignments and the goal is to maximize the profit while respecting the capacity.
Problem (Fixed Weight Subset Sum (Fwss)).
Given a set of nonnegative integers , and nonnegative integers and , is there a nonempty subset such that and ?
FWSS is NPhard.
Problem 2 is NPhard.
Proof.
We will reduce Fixed Weight Subset Sum (FWSS) to Problem 2.
Assuming we are given an instance of the FWSS, we present a polynomial time transformation to an instance of Problem 2. We first define the capital assignment on the edge , and the profit . Then, we define the sequence of transactions as follows: , and , . We will prove that there is a nonempty set that satisfies the FWSS problem if and only if we can choose transactions that satisfy the capital constraints and profit in the aforementioned instance.
Assume we have a "yes" instance of the problem. Then, we have chosen at least transactions to execute. We will show that this corresponds to choosing positive transactions that sum up to , thus to a solution of the FWSS problem. Towards contradiction, we examine the following three cases:

If the number of positive transactions is less than , the total profit is less than , since there are only negative transactions.

If the number of positive transactions is more than , then we violate the capital constraints, since , where corresponds to the chosen transactions.

Suppose the chosen transactions’ values sum to more than . Then, the capital constraint is violated.

Suppose the chosen transactions’ values sum to less than ; suppose the sum is with some . Then, then negative transactions to be executed can be at most . Thus, the profit is strictly less than . Contradiction.
Thus, a "yes" instance of our problem implies a "yes" instance of the FWSS problem. For the other direction, we will prove that if there is no subsequence of transactions of size at least that satisfies the capital constraints, then there is no subset of size that sums to in FWSS. Equivalently, we will show that if there is a subset of size that sums to in FWSS, then there exists a subsequence of transactions of size at least that satisfies the capital constraints. Suppose there is a nonempty set such that and . Then we can execute the transactions that correspond to the chosen ’s with exactly the capital, which will be transfered on . Then, we can execute all the negative transactions since they are many with values , thus we need capital. Therefore, we can execute transactions, achieving the required profit while satisfying the capital constraints. ∎
Both FWSS and Problem 2 are also polynomially verifiable, hence NPcomplete.
The classic dynamic programming approach that typically yields a polynomial time algorithm when profits are fixed is not efficient since in this variation we cannot optimize using the minimum value at each step due to negative values. Instead, we present a fully polynomial time approximation scheme (FPTAS).
Algorithm MaxProfit is a fully polynomial time approximation scheme for Problem 2.
Proof.
The running time of the algorithm is , which is polynomial in both and .
We will prove that the profit of the output of algorithm MaxProfit is at least times the optimal. We denote by the set of transactions returned by the algorithm, the set returning the optimal profit and the profit from the set of transactions . Since we scaled down by and then rounded down, for every transaction we have that . Therefore, the optimal set’s profit can decrease at most , . The dynamic program returns the optimal set for the scaled instance. Thus, , since .
∎
Scaling to many channels. Unfortunately, even when the graph is a tree, algorithm 1 does not scale efficiently. Creating an
dimensional tensor for the dynamic program, where
are the edges of the tree, has time complexity where is the maximum capital from all edges. Even if we bound the capital by a polynomial on the algorithm remains exponential due to the number of edges on the exponent. In the general case where the graph could contain cycles, the problem becomes even more complex. Now, we need to additionally consider all possible routes for each transaction; this adds an exponential factor on the running time of the algorithm.Since Problem 2 is complex, we study special cases that might be useful in practice and provide an insight to the general problem.
3.3 Channel Design for Maximum Profit
In this section, our goal is to find the minimum capital for which we can achieve maximum profit, i.e., execute all profitable transactions (Problem 2).
At first, we note some simple observations for the graph structure. Then, we prove that any star graph is a approximate solution with respect to the capital, but even the “best” star is not an optimal solution. Last, we prove the problem is NPhard when there are graph restrictions.
Throughout this section, we refer to the optimal solution of Problem 2 as the optimal network for maximum profit.
When the capital is unlimited, the optimal network for maximum profit does not contain cycles. When the capital is unlimited, there exists an algorithm, with time complexity , where denotes the number of transactions, that returns the optimal network for maximum profit. The optimal network for maximum profit is not necessarily a connected graph. We refer to transactions that increase the PSP’s profit as profitable transactions. We assume all nodes participate in at least two transactions (Lemma 3.1). Not all transactions are profitable transactions.
Despite Lemma 3.3, we note that payment channels are monetary systems. As such, large companies are expected to participate in the network as highly connected nodes, ensuring that the optimal graph is one connected component. Thus, for the rest of the section we can safely assume that the optimal graph is connected.
We will now define some formal notation to prove that choosing any star as the graph to route all transactions requires at most twice the capital of the optimal graph. This immediately implies we have a approximation to Problem 2.
Now, suppose we can update the capital of an edge before executing each transaction. This way we can guarantee there is enough capital on all channels for each transaction execution. These updates are for free, like assigning tokens, and we use them as a stepping stone to calculate the total capital (amortized analysis). Let us denote the additional capital required at the edge , for transaction with direction from to on graph . Now, we have that the total capital on graph , denoted by , is
Moreover, let denote the optimal graph and the set of nodes involved in .
We will show that the capital used to route a sequence of transactions on any star that contains the same set of nodes as the optimal graph is at most twice the capital used by the optimal solution for the same sequence.
Any star graph yields a approximate solution for Problem 2.
Proof.
To prove the theorem, we just need to prove that for any sequence of transactions , for any star graph , .
We will show that we can execute on the star graph the same sequence of transaction as the optimal solution with twice as many tokens (amortized capital).
Initially we have zero tokens on all edges on both the optimal and the star graph. Every time a new transaction comes the optimal solution finds a path from sender to receiver. For every edge on this path the optimal solution assigns tokens. Then, we assign on the star, , tokens on the edges and , where is the central node on . The only exceptions are the sender and receiver nodes, and respectively, where the tokens are initially placed on and to execute the transaction. Thus, for every transaction the sum of the tokens used on the star graph are twice the sum of the tokens used on the optimal solution. Therefore, the overall required capital on the star is at most twice the optimal capital, .
To complete our proof, we need to show we assigned in total enough tokens to execute the given sequence of transactions. When a new transaction comes from to , we only need to guarantee there enough tokens on and .
Obviously, if a transaction needs additional tokens to be executed on the optimal graph then the aforementioned strategy guarantees the additional tokens for the star graph as well.
If there are already some tokens on the optimal graph for the sender then either he was previously an intermediate node or a receiver node. In both those cases the same amount of tokens would have been stored on as well. With a similar argument, if there were some tokens for the last edge to reach the receiver on the optimal graph then was either an intermediate node or a sender. Again, in both those cases the same amount of tokens would have been assigned to on the star.
∎
The star graph is not an optimal solution for Problem 2.
Discussion. The centralized nature of the star is quite convenient for a payment network operated by a PSP. The star alleviates the problem of participation incentives detected on decentralized payment networks; now the participants of the network can be online only when they want to execute a transaction. Although the star graph is not optimal, it is a good enough solution for a PSP, since the capital he needs to lock in the channels is at most twice the minimum. Thus, payment hubs are an economically viable solution for the throughput problem on cryptocurrencies.
3.4 Channel Design with Graph Restrictions
An interesting variation of the problem is when the network has restrictions (Problem 2). Instead of allowing all possible channels, we assume some of them cannot occur in real life. In this case, we are given a graph with all the potential channels, the sequence of transactions and the capital, and we want to find the induced subgraph that maximizes the profit. We prove that the problem of deciding whether all given transactions can be executed in the given graph with a fixed capital is NPcomplete.
The graph is given so the capital needed to open the channels is fixed in each given instance. Thus, we assume the capital corresponds solely to the capital we lock on the edges but not the one we require to open the channels. Problem 2 is NPcomplete.
4 Online Channel Design
In this section, we study the online case, assuming no prior knowledge for the future transactions. When there is a transaction request we instantly decide whether to execute it or not through our network, assuming we have enough capital on the edges of the path we want to route the transaction. If there is not enough capital on some of the edges, we can refund a channel, which costs 1, the same as opening a new channel.
4.1 Single Channel with Capital Constraints
Similarly to the offline case, we first focus on the simpler case where we have a single edge and limited capital. The transactions arrive online, for each transaction we immediately decide whether it is accepted.
There is no competitive algorithm for adaptive adversaries.
Proof.
Suppose we have a channel with . Transactions from left to right have positive values, those from right to left have negative values. Let us consider two different transaction sequences:
Apart from the second transaction, both sequences are identical: The first transaction has value , starting with the third transaction we always move the complete capital with every transaction. The only difference is the second transaction.
If some online algorithm accepts the first transaction, then the adversary presents the first sequence; if the online algorithm denies the first transaction, then the adversary reveals the second sequence. Therefore, no matter whether this online algorithm accepts the first transaction or not, it can at most accept one transaction, while the optimal offline algorithm can accept almost all transactions (in case of the first sequence, the offline algorithm only needs to deny the first transaction, in case of the second sequence it will accept all transactions). ∎
4.2 Channel Design for Maximum Profit
We assume again that we want to execute all transactions, thus the optimal graph does not contain cycles. Our objective is to minimize the capital, given all transactions will be executed through our payment network. Wlog, we assume the PSP is a node in the network. Similarly to the offline case, we show that constructing a star network to connect the nodes with payment channels is a good solution. Specifically, we present a logcompetitive algorithm that takes advantage of the star graph structure.
In Algorithm OnlineMaxProfit, we gradually form a star where the center is the PSP. At each step, we check whether there is enough capital on the edges to and from the center to execute the current transaction. If the capital on an edge is smaller that the value of the current transaction, we refund the channel and add to the capacity of this edge twice the value of the current transaction.
Algorithm OnlineMaxProfit is competitive.
Proof.
The star is a approximation to the optimal offline solution, thus we start with a competitive ratio of . The way we update the capacities, each time adding twice the value of the transaction if the capacity is less than the transaction’s value, yields also a competitive ratio of two on the edges’ capacities. Moreover, at each such step we at least double the capacity of an edge thus we reach the edge’s optimal capital, , in steps. If we sum over all edges, in total we refund the channels at most times, where is the number of nodes in the network and the edges’ optimal capital of the offline solution. Therefore, algorithm OnlineMaxProfit returns , while the offline solution requires . This yields a competitive ratio of . ∎
5 Conclusion
We introduced a graph theoretic framework for payment networks. We studied the problem for a specific epoch, i.e., for a fixed number of transactions. This restriction is due to privacy issues, such as timing attacks on the payment network that can leak information on the customers’ personal data. We tried to maximize the profit (the number of accepted transactions minus the number of generated channels) and to minimize the capital needed to execute these transactions. Due to the multiobjective nature, there are several versions of this problem. In this paper, we mainly focused on two interesting variations:

How to choose transactions to execute on a single channel with given capital assignments to maximize the profit,

How to design a network and assign capitals to accept all transactions and minimize the needed capital.
It turns out, these two problems are challenging, as we show that the first problem and a variation of the second one are both NPhard. We propose a dynamic programming based algorithm for the single channel problem and show that it is an FPTAS. For the network design and capital assignment problem, we show that stars achieve approximation ratio . In other words, hubs are not only an implementable and privacyguaranteed solution, as mentioned in [9] and [8], but also a satisfactory solution for PSP from the profitmaximization point of view.
We also studied the online versions of these problems. For the single channel case we show that it is impossible to design a competitive algorithm against an adaptive adversary. For the online channel design for maximum profit, we devise an competitive online algorithm based on the star structure.
The results presented in this paper and the proposed algorithms can be applied to other fields such as traffic network design. For example, every airline would want to maximize the profit and to minimize the costs (of creating new routes and purchasing new airplanes). Interestingly, similar to what we discovered, hubs are indeed used by almost all airlines, e.g., most flights of the Turkish airline departure from or fly to Istanbul.
Apart from capital assignment, fee assignment of payment networks [3] is also related to the traffic network design problem. One need to pay for using highways in some countries (e.g., Greece, China and France), thus the companies need to decide which cities are connected by highways and how much one needs to pay for every path. In this way, the drivers prefer highways (analog to the payment channels) to other slow paths (analog to the main chain), and hence the profit is maximized.
References
 [1] Ethereum white paper. URL: https://github.com/ethereum/wiki/wiki/WhitePaper.
 [2] Raiden network. 2017. URL: http://raiden.network/.
 [3] Georgia Avarikioti, Gerrit Janssen, Yuyi Wang, and Roger Wattenhofer. Payment network design with fees. 2018. URL: https://github.com/zetavar/PaymentNetworkDesignwithFees/blob/master/Payment_Network_Design_with_FeesFull_Version.pdf.
 [4] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille. Enabling blockchain innovations with pegged sidechains. 2014. URL: https://www.blockstream.com/sidechains.pdf.
 [5] Conrad Burchert, Christian Decker, and Roger Wattenhofer. Scalable Funding of Bitcoin Micropayment Channel Networks. In 19th International Symposium on Stabilization, Safety, and Security of Distributed Systems (SSS), Boston, Massachusetts, USA, November 2017.
 [6] Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels, Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin Gün Sirer, Dawn Song, and Roger Wattenhofer. On scaling decentralized blockchains. In Financial Cryptography and Data Security, pages 106–125. Springer Berlin Heidelberg, 2016.
 [7] Christian Decker and Roger Wattenhofer. A fast and scalable payment network with bitcoin duplex micropayment channels. In Andrzej Pelc and Alexander A. Schwarzmann, editors, Stabilization, Safety, and Security of Distributed Systems, pages 3–18, Cham, 2015. Springer International Publishing.
 [8] Matthew Green and Ian Miers. Bolt: Anonymous payment channels for decentralized currencies. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS ’17, pages 473–489, 2017.
 [9] Ethan Heilman, Leen Alshenibr, Foteini Baldimtsi, Alessandra Scafuro, and Sharon Goldberg. Tumblebit: An untrusted bitcoincompatible anonymous payment hub. In Network and Distributed Systems Security Symposium 2017 (NDSS), February 2017.
 [10] T. Hu. Optimum communication spanning trees. SIAM Journal on Computing, 3(3):188–195, 1974. URL: https://doi.org/10.1137/0203015, arXiv:https://doi.org/10.1137/0203015, doi:10.1137/0203015.
 [11] D. S. Johnson, J. K. Lenstra, and A. H. G. Kan Rinnooy. The complexity of the network design problem. Networks, 8(4):279–285. URL: https://onlinelibrary.wiley.com/doi/abs/10.1002/net.3230080402, arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.1002/net.3230080402, doi:10.1002/net.3230080402.
 [12] Richard M. Karp. Reducibility among Combinatorial Problems, pages 85–103. Springer US, Boston, MA, 1972. URL: https://doi.org/10.1007/9781468420012_9.
 [13] Eleftherios KokorisKogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford. Omniledger: A secure, scaleout, decentralized ledger via sharding. 2017.
 [14] Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena. A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 17–30. ACM, 2016.
 [15] Giulio Malavolta, Pedro MorenoSanchez, Aniket Kate, and Matteo Maffei. Silentwhispers: Enforcing security and privacy in decentralized credit networks. In Network and Distributed Systems Security Symposium 2017 (NDSS).
 [16] Satoshi Nakamoto. Bitcoin: A peertopeer electronic cash system. 2008.
 [17] Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable offchain instant payments. 2015. URL: https://lightning.network.
 [18] Pavel Prihodko, Slava Zhigulin, Mykola Sahno, Aleksei Ostrovskiy, and Olaoluwa Osuntokun. Flare: An approach to routing in lightning network. 2016. URL: https://bitfury.com/content/downloads/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf.
 [19] Stefanie Roos, Pedro MorenoSanchez, Aniket Kate, and Ian Goldberg. Settling payments fast and private: Efficient decentralized routing for pathbased transactions. In Network and Distributed Systems Security Symposium 2018 (NDSS).
Appendix A Omitted Proofs
Proof of Lemma 3.1.
Assume node is in the graph and sends and receives less than two transactions. Since is part of the graph, it has at least one neighbor. Choose an arbitrary neighbor of , connect all remaining neighbors of directly with (if not already connected), and then remove . For each neighbor of node , increase the capital of edge in the new graph by the capital of the removed edge (on both sides of the edge). Now all transactions routed originally through edge can be routed in the new graph through edge , the new total capital needed is at most the same as the old capital, and there is enough capital to route all previously routable transactions. We denote by the profit of the optimal solution. The graph without has at least one edge less. Thus, the profit of the new graph for (at least) the same set of transactions is at least , since setting up the channel (edge) costs but ’s transaction fees are at most . So we are better off without node . ∎
Proof of Lemma 3.1.
Suppose we are given the following sequence of transactions and capital where :
For this example, we will show that the optimal solution that maximizes the profit given the capital returns a graph that contains a cycle.
One solution is the graph , where , . The profit in is , since all transactions are executed and connect directly and channels are opened. The spent capital is since we open edges and lock capital on the sender side of each edge.
If the graph is not connected we lose at least transactions and remove at most edges. So, the total profit decreases by at least , hence the optimal graph is connected.
Suppose now the optimal graph does not contain any cycle. Since the optimal graph is connected, it is a spanning tree. Let’s denote by the number of leaves in the tree with , since the spanning tree has edges. If we want to have at least the profit of the cycle described above, we must deliver at least transactions, since we only saved the opening cost of a single edge.
We can see that the capital locked on the edges connecting these leaves is at least , since, for every node, both transactions involved are either outgoing or incoming. For every other edge, the capital locked on it is at least . Therefore, the total number of locked capital is at least . ∎
Proof of Lemma 3.2.
We will reduce Subset Sum (SS) [12] to FWSS.
SS: Given a set of integers , and integer , is there a nonempty subset such that ?
Given an instance of SS, we define different instances of FWSS, one for each possible value of , where the set of integers and the integer value are the same for every FWSS instance as in SS. If one of the FWSS instances returns “yes” then we return “yes”, else we return “no”.
If any instance of FWSS returns “yes”, then the same subset satisfies the SS problem, thus it must return “yes”.
If all instances of FWSS return “no”, then there is no set satisfying the SS problem, since we checked all possible set sizes. Thus, SS must return “no” as well. The transformation is polynomial to the input.
∎
Proof of Lemma 3.3.
Suppose the optimal graph contains a cycle. We choose an arbitrary edge of the cycle, denoted , where the nodes of edge . We remove edge and reroute all transactions using edge through the path from to . This path exists since removing an edge from a cycle cannot disconnect the graph. The profit of the graph without is the profit of the optimal graph plus (the cost of opening edge ). This is a contradiction, since the optimal network maximizes the profit. ∎
Proof of Lemma 3.3.
We present the following algorithm:

Traverse the input transactions and create a list that contains the number of transactions between every two nodes (potential edges).

Traverse list as follows:
If the number of transactions is at least and adding the edge between the two nodes does not form a cycle, add the edge to the (initially empty) graph.
The algorithm guarantees there is a path between every two nodes that want to execute at least two transactions (Lemma 3.1). Thus, all transactions that increase the PSP’s profit are executed. Moreover, the algorithm does not contain a cycle, so the output graph is minimal regarding the edges.
The first argument maximizes and the second minimizes for the given sequence of transactions. Therefore, the algorithms returns a graph that achieves maximum profit ().
The running time of the algorithm is linear to the number of transactions, .
∎
Proof of Lemma 3.3.
Suppose the graph of the optimal solution is always connected. Assume now we are given the following sequence of transactions: . Since the optimal graph for this example is connected, there are at least three edges in the graph. Thus, the optimal profit is . However, if we consider the graph with edges and , the PSP’s profit is , greater than the profit of the optimal solution, which is a contradiction. ∎
Proof of Lemma 3.3.
Suppose all transactions are profitable transactions. Lets assume we are given the following sequence of transactions: . It is straightforward to see that any solution that executes all transactions must return a connected graph. However, we showed in the proof of Lemma 3.3 that the optimal graph for this example is not connected. Thus, there are transactions that are not executed in the optimal solutions and hence they are not profitable transactions. ∎
Proof of Lemma 3.3.
We present a sequence of transactions for which any star graph requires larger capital to execute all transactions than the optimal solution, as illustrated in Figure 1. Moreover, finding the optimal solution is not trivial in our example, even though we only consider unitary transactions.
The sequence of transactions is the following
Figure 1 illustrates the optimal graph (not necessarily unique); the capital needed to execute all transactions is , which is the least possible since any tree with seven nodes has six edges and all of them are used at least one time with unitary values (in this example). There are seven different stars, one for each node as a center. It is easy to see that the capital needed for each one of them is at least , which is strictly larger than the optimal. ∎
Proof of Theorem 3.4.
We will reduce Partition, a known NPcomplete problem [12], to Problem 2.
Partition: Given a finite set and a size for each , is there a subset such that ?
Given an instance of Partition we define an instance of Problem 2 as follows:
Let .We consider the graph with four nodes and edges . We define the capital and the sequence of transactions
We will prove that this instance of Partition is a “yes” instance if and only if all transactions can be executed in with the given capital . We denote by the last transactions defined above. Suppose all the transactions in the instance we defined can be executed using the capital . This implies we can divide into two groups that each sum to at most and route each group through one of the two paths from to in . Since , we have . We define the set . It holds that
For the opposite direction, suppose we cannot execute all transactions in with capital . Since the first four transactions can always be executed with capital , we cannot execute all transactions in with capital . Thus, in the optimal solution we cannot partition the transactions in in two groups with equal sum. Since we defined the values of transactions in to be the sizes of the elements in , we conclude there is no subset such that . ∎
Comments
There are no comments yet.