1 Introduction
A main approach to solve the scalability problem in Bitcoin is to use offchain transaction channels that allow parties to transfer funds while communicating directly, and only occasionally to settle on the blockchain. The recent deployment of SegWit, a solution to transaction malleability (among other benefits) opens the path for better constructions of offchain transaction channels. While transaction channels themselves are limited to exchanges between pairs of individuals, further developments like the lightning network [PD16] allow to route payments over longer paths and thus can allow the construction of a well connected network of payment channels that can be used to transfer money quickly and with relatively little interaction with the blockchain. For additional discussion of micropayment channels and scalability, see, e.g., [HS, DW15, CDE16].
One of the key unknowns regarding fast payment networks is the economic effect that they will have on the Bitcoin fee market. If the blockchain is used less often, fees to miners are paid less frequently and competition for space in blocks declines. Bitcoin’s security depends heavily on having a large amount of computational power invested in solving proofofwork puzzles, making it hard for attackers to double spend or censor transactions in the currency. As the block reward in Bitcoin declines (halving every four years), the reliance on fees increases and these must suffice to pay for enough mining by honest participants.
In this work we explore the economics of Bitcoin transaction channels, and in particular the economic equilibrium that results from the introduction of fastpayment networks to the Bitcoin ecosystem. Our main contribution is a theoretical framework in which one can reason about the usage of payment channels and the cost of committing records to the blockchain. We explore different topologies of payment channels and find the market equilibrium that dictates (among other things) the fees that will be collected by miners, the transactions that pass through the lightning network or directly through the blockchain, and the transactions that do not take place (e.g., micro transactions for which the fees are too high on both alternatives).
Summary of our findings
While our findings strongly depend on the assumptions we have made regarding the distribution of payment sizes and willingness to pay fees, we generally find that the revenue obtained by miners can sometimes be lower when lightning networks are deployed compared to when they are not, unless extremely large numbers of participants take part in transacting (there too, results depend on the distributional assumptions). Naturally, the addition of payment channels does indeed result in very high transaction throughputs in the system overall.
The implications for Bitcoin are that the revenue from fee payments alone might be insufficient to support the security of the system. Still, we caution that our results should be taken with a grain of salt: we account for very simple topologies but hope our initial exploration will inspire further exploration of similar models.
1.1 An overview of our approach
The first step taken when modeling the effects of different transaction methods is to select a model for the demand for transactions — a model specifying which participants want to send money, to whom, what amount is transfered, and how much fee the sender is willing to pay to complete the transfer.
A second aspect that needs to be determined is the topology of payment channels that is set in the system: which pairs of participants choose to establish channels between them, and how much funding is dedicated to each such channel. This is crucial in determining the lifetime of the channel given different use patterns.
Finally, with this information in hand we set out to compute the demand for blockchain records. Such demand stems from two main sources: The establishment and settlement of existing lightning channels, and direct transfers that occur on the blockchain. Given that the block size is limited, the daily supply of new transaction records is fixed, and we are thus able to compute the market equilibrium fee for records.
The mechanics of transaction channels
Transaction channels are typically established by locking funds using a single blockchain transaction. The channel state is then updated by the two participants by exchanging transactions that update the division of funds from the locked amount. These transactions are not typically transmitted to the blockchain. Each update represents a new division of funds and usually only the last transaction is committed to finalize the transfer. The transactions exchanged by the two participants on each channel are set up so that if one of the participants disappears or tries to take funds that are not his (e.g., by placing a transaction that represents an old state on the blockchain). The other participant can recover his funds or even punish his counterpart by taking all funds in the channel. For the purpose of this work, we assume all channels are established and settled cooperatively, as we aim to consider the expected behavior of the market under “normal” circumstances.
We additionally assume that channels can be settled and reopened with a single transaction, which may be of larger size in the network. We assume the parties that transfer money back and forth do so according to a random process, and that they therefore occasionally end up in a state where all funds in the channel are directed to one of the users. In this case, the channel can only be used to transfer money in one direction and the channel must be reset or refunded to allow flow in the other direction. Clearly, if the amount of liquidity in the channel is high this event will occur rarely. It is therefore of paramount importance to establish the typical amount of funding in each channel. Since liquidity that is locked within the channel represents money that is not invested elsewhere, we consider the cost of holding liquidity in the channel as the lost income from interest payments on this sum. Stated differently: we allow participants to borrow as much money as they want to fund their transaction channels, and the cost for such payments is simply the interest rate in the economy. This cost is the de facto limiting factor for the lightning network.
Models for the demand for transactions
We explore two primary models for the demand for transactions. The first is a model in which participants are paired and only transact with their direct partner. While this is not a realistic depiction of the flow of money in an economy, it is in some sense a bestcase setting for transaction channels, as no routing of payments is required by the system. The topology of channels in this case is also simple: just create channels between transacting pairs if it is profitable to do so. In this setting we explore several variants: one in which transactions occur with equal probability in each direction, and one in which transfer is asymmetrically biased in one direction. Another axis along which we vary our analysis is regarding the size of payments. We assume in one case that payments come from a uniform distribution, and in another case that they are derived from a powerlaw distribution (as is typically the case in real life data).
Our second model assumes that all participants may pay each other, and that payments occur between participants that are chosen uniformly at random. Here we focus on an analysis of a payment network that includes a single payment hub. The hub needs to maintain additional liquidity, but allows participants that are connected to it to route payments to everyone else. We find surprisingly that the results bear great similarity to the pairs model (except for extra payments for the additional liquidity).
Implementation
The code used for our simulations can be found at: https://github.com/
erelsgl/bitcoinsimulations.
2 Model
We analyze the market for records on the blockchain. A record is a part of a block, in which a single transaction is recorded. Each record has a marketprice [bitcoinsperrecord], which is the miningfee for a blockchain transaction. The marketprice is determined as a price in which the supply of records equals the demand for records.
The supply in our market is quite simple: the bitcoin protocol ensures that the supply of records per day is fixed. We denote this parameter by . As of this writing, the value of this parameter is [recordsperday]. The total revenue of the miners, which is an important factor in the security of bitcoin, will be [bitcoinsperday].
The demand is driven by the need of users to transfer money to other users. The demand is determined by the following sets of parameters:

