[Lightning-dev] Superbolt Proposal - a professionally run LN subset delivering superior UX
robertwilliamallen at gmail.com
Tue Mar 3 01:19:18 UTC 2020
Currently, the LN user experience is far from retail ready.
Inbound/outbound channel liquidity issues and node dropouts mean that many
payment attempts will not succeed.
I have spent some time thinking through these issues and believe a BOLT
specification which would enforce a stricter set of rules for nodes to
follow and which would ensure sufficient liquidity, uptime and channel
rebalancing automation would move the needle greatly in the direction of a
UX which could go mainstream. If LN is currently resulting in many “gutter
balls,” Superbolt would be like bowling with bumpers. This BOLT would be
optional for LN nodes to use or not depending on whether they wish to
participate in the Superbolt network directly.
In Christian Decker’s talk
at The Lightning Conference (Berlin, October 2019) he presented some
frustrating statistics from a study he conducted to test payment routing
success/failure on Lightning Network (LN) using payment probes. Some of the
48% of payment probes failed to find a payment path to the targeted
node. This is likely because either the node itself was offline or a
connecting node along the path was offline.
Ignoring the 48% of unreachable nodes, payment success rate is 66% on
the first payment attempt. With multiple retries for the payment, success
rates reach about 80%. This means that even for nodes which are available
and reachable, 20% of payments are not able to complete. This is not good.
Stuck payments (initiated but not completed) because a node died along
the path occurred at approximately 0.19%.
It should go without saying that a payment network which works less than
50% of the time presents a user experience which will never catch on with
the vast majority of the total addressable market. If you are flipping a
coin every time you attempt to use a payment method, you will quickly
abandon this method for one which works reliably.
To make matters worse, I believe Christian was attempting to route
micropayments for his testing of the network, so the above numbers may
actually be optimistic when you factor in attempting to route larger
payments (even just a few hundred dollars worth of BTC). For example, a
route may be found for the desired payment but if there is insufficient
liquidity on one of those hops (either due to insufficient channel capacity
or because of inbound/outbound liquidity issues), then the payment will
In summary, there are two fundamental problems with LN as it is currently
Connectivity: Node uptime and connectivity to the broader network are
both insufficient to guarantee payment success.
Throughput: Node channel capacity is frequently insufficient due to low
total capacity and/or inbound/outbound liquidity snags.
I am proposing an LN BOLT, called Superbolt Network (SBN). Conceptually,
this might be analogous to an “electrical grid” for LN. SBN would enforce
and/or automate the following:
Liquidity: Distinct and uniform LN node classes with commensurate total
node and per channel liquidity requirements. To begin, two node classes are
Routing Node (RN) - 4 BTC total node capacity, 4 x 1 BTC channels
(0.5 BTC per side) to other RNs, 8 x 0.5 BTC (0.25 BTC per side) channels
to ANs. 3 of 4 RN connections should be with shared peers (i.e.
A => B => C
=> A) while the 4th connection should be with an RN without
shared peers to
ensure the network is sufficiently connected.
Access Node (AN) - 1 BTC total node capacity, 2 x 0.5 BTC channels
(0.25 BTC per side) to RNs. 10 x 0.1 BTC channels (0.05 BTC per side) to
regular LN wallets/individual users/etc. RNs should be peers to allow off
chain rebalancing via circular payments.
Please note: Additional node classes (larger or smaller) may be
beneficial to network performance. However, to maintain sufficient
decentralization, it may be beneficial to have a maximum node
Uptime: Nodes would be required to maintain uptime to the network of at
least 99% availability. Nodes which fall below this requirement for a
determined period of time would be ostracised by the rest of the network
and perhaps eventually excised completely from SBN. I believe we could use
chanfitness <https://github.com/lightningnetwork/lnd/pull/3332> from lnd
and add some logic to check for fitness and then some scripting to
automatically route around bad nodes.
Channel balancing: To ensure that channels do not become stuck from
inbound/outbound liquidity snags, the protocol would include some scripting
to automate channel rebalancing via “circular payments” and Loop.
Attestation: Any LN node which claims to meet the requirements to be
included in SBN would be rated by a randomized subset of the SBN network
and the inquiring node would receive cryptographically signed attestation
that the node is either valid or invalid.
Uniform fee: Payments sent on the network would be subject to a flat fee
regardless of hops involved in routing the payment.
Given the above, anyone using SBN/LN/BTC would have a close to 100%
guarantee that their payment would be successfully routed from any given
SBN Access Node to any other SBN Access Node up to a reasonable
network-defined maximum (perhaps 0.025 BTC ~= $215 with BTC at $8600). We
can be confident of this because:
Channel capacity is sufficient such that any one payment is an order of
magnitude smaller than the nearest chokepoint (0.25 BTC outbound from AN to
RN while maximum payment would be 0.025 BTC). I haven’t done the hard math
on this, but my intuition tells me that the probability of all participants
connected to any given AN attempting to route payments from said AN at the
same time would approach 0%.
In the event that an AN or RN node channel capacity becomes unbalanced
(i.e. Node A = 0 BTC, Node B = 1 BTC in given channel), Channels should
frequently be able to use circular payments
<https://github.com/lightningnetwork/lnd/pull/3736> to unstick capacity
given that nodes are sufficiently connected with common piers. In the event
that off-chain rebalancing is impossible, Loop
<https://github.com/lightninglabs/loop> may be used. Ideally, both
approaches would be automated such that rebalancing occurs if node
liquidity is stuck in either direction beyond some threshold (say <25% of
total channel capacity).
Nodes are incentivized to stay online ready to route payments and
ostracized for insufficient uptime.
The user experience I envision with this protocol would be one where a user
would go to pay with Lightning and look for the Superbolt logo and know
with near certainty that they will be able to make the payment. This is the
experience today with processors like Visa and Mastercard and it seems
unlikely that LN will achieve similar levels of reliability unless some
additional requirements such as those proposed here are added to the LN/BTC
I would very much appreciate input on this idea.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lightning-dev