Now, when transaction fees for btc are constantly in $30 area pretty much every thread about scalability ends up with mentioning LN or eth’s Raiden (which recently raised $33M by selling a token the network never needed).
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
Have you heard of the Bitcoin Lightning Network? It is a proposal that claims that:
Continued Discussion on why Lightning Network Cannot Scale
I’d like to thank everyone in the Bitcoin community that took the time to read an article I published this week called…
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.
- 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.
- 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.
- 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
A fail-safe in engineering is a design feature or practice that in the event of a specific type of failure, inherently…
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.