Egor Homakov on Twitter

FYI, any custodial @lightning wallet == Extended Lightning (as described in https://t.co/o53EvbsC5T). The server receives insured assets on input and promises custodial/uninsured assets to the destination user. Interesting how LN naturally adopts XLN without admitting to it :D https://t.co/H0wzXIu9ay

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

Egor Homakov on Twitter

Centralized != trusted. Decentralized != trustless.

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:

Why Miners/Validators Are Money Transmitters Too

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:

Why Lightning and Raiden Networks Will Not Work

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

XLN: Extended Lightning Network was originally published in Xlnomy on Medium, where people are continuing the conversation by highlighting and responding to this story.

I wrote this short memo specifically to demonstrate why LN is an ephemeral concept not applicable to reality.

I learnt about LN back in 2015 from Jonathan Wilkins, CSO of Blockstream, but like everyone else didn’t pay any attention to it because there were no scalability problem.

The abstracted idea, detached from reality, is great — everyone has a channel with someone else, everything is trustless, you can do onion routing and multi-hop payments to anyone else. Sounds too good to be true, right?

I can only recall these posts with critics of LN by Jonald:

• Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution
• Continued Discussion on why Lightning Network Cannot Scale

He points to a problem that mesh-network between individuals is unlikely because the system gravitates to centralization.

He is damn right. But he missed the obvious: even being centralized LN will simply not work due to broken (or, rather, non-existent) incentive model.

Some people do 10 million node simulation to “prove” him wrong — which has nothing to do with real economy, that’s why it’s called a “simulation”.

On a positive side, LN is not “vaporware” as many bcash fans call it — it’s a very real project. There’s massive work being done on lnd (which I follow closely) and I’m sure in 3–6 months there will be a fully-fledged production-ready daemon.

The codebase, the team, the spirit , even the name ⚡— all of them are superb.

It’s just the design that’s broken.

Here is the question:

LN is production-ready. Now what?

How will the network grow from day one? Let’s assume all wallets (client and server side) add payment channel functionality, so I can open a channel to anyone else.

Who I’d like to open a channel to? Given $30 fees, I will probably think hard before doing that… coffeeshop I’m using twice a month? Bob who I split bills with once a year? let me think… a hub!

Hubs have connections to other users, that’s what “hub” means.

Where do hubs come from? Let’s say there’s a respectable team FirstHub that wants to become a LN hub. Ok, here we go, Alice opens a channel to FirstHub. She wants to pay Bob.

She sends a $10 commitment tx (LN terminology) or balance proof (Raiden terminology) to the hub.

How the hub pays to Bob? An on-chain channel to Bob is a pre-requisite to routing any payment.

Why would the hub open a channel to Bob? $30 to open a channel to random dude?

Should Bob go through KYC or fund a channel himself with FirstHub? So Bob puts $30 in channel and hub what, $300?

What if Bob doesn’t own any coins and is first time user?

What if Bob is malicious and runs sybil attack to destroy hub’s liquidity so hub has no money to open new channels?

Where does FirstHub get this kind of liquidity to start with?

They are just programmers who run the software. They have just a few Bitcoins. But they need as much money as they have volume. Paypal’s volume is $100B.

Who wants to give 100 BTC to FirstHub team running a freshly baked lnd daemon? What ROI? For ridiculous “sub-satoshi” off-chain fees? Nope, thanks, I’d rather HODL than lose my money being a “liquidity provider” for your questionable operation.

What if there’s a channel to Bob, but the capacity is not enough to route $10? Risk FirstHub’s money and open a new channel?

What if Bob transfers $100 to Bob2, then Bob2 to Bob3 and so on, how should the hub go about it?

Open a ton of channels to Sybils, check their identity or ask them to bring just as much money as they want to receive so they would not have a leverage in attacking hub’s liquidity?

How did we end up developing a technology that does not have a reasonable incentive model?

So it will not work?

Yep. When it will be released, no one will give a shit. A few enthusiasts will install it, play around in testnet, run “simulations” but that’s about it.

Maaaybe some exchanges will have channels between each other in some way, but that has nothing to do with LN (mesh network of channels), that’s just channels that existed long before that.

As a user, you will have no reason to open a channel to anybody, no one will have an incentive to open a channel to you, and no one will have an incentive to run a hub to join you guys together. Stale mate.

Don’t trust me? Fine. Wait 3–6 months and see it yourself.

Speaking of Raiden, it has much lower chances.

1. Obviously, no one is going to transact in shittokens. People need liquid asset such as ether. So first things first, there would have to be a tokenized ether. Not a deal breaker, but would save quite some gas and code complexity if they started with pure ether instead of all kinds of CoffeeTokens. Solidity is pain to write in, so any simplification is a huge win.
2. uRaiden is a gimmick — no one ever needed many-to-one unidirectional network. Paying per megabyte of Internet? Come on! It’s all about many-to-many bidirectional channels.
3. Very strange Solidity patterns. Each channel requires a new contract to be deployed, while it’s not that hard to engineer the entire network (mapping many => many) running inside one contract. No benefits on the security side either — having 10000000 contracts vs 1 doesn’t make the system more secure, as all of them could be vulnerable to exact same bug.

But is there hope?

LN/Raiden incentive model is hopelessly broken, but it’s not a game over. The fix is ridiculously simple.

Introducing Failsafe Network

The hub can give a signed promise to Bob (positive delta +10) for every commitment they receive from Alice (negative delta -10). Alice can settle whenever she wants (normally when positive delta is reaching 100x of current onchain fee, eg $1,000). A positive delta is not exactly custodian balance, as it’s possible to enforce the hub to pay you onchain as long as the hub is solvent.

Sure, you don’t have 100% security for 100% of your money, there’s a trade-off to be made.

But it’s a lot more important to keep first layer lightweight and bandwidth requirements as low as possible than going full Bitcoin Cash like newer blockchains promoting “100,000” tps do.

Those who sacrifice first layer aren’t real blockchains but scammers who edited a single line of code that limits blocksize.

In Fairlayer you get 100% security for 99% of your money (collateral) and 99% security for the other 1% (money in-motion, positive deltas). As long as sum of all deltas stored by a hub is <0 (more money owned in negative deltas than promised in positive deltas), the hub is solvent.

Once it gets insolvent, it will be apparent fairly quickly as it stops settling collateral on time, and people would migrate to other hubs.

Coming to you this January.

Why Lightning and Raiden Networks Will Not Work was originally published in Xlnomy on Medium, where people are continuing the conversation by highlighting and responding to this story.