>> (p.1)
    Author Topic: My conclusions about the Lightning Network and a request for critique by smarter  (Read 464 times)
    noamlevenson (OP)
    Newbie
    *
    Offline Offline

    Activity: 3
    Merit: 8


    View Profile
    April 23, 2019, 10:56:27 AM
    Merited by bones261 (3), aliashraf (3), LoyceV (1), ABCbits (1)
     #1

    I am writing an in-depth article about the Lightning Network. I want it to be comprehensive and balanced, educating people on the state of LN, how it works, as well as on current internal debates over its directions and concerns.

    I generally publish on Medium (@noamlevenson).

    Currently, I’ve read everything I could on the LN, including criticisms and responses to those criticisms and so on. Before I publish my article, I want to post my conclusions here for anyone to present any counter-arguments. Please do so.

    1. The first challenge that I see forming in regards to the LN is the difficulty in maintaining a network “map.” Nodes need a topology in order to route transactions. Problems with this are both the eventual enormous size of the topology and the number of messages that would need to be sent in order to determine the topology. I see two solutions: one, we only use the network for microtransactions and those transactions with few “hops.” Or two, we rely on centralized hubs that maintain the network for us.
    * 1.a. However, I also recognize that we might not need to find the most optimal route - “good enough” might work. But can we achieve good enough without relying on centralized hubs? 

    * 1.b. How do LN wallets today manage to route messages? Do they maintain a network map? What is the anticipated consequence of a network with millions of users? 

    * 1.c. Additionally, what happens if, when using onion routing, an offline node is encountered? Doesn’t the end destination need to be revealed if a new path is to be determined? In other words, won't the onion encryption need to unwrapped?


    2. Obviously the hub and spoke model of the network comes under a lot of attack. I do think that to some degree this is an eventual reality of the network. I don’t think this would be the end-all of the LN if it does occur. However, it introduces the following risks:
    * 2.a. Rising costs of BTC onchain transactions give hubs more power over individuals. This is especially relevant to any transactions that fall under the “dust” level of BTC (i.e. the cost of onchain transactions). If a transaction falls under this metric, time lock hashes cannot be used and the transaction ceases to be “trustless.” At this point, hubs could refuse to route funds (after the funds were locked), unless certain criteria were met (holding the funds hostage). If the user didn’t consent, they could withdraw their funds, but the user would lose all the money in the onchain transaction (because the whole sum would be "dust" and would go to paying the miner). Additionally, it could be very costly to execute an onchain transaction to open up a channel with a different hub, preventing people from switching to another hub if the hub proved untrustworthy.
        * Splicing is nice for other things, but I don’t think splicing would solve this issue at all. 


    3. Fractional-teller-banking presents a serious problem, again highlighting why an unscalable layer 1 will impact layer 2 solutions. If everyone on the LN wants to withdraw their funds (a “run”), the BTC onchain validators would be overwhelmed. Now, this isn’t a huge issue as eventually, the network will process through the waiting transactions. However, if users try to push old “states” from channels onto the main chain to steal from users, then a problem results. Because of the network lag, the counterparty might fail to push a “breach remedy transaction” (i.e. a transaction invalidating the “old” state and preventing the fraud.). But because these remedy transactions must be submitted in a timely manner, a backlogged BTC core layer could prevent the transaction from being processed in time and lead to the success of the fraudulent party.

    My conclusion: Ultimately, the LN as a layer 2 solution relies on layer 1: i.e. the BTC core protocol. I think that there is a place for the LN, but it doesn’t remove the necessity of scaling BTC’s layer 1 and ensuring that fees stay reasonable. The LN has solid use cases, but not nearly as many as people think. And ultimately, it is certainly not a solution to a crippled BTC network — but only, in the best case scenario, a complimentary service for niche use cases.
    I don't see the LN ever being the global payment network that some people envision.

    Looking forward to your responses!
Page 1
Viewing Page: 1