XLN: Extended Lightning Network
TL;DR LN is prepaid (full-reserve) only, XLN introduces credits and allows postpaid payments, mirroring traditional banking topology yet fixing their disadvantages.
Payment-channel-networks is a brilliant yet incorrectly understood concept that works perfectly for banking topologies.
XLN accepts it and intends to seamlessly & unobtrusively integrate into banking 1.0 upgrading it to banking 2.0: now with cryptographically guaranteed deposit insurance & undeniable signed proof of your balance at all times.
You can see it as a yet another feature added on top, like Atomic Multi Path payments or splicing — XLN doesn’t change the model of LN but simply adds new functionality that you may choose not to use.
XLN is a superset, and with specific configuration (all credit lines set to 0) functions exactly like original LN.
What is this functionality I’m offering exactly?
How BCH fails to see the real problem of LN
Let’s quickly reiterate over what BCH community constantly brings up as “flaws” of LN protocol and see that they can’t even manage to see the fatal flaw of original LN.
1. It will be hub&spoke like ordinary banking (aka “centralized”)
Yes, and that’s fine. LN doesn’t inherently require to have mesh network and simply offers a way for channels to be connected. No one ever said “LN is only LN when it’s a mesh”.
It’s true that Lightning Labs and co try to push the mesh narrative, but that’s just their wishful thinking. I have never signed up for their vision of a mesh network, and if you’re a technical person thinking about LN working mesh for a minute you will see it just doesn’t make sense.
Showing that LN can’t work mesh and only hub&spoke is like taking a candy from a kid. I believe no one of LN devs actually believes in mesh either, they just feel that hub&spoke are bad.
2. Since it’s hub&spoke, it’s centralized, therefore bad.
Lion share of crypto commentators have no clue what they are talking about. They are cargo-culting the word “decentralized”, and shame everything that looks “centralized”.
Layer 2 systems are exactly good for a reason that you don’t care about their centralization (number of servers that participate in routing). This problem is just out of equation. Channels are trustless and that’s the word you are looking for.
Layer 2 is trustless because you have balance proofs which you can enforce onchain and get your money back, guaranteed.
And this is all that matters for users and network security. As long as you can enforce your balances on the layer 1, you don’t care if it’s a mesh, hub&spoke, or just one giant Visa-like bank. It’s trustless.
3. Since it’s hub&spoke, it’s subject to KYC.
I have a separate article that covers just that:
In short: If you call the XLN banks money transmitters, then miners/validators are easily transmitters too. Just run a couple of thought experiments: e.g. Paypal can adopt blockchain-look-alike architecture with 4 validators in 4 datacenters and avoid all regulations? Anyone can start a Tether with unlimited blocksize and avoid all regulations?
That’s not a viable strategy long term, like selling designer drugs which might be legal right now but in essence they just try to bypass the wording of the law.
Instead, try to get real and consider anything that confirms transactions (miners/validators/lattice chains/plasmas etc) a transmitter, act accordingly and seek according licenses.
Expect a money transmitter test that will cover any entity that helps to confirm the transaction not just ones that fit into current transmitter definition.
4. Mesh routing can’t work
Nobody solved routing in mesh networks indeed. However, as we noted in #1 we are totally fine with hub&spoke so routing is a routine (pun intended).
The real problem: Receivability and Inward Capacity
Enough with BCH FUD, let’s figure out the real problem.
Here you can see two users with their onchain balances inside the circle.
Paying from onchain to onchain is expensive and incurs high tx fees — it’s only good for large $10k+ payments. So Alice deposits $4 capacity to a channel Alice@Merchant! (We don’t use open/close channel as it’s pretty much useless. All users have channels with all users by default with zero insurance (collateral), and all they do is deposit/withdraw insurance.
Now she can easily send $2.
This “vacuum” use case is the only thing that reliably works in original LN.
Pretty much all other types of payments fail due to lack of inward capacity.
There is no inward capacity for Merchant in this picture so under original LN terms absolutely no payment can happen from Alice to Merchant.
It might come as news to you because before you’ve seen inspiring LN explorers with gibberish of interconnected lines like this:
However, those lines simply don’t matter because this graph doesn’t show actual inward capacity for every node. Full disclosure: it’s non-existent.
Let’s call this new parameter receivability: an average % of funds that can be sent from any user to any another user.
This is a pretty good way to estimate overall usability of a payment network: if you cannot send money through the network what’s use in it?
Here we have a bunch of users with their balances $1, $2 or $3. However in this situation no one is able to make any payment and receivability is 0%.
Let’s assume the bank (even though it has no incentive) deposits some inward capacity for some users.
Let’s calculate receivability of every user:
Alice: 0% (no inward capacity)
Bob: can receive 1 which is 100% for Carol, John and Merchant, 50% of Dave and 33% of Alice’s funds. The total is 76%
Dave has same 76%
Carol and Merchant has 66%.
The total receivability of entire network is 0+0+76+76+66+66=47%
However, this is only for this state at this time. Once any payment is done and inward capacity is exhausted, you need to calculate it again.
So how would 100% receivabilitiy look like?
That thing in the middle is one giant jack pot must hold as much money as the entire volume. This is an obvious problem which was previously outlined in:
No receivability = no users
Would anyone use a payment network where they can only conditionally receive money and only conditionally pay? The answer is no.
Right now, if you try to install any original LN app you are pretty much guaranteed to end up with “No route/capacity found” error.
The whole thing is uncapable to route payments unless enthusiast fund specific routes (solely being enthusiasts not for some economic incentive).
XLN increases receivability with credit limits
The bank has no inward capacity for the receiving user, and has no incentive to provide insurance before hand and lock up their collateral. So what can he provide instead? A signed promise.
In XLN any user can extend the credit limit to another user, from 0 to Infinity. The credit limit defines how much more you can pay beyond the capacity.
The bank can send uninsured assets and any merchant would take uninsured money any day of the week over original LN’s “no payment can happen” situation.
99% secure (uninsured) money you can get is better than 100% secure (insured) you can’t receive.
Let’s say Bob sets credit hard_limit=10 soft_limit=5 (defines when the bank should rebalance). Alice sends $2 to Bob
Other than being uninsured (not protected by insurance onchain) those uninsured assets are just as good as insured ones. You can send them anyone else, even to unregistered users (Bob sends $1 to New User)
Each empty uninsured circle represents full insured circle that bank holds in another channel.
And once a while bank must do a rebalance (withdraws from channels with Alice, Carol and Merchant and deposits insurance to Bob):
With uninsured balances, the scalability of XLN is literally infinite!
Here’s a simple proof: everyone defines credit line = Infinity to their banks, which means all money can be sent to a single user with no inward capacity needed.
However, obviously we want some reasonable credit lines (soft=$100 hard $1k right now). But that’s another story.
The novelty of XLN
XLN shifts the capacity problem from being protocol/onchain-defined to user/trust-defined.
Your receivability as an XLN node does not depend on your inward capacity anymore, but on credit limit you open to the bank.
More than that, XLN allows billions of people from developing countries to use the network using solely uninsured balances, i.e. never touching the onchain layer. This opens up the blockchain security to people who can’t afford a single onchain tx (50% of Earth population lives on $2/day).
Our goal is to find proper tradeoff between Total Avg Uninsured Balances and Avg Receivability.
XLN is strictly superior to original LN because it can function as LN (set all credit lines to 0), while LN cannot function as XLN.
Some people find similarities to fractional reserve banking but first of all uninsured money is complementary to insured part and will barely exceed 1% of your total funds. Also, uninsured balances are enforceable onchain, which is very different from a trusted balance.
Fairlayer is the first XLN implementation: https://github.com/fairlayer/fair