The number of times that user wants to transfer money to user
per day is a Poisson random variable with mean value
[transfersperday]. 
The size of transfers from user to user is [bitcoinspertransfer]. This models the fact that some users do microtransfers while others do bulk transfers. We will sometimes assume that
is drawn from a probability distribution such as uniform or powerlaw.
We assume that the transfersize is constant for each pair, i.e, it is drawn randomly once for each pair and then remains fixed.

The utility that user gains from each transfer to user is [bitcoinspertransfer]. We will often assume that the utility is proportional to the transfer size, i.e, , where is some constant fraction in .
Each time user considers to transfer money to user , he compares three options: blockchain transfer, lightning transfer, or no transfer at all. The user selects the option with the highest net gain. In the case of a blockchain transfer, the net gain is minus the blockchain fee . In the case of a lightning transfer, the net gain is minus the lightning fee, which is derived from the cost of maintaining the lightning channel. In case of no transfer, the net gain is zero.
The lightning fee is derived from several parameters which determine the cost of using lightning:

The number of blockchain records required for a channelreset transaction, denoted by . a reset transaction is slightly larger than a standard transaction, so is a number between and [records]. Therefore the cost of resetting a lightning channel is [bitcoins].

The (fixed) interest rate [per day]. A user who wants to use lightning has to lock money in channels, and thus he has to pay an economic cost determined by . This means that in general a user will not want to lock all his money in lightning channels; he will look for the optimal amount to lock such that the total cost (economic cost plus channelreset cost) is minimized.
We study several special cases for the transfer matrix :
 Pairs:

the users are divided in pairs, e.g. , , etc. All transfers are only inside each pair, i.e, for every , only and are nonzero. This is in some sense the “best case” for lightning, since we need a channel only between user to user .
 Symmetric Uniform:

for all and .
 Asymmetric Uniform:

for each pair , and . I.e, the pairs are asymmetric, either user transfers more money to user or viceversa.^{2}^{2}2note that in general, it is possible that some agents accumulate money endlessly while other agents spend money endlessly; this can be explained by assuming that they do some transfers outside bitcoin. Alternatively, we can assume a special topology in which all nodes have an even degree and have positive net transfer in exactly half their edges.
We also study several possible lightning topologies:
 Pairs:

each user has a channel only with user .
 Star:

there is a single node (“bank”) which is connected to all users; all transfers go through the bank.
3 Analysis of a Single Channel
The basic buildingblock for our analyses is the analysis of a single channel between two users, Alice and Bob. We first analyze the expected channel lifetime for a given channel capacity and distribution of transfers, and then find the optimal channel capacity.
We checked two cases related to the transfer rates: in the symmetric case the transferrate from Alice to Bob equals the transferrate from Bob to Alice; in the asymmetric case the transferrates are different. For brevity, this paper presents only the results for the symmetric case; the results for the asymmetric case are qualitatively similar.
3.1 Channel Lifetime
Theorem 3.1 (Lifetime of Symmetric Channel).
Let Alice and Bob have a channel with bitcoins, which they use to transfer single bitcoins to each other at a time. Each transfer consists of one coin sent by Alice with probability and by Bob with probability . Then the expected lifetime of the channel from the state where Alice has bitcoins and Bob has bitcoins is
Proof.
Let denote the expected channel lifetime from the state where Alice has bitcoins. The recurrence relation can be derived from the asymmetric case, by substituting :
Note that , since if Alice has zero in her account and wants to make a transfer, then the channel is reset. Similarly, corresponds to the case where Bob has zero in his account.
The associated homogeneous recurrence relation is , with characteristic equation . The roots of the associated characteristic equation are , and so the general solution has the following form, where are constants:
Recall that in general, if is a root with multiplicity of the characteristic equation, there exists a general solution to the recurrence such that for some constants :
(1) 
The particular solution, given by Equation 1, has , , and , so for some constant . Then
The particular solution is
Adding the homogeneous and nonhomogeneous parts
The boundary condition gives , while gives . Then for all , the expected number of transfers made on the channel is:
This completes the proof. ∎
Corollary 3.2.
Let Alice and Bob have a channel with bitcoins, which they use to transfer single bitcoins to each other at a time. Both Alice and Bob transfer to each other using a Poisson process with mean . Then the expected number of days that the channel from the state where Alice has bitcoins and Bob has bitcoins is:
Proof.
When the players send to each other with equal means, Alice sends to Bob a single unit with probability and Bob sends to Alice with probability . From Theorem 3.1, the expected lifetime from the state where Alice has bitcoins is . To obtain a solution in days, we divide this by the mean number of transfers per day, which is . ∎
3.2 Channel Optimal Initialization
Given the expressions for the channel lifetime, Alice and Bob can calculate the optimal way to initialize a channel with a fixed capacity , i.e. the initial balance that maximizes the expected lifetime of the channel.
Lemma 3.3.
The optimal initialization of a symmetric channel with capacity is for both Alice and Bob to start with bitcoins.
Proof.
Given that the expected channel lifetime from the state where Alice has bitcoins is , the lifetime is maximized when . Then an optimally initialized symmetric channel is expected to last for: . ∎
So far, we assumed that each transfer between Alice and Bob consists of a single coin. However, it is easy to generalize the results to a situation in which each transfer between Alice and Bob consists of bitcoins, for some constant . In this case, the channel funding is given in transfers, i.e, the channel lifetime is when the channel is funded with bitcoins.
3.3 Channel Optimal Capacity
Alice and Bob have two options for performing a sequence of transactions, namely sending money to each other on the blockchain or through a channel in the lightning network. In the case of blockchain transactions, there will be a fixed fee paid for each transaction, where is equal to the price (in bitcoins) of a blockchain record.
If on the other hand Alice and Bob decide to use a lightning channel, they will incur an interest on the money that is locked into the channel, in addition to the fee paid when the channel is reset and recorded on the blockchain. We assume that this cost is covered by charging a fixed fee per lightningtransaction. The fee is calculated such that the expected fee charged during the entire channel lifetime equals the total cost of maintaining the channel.
Lemma 3.4.
Let be the blockchain mining fee and the daily interest rate for locking money in a lightning channel. Suppose the transfers between Alice and Bob are Poisson processes with means transfersperday respectively, with . Each transfer is of bitcoins, and they use a lightning channel with capacity bitcoins.
Then, to cover the maintenance costs of the channel, the fee per transaction should be:
[bitcoins/transaction] 
where is the expected channel lifetime (in days).
Proof.
The players pay interest on the quantity locked in the channel until the channel closes, i.e. for days in expectation. Since the interest is paid each day (rather than for each transaction), the cost due to the interest is:
The users incur an additional cost of at the end for recording the channel balance on the blockchain.
The expected number of transactions during the channel lifetime is , so the expected fee charged during the channel lifetime is . This fee should cover the costs, so we should have:
from which the claim follows. ∎
Lemma 3.5 (Firstorder approximation).
The firstorder approximation of the function
that gives the expected fee per transaction, taken around , is:
where is the expected channel lifetime and is independent of the interest rate .
Proof.
Let , where . Then
Since is independent of , the first derivative of is . Then the first order approximation of around is:
Substituting for in , we obtain
The error term for the estimation of
is given by a function with the property that , where is the maximum value taken by on the interval . We have thatThere are a few cases:

