Skip to content

Instantly share code, notes, and snippets.

@sebulino
Created September 22, 2022 12:32
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sebulino/dc00ad4914830c4f61dea75c0988bed2 to your computer and use it in GitHub Desktop.
Save sebulino/dc00ad4914830c4f61dea75c0988bed2 to your computer and use it in GitHub Desktop.
Einleitung
# Motivation
The Lightning Network is a decentralized system where transactions are sent over a network of micropayment channels (Poon, Dryja). It is based on the Bitcoin blockchain where the consensus of the balances of bitcoins in wallets is agreed upon. Given its character the Bitcoin blockchain cannot register an equally high number of transactions per seconds, as would a current payment network. Being able to serve a higher transaction volume would only be possible with more centralization. But for Bitcoin to succeed it needs to maintain its current advantages of decentralization.
Using a network of micropayment channels that is linked to the bitcoin blockchain is a way to scale to billions of transactions per day.
However, to be used as such a payment network it needs to fulfill ist promise to reliably send transactions over its network of micropayment channels. It needs a minimum degree of reliability to acquire enough acceptance so that it can present itself as a viable alternative to current transaction networks and electronic payment systems.
Reliability refers to a high degree of confidence that payments between two counterparts don’t fail.
Unfortunately this is currently not the case. The lightning network currently cannot provide the reliability needed, so that it could be regarded as an alternative to centralized payment networks. Given its young age of six years, this is not surprising. Current estimates range between ≈≈≈≈≈ of payments failing.
Unreliability originate in nodes not being able to send or receive payments. The main reasons for this are nodes not being reachable and channels not being able to forward the expected amount.
The availability of nodes is more an operational problem, but providing enough liquidity to deliver a payment is generally a question of distribution of channel balances, which can be dealt with on a protocol level and on an implementation level of a lightning node.
When a payment is sent from sender/source to receiver/sink the sending node chooses the path. The path describes the flow of the payment through the graph of Lightning nodes for the respective payment. Which flow is chosen is determined by criteria implemented in the lightning node software. Several strategies exist for path selection.
Each payment changes the state of channels in the lightning network. Thus each payment changes the balances in channels and thus has the chance to deplete channels, making them unavailable for a future payment flow between the two nodes. In consequence, the path selection decision impacts the state of the lightning network and its reliability.
The path for the payment from sender to receiver is chosen by the node, according to the preferences implemented in the node software. These preferences are for example to minimize cost or minimize the payment failure probability. They are at the discretion of the sending node and generally don’t follow the payment networks best interest. The sender optimizes the choice of the payment flow exclusively to its own interest. That self-interested users might route traffic through congested networks is referred to as selfish routing.
Optimizing along personal preference is generally detrimental for the network as a whole, because using the cheapest path promotes channel drain, which will in return lead to unusable channels and a cut in the network more frequently.
Assuming other strategies exist, they might avoid such network deficiency and generally create a higher welfare for the network, because less channels are depleted and the network is usable more broadly.
The existence of these strategies could allow for calculating a cost of selfish-routing. If a quantitive measure for the inefficiency can be derived, this is referred to as the Price of Anarchy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment