[Lightning-dev] Superbolt Proposal - a professionally run LN subset delivering superior UX

Robert Allen robertwilliamallen at gmail.com
Tue Mar 3 01:19:18 UTC 2020


Superbolt Proposal

*Introduction*

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.

*The Problem*

In Christian Decker’s talk
<https://www.youtube.com/watch?time_continue=1&v=HtU7ZlxvLL4&feature=emb_logo>
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
salient points:


   1.

   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.
   2.

   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.
   3.

   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
fail.

In summary, there are two fundamental problems with LN as it is currently
functioning:

   1.

   Connectivity: Node uptime and connectivity to the broader network are
   both insufficient to guarantee payment success.
   2.

   Throughput: Node channel capacity is frequently insufficient due to low
   total capacity and/or inbound/outbound liquidity snags.


*Proposal*

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:


   1.

   Liquidity: Distinct and uniform LN node classes with commensurate total
   node and per channel liquidity requirements. To begin, two node classes are
   proposed.
   1.

      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.
      2.

      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.
      3.

      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
      capitalization limit.
      2.

   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
   v0.9.0-beta
   <https://blog.lightning.engineering/announcement/2020/01/22/lnd-v0.9.html>
   and add some logic to check for fitness and then some scripting to
   automatically route around bad nodes.
   3.

   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.
   4.

   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.
   5.

   Uniform fee: Payments sent on the network would be subject to a flat fee
   regardless of hops involved in routing the payment.


*Why?*

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:


   1.

   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%.
   2.

   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).
   3.

   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
stack.


I would very much appreciate input on this idea.

-- 
Best,

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200302/22a74f46/attachment-0001.html>


More information about the Lightning-dev mailing list