: is attained for , so we have that

: the maximum is , attained for .
Take .
Let be the error term in the approximation of . Then
∎
The cost of a transaction on the blockchain is , thus performing transactions on the lightning network is profitable for Alice and Bob as long as .
Lemma 3.6 (First order approximation of symmetric channel capacity).
Let be the blockchain mining fee and the daily interest rate for locking money in a lightning channel. Suppose the transfers between Alice and Bob are Poisson processes with means transfersperday, with . Each transfer is of bitcoins, and they use a lightning channel with capacity bitcoins.
Then, the first order approximation of the expected cost per transaction on the channel is . The optimal channel capacity based on this approximation is .
Proof.
From Lemma 3.5, the firstorder approximation of the lightningfee is:
For a symmetric channel, [days], so
as claimed. The error term is given by:
Minimizing the fee given the interest rate , blockchain fee , and mean number of daily transfers, is equivalent to minimizing the function
To find the optimal channel funding for a given , , , we must find the minimum of on the interval . As explained before, the firstorder approximation of is:
The optimal channel funding based on this approximation can be determined by taking the minimum of the function on the range . Note that
Thus is convex and the minimum is attained for with the property that , that is,
The lightning fee given the optimal funding is:
This completes the proof. ∎
4 Pairs Topology
In this section we assume that the network of transfers has a very simple topology: the users are divided to pairs who only trade with each other.
Our goal is to calculate the marketequilibrium blockchainfee . To this end, we have to calculate the demand for each value of , and find the value of in which the demand equals the supply (which we assume is constant, records per day).
4.1 Symbolic computations
We start by analyzing the demand of a single pair.
Lemma 4.1 (Choice of a single pair).
Let be the blockchain mining fee. Suppose the transfers between Alice and Bob are Poisson processes with means transfersperday respectively, with and and each transfer is of bitcoins.
Then there exist thresholds such that Alice and Bob:

do not transfer to each other when .

do all their transfers via lightning when .

do all their transfers via the blockchain when .
The threshold values depend on the transferrates. With symmetric transferrates, the thresholds are: , , and . (the thresholds for the asymmetric case are omitted).
Proof.
The users consider three options: (1) do not transfer at all, (2) transfer through the lightning channel between them, or (3) use direct blockchain transfers. They will choose the option with the lowest net utility. We assume that the users are quasilinear in money, so their net utility is the value of transfer minus the fee.
The net utility of doing no transfer is obviously 0.
If the value of a transfer from Alice to Bob is , then the net utility of doing a blockchain transfer is:
The net utility of a lightning transfer is minus the lightning fee calculated in the previous subsection, assuming optimal channel funding:
[symmetric case] 
The possible relations between the three net utilities, in the symmetric case, are given by:
The choice of the users depends on these parameters as follows. If , then the users choose notransfer. If , then the users use blockchain. If , then the users use their lightning channel. The claim follows from the above by straightforward arithmetic manipulations. ∎
It is noteworthy that all three thresholds are linear functions of the blockchainfee (this holds both in the symmetric and the asymmetric case). This is so even though the channellifetime is a nonlinear function of .
Note that we ignore the case in which two of the three utilities are exactly equal (e.g, or or ). This is because we are going to assume that the transfersize is drawn from a continuous distribution, so the probability of an exact equality is zero.
The previous lemma assumed that the transfersize is fixed. Now, we let be a random variable, and calculate the expected demand per pair. We calculate the demand function both with and without lightning.
Lemma 4.2 (Demand of a single pair).
Let be the blockchain mining fee. Suppose the transfers between Alice and Bob are Poisson processes with means transfersperday respectively, with and , and the transfersize is a random variable with probabilitydistributionfunction .
Then the expected demand of the pair [in recordsperday] is given by:
(without lightning)  
(with lightning, symmetric case) 
The transactions counts are:
and the transaction volumes are:
where are as defined in Lemma 4.1.
Proof.
By Lemma 4.1, when , the users use blockchain transfers. They do transfers per day, each of which uses a single record, so their demand is recordsperday. This explains the rightmost terms in all expressions.
When , the users use their lightning channel, so their demand is records each days, where is the channellifetime (in days) when it is funded optimally. So their daily demand is in the symmetric case. This explains the leftmost term, and completes the proof. ∎
Note that, in theory, the range of the integral in the lefthand side might be empty (if ). In this case, no users use lightning, and the value of this integral is zero. In practice, however, this option is very unlikely. In the Examples section below, we present some calculations with realistic numbers and show that usually .
Now we are ready to calculate the equilibrium blockchainfee.
Theorem 4.3 (Equilibrium blockchainfee).
Suppose there are users who only interact in pairs, so there are pairs of users. In every pair, all parameters () are the same, except for the transfersize , which is drawn randomly for each pair from probabilitydistribution . Then, the marketprice is a solution to the following equation:
where is given by one of the expressions in Lemma 4.2, depending on the case.
Proof.
Assuming all pairs have the same parameters, the expected aggregate demand is recordsperday. The supply is recordsperday. The marketequilibrium price is the price in which the demand equals the supply. ∎
4.2 Powerlaw distribution
We now present a special case of Lemma 4.2 for the case in which the transfersize is distributed according to the following powerlaw:
For simplicity we assume that , in accordance with the numeric data below.
Corollary 4.4.
When the transfersize has powerlaw distribution and , the expected demand of the pair [in recordsperday] is given by:
(without lightning)  
(with lightning, symmetric case) 
The transactions counts are:
and the expected transaction volumes are:
where are as defined in Lemma 4.1.
4.3 Numeric examples
For the examples, below, we assume the following parameter values.

