{
"cells": [
{
"cell_type": "markdown",
"id": "c4d91e15-9174-4aaa-90c5-ee4466038c34",
"metadata": {},
"source": [
"**WARNING: This work is currently under review. It's claims should be taken with caution. It is only available for interested folks to provide feedback (which is very wellcome!)**\n",
"\n",
"## Abstract\n",
"\n",
"It has been observed that [payments on the Lightning Network fail too often even if several attempts for the delivery of a payment are made](https://youtu.be/zk7hcJDQH-I?si=2k2pRtS5nAKaP92d). Most people believe that depletion of liquidity in channels is a challenge for payment delivery and route discovery. While [depletion can be explained through drain which can be mitigated through various control valves](https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/) there is [research in this repository showing that payment failure rates are expected to happen due to the statistical min cut distribution of all pairs of peers in the network](https://github.com/renepickhardt/Lightning-Network-Limitations/blob/main/likelihood-of-payment-possability/An%20upper%20Bound%20for%20the%20Probability%20to%20be%20able%20to%20successfully%20conduct%20a%20Payment%20on%20the%20Lightning%20Network.ipynb) on the liquidity graph. That observation is independent of the drain in channels and the uncertainty about the liquidity that is part of the protocol.\n",
"\n",
"This notebooks explains how the $2$-party channel design seems to be the main reason for the limited abilities to successfully facilitate payments at a service level objective that is close to $100\\%$. \n",
"\n",
"We introduce a [geometric model](https://en.wikipedia.org/wiki/Algorithmic_Geometry) to study the impact of payment channels to the number of possible wealth distributions of Bitcoins between the users of the Lightning Network. This particular question is interesting because any payment between two peers can be considered as a change in the wealth distribution of the peers. Consequently, the more wealth distributions are possible in a fixed Lighting Network Topology the more payments can be facilitated. The problem of counting how many payments are possible in a given network topology is related to the computationally hard problem of [Counting Integer Flows in Networks](https://arxiv.org/abs/math/0303228). Thus we show that the number of possible wealth distributions can be described by the volume of a [convex polytope](https://en.wikipedia.org/wiki/Convex_polytope) that is defined by the Lightning Network's channel graph. While exact [computation of such volumes](https://en.wikipedia.org/wiki/Convex_volume_approximation) is also computationally challenging it is known that the volumes can be estimated well through [Monte Carlo Simulation](https://en.wikipedia.org/wiki/Monte_Carlo_method). \n",
"\n",
"Besides the $2$-party channel design we show that the low densitiy of the network and the inequality of channel capacities reduces the ability of the network to facilitate payments. However the evidence demonstrated in this notebook suggests that the biggest limitation by far seems to be the two party channel design that is currently being deployed on the network. \n",
"\n",
"We give empirical evidence that the deployment of multiparty channels could allow for service level obejectives close to $100\\%$ even if the network consists of less than $1$ multiparty channel per peer. Under the assumptions that multi party channels don't produce significantly more on chain footprint as the current channels this result would imply that off chain (multiparty) payment channel network could be supported with the given on chain bandwidth and be able to facilitate almost all payments without the necessity to conduct additional on chain transactions for liquidity management and realocation. \n",
"\n",
"In particular we show empirically that when extending the $2$-party channels of a current snapshot of the lighting network to $120$-party channel by randomly adding peers we observe that $100\\%$ of our sampled wealth distributions were feasible in the multi party channel network where $\\0\\%$ of our sampled wealth distributions were feasible in the $2$-party channel design \n",
"\n",
"### Summary of our contributions in this notebook:\n",
"\n",
"* A [Geometric model](https://en.wikipedia.org/wiki/Algorithmic_Geometry) based on convex polytopes to describe the space of wealth solutions that is given by channel graph\n",
"* A [Monte Carlo](https://en.wikipedia.org/wiki/Monte_Carlo_method) based simulation to [estimate the volume of the convex polytopes](https://en.wikipedia.org/wiki/Convex_volume_approximation).\n",
"* An investigation how the topology of the network impacts the number of possible wealth distributions.\n",
"* An argument how the inquality of channel capacities reduces the number of possible wealth distributions\n",
"* A demonstration of how multi party channels allow for more wealth distributions and (potentially) less on chain transactions than the currently deployed 2 party channels.\n",
"* Relation between expected payment failure rates and an inverse power of the number of members in the channel. This is achieved by random walks on the polytope describing the network\n",
"\n",
"\n",
"### Acknowledgements: \n",
"\n",
"Thanks to Stefan Richter, [Christian Kümmerle](https://cci.charlotte.edu/directory/christian-kuemmerle/) and Eduardo Quintana for helpful discussions, insights and feedback while this work was being created. The work is sponsored through a [grant from OpenSats](https://opensats.org/blog/rene-pickhardt-receives-lts-grant) and through [individual patreons](https://www.patreon.com/renepickhardt)."
]
},
{
"cell_type": "code",
"execution_count": 6,
"id": "82c8c7d8-1e9d-482c-a393-4fac2c24c58f",
"metadata": {},
"outputs": [],
"source": [
"#some libraries that are necessary\n",
"from drs import drs\n",
"import numpy as np\n",
"from math import comb\n",
"import random\n",
"from networkx.readwrite import json_graph\n",
"import json\n",
"import matplotlib.pyplot as plt\n",
"import plotly.express as px\n",
"import scipy\n",
"from scipy.stats import zipf"
]
},
{
"cell_type": "markdown",
"id": "01554443-0fc9-4632-8dea-11a63d6edad2",
"metadata": {},
"source": [
"## Modeling Wealth Distributions on the Bitcoin Network as a convex polytope\n",
"\n",
"Let $w_1,\\dots,w_n$ be the wealth of $n$ users, i.e. the number of coins each user owns. Given a fixed number $C$ of coins in circulation the possible wealth distributions may be described by a convex polytope. This is given as the intersection of the hyperplane derrived from the set of zeros of the equation $w_1 + \\dots w_n = C$ with the [half spaces](https://en.wikipedia.org/wiki/Half-space_(geometry)) $w_i \\geq 0$.\n",
"\n",
"* The linear hyperplane $\\{\\vec{w} \\in \\mathbb{Z}^n|w_1 + \\dots + w_n - C = 0\\}$ describes the fact that all coins must be distributed among all users.\n",
"* The $n$ convex half spaces $\\{\\vec{w} \\in \\mathbb{Z}^n | w_i \\geq 0\\}_i$ describe the fact that none of the users may have negative wealth.\n",
"\n",
"In particular it is trivial to see that by construction that the described geometric object is both **convex** and **bounded** which is why - in accordance to the literature we omit this two words but mean them when we speak of (convex) polytopes. \n",
"\n",
"\n",
"***Disclaimer: While low dimensional observations in Geometry may not directly translate to higher dimensions we still use the first part of this notebook to introduce low dimensional examples to give some intuition about this new model of the Lighting Network*** \n",
"\n",
"We start by looking at a low dimensional example of $3$ users that own in total $12$ coins.\n"
]
},
{
"cell_type": "code",
"execution_count": 2,
"id": "c6544a9e-ea63-4b1f-8b0a-87c5bd64252e",
"metadata": {},
"outputs": [
{
"data": {
"text/html": [
" \n",
" "
]
},
"metadata": {},
"output_type": "display_data"
},
{
"data": {
"application/vnd.plotly.v1+json": {
"config": {
"plotlyServerURL": "https://plot.ly"
},
"data": [
{
"hovertemplate": "x=%{x}
y=%{y}
z=%{z}