Between each pair, there are transfers per day.

The transferrate is symmetric, i.e, each of Alice and Bob makes an average of 5 transfers per day.

, i.e, the utility of a user from a moneytransfer is of the transfersize.

The interest rate is per year. This implies that per day.

The size of a channelreset transaction is times the size of a usual transaction, i.e, [records].

The minimum transfersize is [bitcoins]:
These parameters give the following threshold values of (in the symmetric case):
So, without lightning, users use blockchain iff their transfersize is above ; with lightning, in the symmetric case:

Users whose transfersize is less than , do not transfer at all;

Users whose transfersize is between and use lightning;

Users whose transfersize is above , use direct blockchain transfers.
This has several interesting implications:

In a world with lightning, whenever is even slightly above zero (e.g. ) almost all users user lightning — the number of direct blockchain transfers is negligible.

Since , the demand function for the range of high (e.g. ) is dominated by the factor:
which is the demand without lightning. So, for this we expect the demand curves with and without lightning to be almost overlapping.
4.3.1 Demand curves
Substituting in Corollary 4.4, the demand functions are:
(without lightning)  
(with lightning, symmetric case) 
and the transactions counts are:
The demand curves for the above parameters are shown in Figure 1. As increases, we notice several interesting regions in the curves.

When is very low, all transfers above are profitable, so all demand curves start at (the maximum demand per day). In a world with lightning, a small increase in induces many users to prefer a lightning channel, so the demand for blockchain transfers declines quickly. In a world without lightning, initially the demand remains high since users have no alternative, but then starts to decline as becomes too high for blockchain transfers (Left).

Both curves continue to decline with the price. In a world with lightning, almost all decline in demand comes from a decline in direct blockchain transfers; the number of lightning transfers remains at its maximum () even with becomes quite high. But when becomes very high (), even the sparse channelresets become too expensive. The two demandcurves meet and the number of lightning transfers starts to decline too (Right).
4.3.2 Price curves
Based on the demand curves and Theorem 4.3, we calculate the marketequilibrium price as a function of — the number of agents. Note that the number of pairs is .
The price is 0 as long as the maximum demand is less than the fixed supply . When the maximum demand hits the supply, the price starts to increase and the demand decreases.
Without lightning, the equilibrium price is given by:
which leads to the following pricecurve:
Here, when the maximum demand hits the supply, the price jumps to (see Figure 2, top left); the discontinuity in the pricecurve comes from the discontinuity in the powerlaw distribution. The equilibrium price then increases linearly with to keep the demand and supply equal (see Figure 2, top right).
With lightning, in the symmetric case the equilibrium price is:
Here, when the maximum demand hits the supply, the price jumps to , which is in general much lower than (see Figure 2, top left); even a small priceincrease is sufficient to induce users to use lightning, thus reducing the demand for blockchain records. The priceincrease is initially superlinear (, but eventually reaches its critical point where even channelresets are too expensive (). At this point, the price starts to increase linearly with and the two pricecurves coincide (see Figure 2, top right).
The price with lightning network, hence also the miners’ revenue, is always below the price without lightning.
Below each pricecurve we show the total number of transactions in the market and how they split between lightning and the blockchain:

When the number of users is small. In a world without lightning, the number of transactions quickly attains its maximum of . In a world with lightning, while the number of blockchain transactions decreases, a small number of such transactions can support a much larger number of lightning transactions (Left).

When the number of users grows, almost all transactions are done in lightning (Right). Eventually, all transactions per day are used for reset transactions and the lightning network attains its maximum capacity, which is about — more than 2 million times the blockchain capacity.
5 Simulations
In the theoretic analysis we assumed that the transfersize is randomized once per pair of agents. We found out that the case in which the transfersize is randomized in each transfer is much more difficult to analyze theoretically. Therefore we study this case using simulations.
5.1 Channel operation and definitions
We consider a channel with a total capacity . Since the transferrate from Alice to Bob is the same as from Bob to Alice, we assume that the channel is initialized symmetrically  each agent contributes . The ”channel state” is the balance of Alice in the channel; therefore the initial state is .
Whenever a transfer has to be made, we determine its size by randomly drawing from the powerlaw distribution . Then, we check whether the transfer can be done in the current channel state (i.e, whether the agent making the transfer has a sufficiently high balance). If the transfer can be done in the channel, then it is done and the channel state is updated. Otherwise, we check whether it is worthwhile to do the transfer in the blockchain: if the transfer value is larger than the current , then the transfer is done on the blockchain; otherwise, it is not done at all.
In the initial state (), the chances of channel failure are relatively small; as the channel drifts away from this initial state towards one of its endpoints, the chances of channel failure increase. Therefore, at some states it may be worthwhile to do a channel reset and return the channel to its initial state. We assume that there is some constant such that, whenever the state after a channel transfer is smaller than or larger than , it is reset to . We call the reset radius.
5.2 Finding the optimal resetradius
The first step in analyzing the channel performance is finding the optimal reset radius. The plots in Figure 3/Left illustrate the channel performance as a function of the reset radius, for a capacity of .
Right: optimal reset radius as a function of the channel capacity.
The first plot shows the number of blockchain hits — the number of blockchain records required for a typical sequence of transfers (this is the sum of the records used for outofchannel transfers and the records used for reset transactions). The number of blockchain hits is minimized when the reset radius is about . The second plot shows the net utility of the agents, which is their value from making the transfers ( times the transfer sizes) minus the fee paid for blockchain hits. The utility is maximized at approximately the same point  0.5. The third plot shows how many transfers are done in the blockchain and how many are done in the channel, as a function of the reset radius.
We now calculate the optimal reset radius. Naturally, the optimum depends on the capacity and on the blockchain fee . For simplicity we calculate and plot the optimal reset radius only as a function of , for a fixed fee of . We make 50 experiments, each of which simulates transfers over 1000 days. Figure 3
/Right shows the average optimal radius, as well as a linear regression line; it shows that the optimal reset radius is approximately 5 percent of the channel capacity.
5.3 Finding the optimal channel capacity
From now on, we assume that each channel with capacity is operated with the optimal resetradius for this capacity, using the linear regression formula shown in Figure 3/Right. Our next goal is to calculate the optimal channel capacity, given the blockchain fee (and the fixed interest rate ).
Right: optimal channel capacity as a function of the blockchain fee.
Figure 4/Left shows some plots of the channel performance as a function of the channel capacity, for different blockchain fees. As increases, the blockchain cost (the cost from blockchain transfers and reset transactions) decreases, but the economic cost (the cost from interest) increases. The optimal utility is attained at a capacity in which these two costs are approximately equal.
We now calculate the optimal channel capacity as a function of the blockchain fee. We make 50 experiments, each of which simulates transfers over 1000 days. Figure 4/Right shows the average channel capacity, as well as a curve calculated by loglog regression; it shows that the optimal channel capacity is approximately a constant times . The theoretic analysis in Lemma 3.6 gives a constant times , which is qualitatively similar (recall that the situations are different since here we randomize the transfersize each transfer rather than once per pair).
5.4 Demand curves
From now on, we assume that each channel is funded with the optimal given the blockchain fee , and operated with the optimal resetradius given that .
We calculate the curve of demand for blockchain records in the following way. For each value of we calculate the number of records required to do the randomlydrawn transfers. This calculation is done in two steps: first, we calculate the total cost for doing all these transfers in a lightning channel (the blockchain cost plus the economic cost). We assume that this cost should be covered by putting a fee on each lightning transaction. The lightning fee is proportional to the transfer size, and the value of a transfer is also proportional to the transfer size. Therefore, if the total cost is smaller than the total value of all transfers, then all transfers will be done in the lightning channel. If the total cost is larger than the total value, then no transfers will be done in the lightning channel. In the latter case, the users will use only the blockchain, and they will do only the transfers with a value above the blockchain fee.
Figure 5/Top shows some plots of the daily demand for blockchain records (per pair of users) as a function of the blockchain fee. Loglog regression shows that the demand is with lightning is approximately and the demand without lightning is approximately . The theoretic analysis in Subsection 4.3 also gives a demand of in a world without lightning. The demand with lightning is , which is qualitatively similar to the simulation results.
Figure 5/Bottom shows the division of transactions between lightning and blockchain. Interestingly, while almost all transfers are done in lightning (Left), most transfervolume is done in the blockchain (Right).
Bottom: transactions with and without lightning. Left: transactioncounts. Compare to Figure 1 bottomright. Right: transaction volumes.
5.5 Equilibrium fee
Our next goal is to calculate the pricecurves — describing the equilibrium blockchain fee as a function of the number of users. Given the number of users , we estimate the equilibrium fee in the following way.

Draw a random sequence of transfersizes for 1000 days (an average of transfers).

Define the demand function as the number of blockchainhits when the above sequence is performed in a lightning channel with optimal capacity and optimal resetradius.

Define the surplus function as the difference between the demand and the supply per day, i.e: .

Find a for which (we used scipy.optimize.brentq, which uses a method by Brent (1973) to find a zero).
We executed the above procedure for 100 values of between and (logarithmically spaced). For each value, we repeated the random calculation 500 times. We calculated both the average for each (averaged over the 500 samples), and a regression curve of . The results are shown in Figure 6.
The blockchain fee grows superlinearly with the number of users. The data exhibits a very good fit with a polynomial of degree 2, which shows that the blockchain fee grows like , where is the number of users. In the theoretic calculation (Sub. 4.3.2), the price grows like , which is qualitatively similar.
Without lightning, the price grows linearly with , which is also similar to the theoretic results.
5.6 Overall network performance
Finally, we simulated the overall network performance as a function of the number of users. We simulated random transfers over 100,000 days, and 1000 values of between and (logarithmically spaced). For each value, we calculated the equilibrium fee with and without lightning, the number and the volume of transfers done in blockchain vs. lightning.
We did this experiment once for the current block size (a supply of 288000 records per day) and another time for a double block size (a supply of 576000 records per day). The results are shown in Figure 8.
The results are qualitatively similar with single or double block size. As the number of users grows, the equilibrium fee grows superlinearly (1st line) and with it, the miners’ revenue (5th line). However, the utility per user decreases (6th line). All the supply of records is used (2nd line). Almost all transfers are done in lightning (3rd line), but the volume of transfers is split approximately equally between lightning and blockchain (4th line), since the largest transfers are done in the blockchain.
Doubling the block size (with lightning) has some minor quantitative differences: the blockchain fee is smaller by a factor of about 3, the miners’ revenue is smaller by a factor of about 1.5, and the utility per user is higher by factor 1.5.
6 Star Topology
We now show how to solve networks where there is a central bank that each user is connected to. For each pair of , let denote the flow of player towards player . Then we can define and . Set and . Then , so the expected lifetime of the channel between user and the bank can be obtained as a corollary from the single channel analysis.
Corollary 6.1 (Lifetime of Channel between User and Bank).
Suppose there is a lightning star network, where the transfers from each user to any other user are given by a Poisson process with mean transfers per day, and the channel between user and the bank has capacity . Let and . Then, the expected lifetime of the channel between user and the bank from the state where user has bitcoins and the bank has bitcoins on the channel with user is:
(a) when :
[days] 
(b) when :
[days] 
Corollary 6.2.
The optimal initialization of a star network with channels of capacity is such that for each user

If , both the bank and user start with bitcoins. The expected lifetime of user ’s channel with the bank when initialized this way is .

If , user starts with bitcoins and the bank with bitcoins, while if . User starts with bitcoins and the bank with bitcoins. The approximate expected lifetime of user ’s channel is .
Next we calculate the optimal channel funding for the star topology, finding that the fee per transaction for any user in the star network is twice as high compared to the pairs topology.
Theorem 6.3.
Consider a star network with users connected through a bank, such that the transfer from any user to another user is a Poisson process with mean , with . Let be the blockchain mining fee and the daily interest rate for locking money in a lightning channel. Each transfer between any pair of users is of bitcoins, and each user has a channel with the bank of capacity bitcoins.
Then the expected cost of any transfer that a user is involved in is:
[bitcoins/transfer] 
where is the expected lifetime (in days) of a channel of capacity .
The expected fee paid by each user is twice as high in the star network compared with the model where user transacts only with a fixed user without a bank.
Proof.
This follows from the single channel analysis (Lemma 3.4), by noting that the expected (total) cost of a transaction that passes through user ’s channel with the bank is
Since the bank does not support any cost that user incurs, the fee for user is twice as high compared to the case where has transactions with only one other user (with no intermediary). ∎
The analysis from the pairs topology applies here too, except that the cost of using the lightning network for each user is multiplied by a factor of two.
7 Future Work
Instead of Poisson transfers, we can assume that there is a fixed sequence of transfers: , , where transfer number is from user to user . Each user has a fixed initial budget . The sequence is feasible, i.e, at time , user always has a sufficient amount of money for transferring to user . We assume that at time , user considers only two options: blockchain transfer or bitcoin transfer, and selects the cheaper option. There is an interesting algorithmic question: given a fixed sequence of transfers, what is the optimal configuration of lightning channels?
8 Acknowledgments
This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 740282), from the Israel Science Foundation (grant 616/13 and grant 1083/13) and from the HUJI Cyber Security Research Center in conjunction with the Israel National Cyber Bureau (grant 0399230). Erel was supported by the ISF grant 1083/13.
The symbolic calculations were done with Sympy [MSP17]. The plots were done using Desmos [des] and Matplotlib [Hun07].
References
 [CDE16] 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 Jeremy Clark, Sarah Meiklejohn, Peter Y.A. Ryan, Dan Wallach, Michael Brenner, and Kurt Rohloff, editors, Financial Cryptography and Data Security: FC 2016 International Workshops, BITCOIN, VOTING, and WAHC, Christ Church, Barbados, February 26, 2016, Revised Selected Papers, pages 106–125, Berlin, Heidelberg, 2016. Springer Berlin Heidelberg.
 [des] Desmos. http://www.desmos.com. Online; accessed Dec 2017.
 [DW15] Christian Decker and Roger Wattenhofer. A fast and scalable payment network with bitcoin duplex micropayment channels. In Proceedings of the 17th International Symposium on Stabilization, Safety, and Security of Distributed Systems  Volume 9212, pages 3–18, 2015.
 [HS] Mike Hearn and Jeremy Spilman. Bitcoin contracts. https://en.bitcoin.it/wiki/Contracts. Online; accessed Dec 2017.
 [Hun07] J. D. Hunter. Matplotlib: A 2d graphics environment. Computing In Science & Engineering, 9(3):90–95, 2007.
 [MSP17] Aaron Meurer, Christopher P. Smith, Mateusz Paprocki, Ondřej Čertík, Sergey B. Kirpichev, Matthew Rocklin, AMiT Kumar, Sergiu Ivanov, Jason K. Moore, Sartaj Singh, Thilina Rathnayake, Sean Vig, Brian E. Granger, Richard P. Muller, Francesco Bonazzi, Harsh Gupta, Shivam Vats, Fredrik Johansson, Fabian Pedregosa, Matthew J. Curry, Andy R. Terrel, Štěpán Roučka, Ashutosh Saboo, Isuru Fernando, Sumith Kulal, Robert Cimrman, and Anthony Scopatz. Sympy: symbolic computing in python. PeerJ Computer Science, 3:e103, January 2017.
 [NBF16] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.
 [PD16] J. Poon and T. Dryja. The bitcoin lightning network: Scalable offchain instant payments. 2016. Technical report.
Comments
There are no comments yet.