Scaling LN-What coming in 1.1 release of the LN ?

Lightning Network or LN for short is a second layer solution which many bitcoiners say is the holy grail to Bitcoin scaling woes. In order to keep bitcoin decentralized, keep the base layer nice and lean and move tx offchain.

Now this article won't be talking about what the LN is-this articles assumes you know what LN is already.

However here is a good article to understand LN:

https://99bitcoins.com/bitcoin-lightning-network/

Anyway let begin to talk about the title shall we :)

So the LN alone is just a bunch of protocols that make up one network. Now you might of seen some articles talking about how even with the LN the block size needs to be somewhere between 20-140 MB right? That is assuming the main part of the LN which is opening channels and closing them which require onchain.

However the needs of onchain txs can be lessened majorly.

These updates aims to do just do or open up some part of the LN now that the network is more mature and some privacy features :P

• Multi-path payments: the current normal way to make a payment over LN is using a single path. Alice pays Charlie through her channel to Bob and Bob’s channel to Charlie. This works well for small payments where each participant has enough capacity to support the payment. But if we use this mechanism when Alice has 10 open channels each containing a maximum of 10% of her total hot wallet balance, Alice can only spend at most 10% of her funds at a time.

  Multipath payments provide a solution to this problem: if Alice wants to send 15% of her funds, she can send 7.5% to Charlie through her channel with Bob and 7.5% through her channel with Dan (who also has a channel with Charlie). Although the partial payments are routed through separate paths, they can each commit to the same hash Alice would’ve used to send a single-path payment. If Charlie receives multiple payments within a reasonable time period that equal or exceed the expected amount, he can guarantee that he’ll receive all of them by simply revealing the single preimage used by all of the hashes. This reuses the same proven security mechanism currently used for single-path payments and so doesn’t introduce any new security assumptions. The same mechanism also works if some other party along the path with sufficient channel capacity merges together the partial payments and forwards a single payment along the remainder of the path to Charlie.

  For more information, see the following Lightning-Dev threads which often call this feature Atomic Multi-path Payments (AMP): an early proposal with separate hashes/preimages, something like the currently favored proposal, a possibly too optimistic proposal.

• Dual-funded channels: a nice feature of the current implementation is that only one party to the channel needs to initially commit any funds to it. For example, Alice opens a channel to Bob with 0.1 BTC of her money and none of Bob’s money. This makes it very easy for users to accept new incoming channels, but it also means that channels can only be used in one direction initially—Alice can pay Bob or route payments through Bob, but Alice can’t receive payments from Bob or from any routing path including Bob until Alice has sent Bob some money. This creates a bootstrapping problem: if Alice wants to receive payments via LN, she has to get people to open new channels to her node—which requires they pay onchain transaction fees and wait for onchain confirmations that can take hours.

  A proposed solution to this problem is to allow dual-funded channels. Alice agrees to put 0.1 BTC into a channel with Bob if Bob agrees to open the channel with 0.1 BTC of his own funds. This can cost Bob money—namely onchain transaction fees and the opportunity cost of having his funds committed for some time—but Bob also receives the opportunity to earn LN routing fees for any payments sent to Alice.

  The basic implementation of dual-funding is probably simple (LN nodes already handle bidirectional payments) but creating an incentive mechanism that can reward capital providers like Bob is still being discussed. For more information, see the following threads: 1, 2, 3. Also see the section on advertising node liquidity in Newsletter #21.

• Splicing: you can’t currently increase a channel’s maximum balance or send some of the channel’s funds onchain to another person without closing the whole channel and opening another between the same parties. Closing one channel and opening another requires completely stopping all payments between the two parties until an appropriate number of onchain confirmations have been received for the close-and-reopen transaction.

  Splicing provides a solution where parties cooperatively create an onchain transaction that adds to or subtracts from the channel. When adding funds (splicing in), the funds previously in the channel can continue to be used offchain without interruption while the new funds are being confirmed. When spending funds onchain (splicing out), the remaining funds can also continue to be used offchain without interruption while the onchain recipient sees no difference from a normal transaction. This allows the wallet UI to make in-channel funds part of the total available balance for spending in onchain transactions so that users don’t need to manually manage offchain and onchain balances separately. Combined with multipath payments that allow funds from multiple channels to be intermixed in payments, this greatly simplifies spending: users will just click a link, review the invoice, and click Pay—letting the wallet automatically use any of its available balance for either an onchain payment or an offchain payment using any number of paths.

  For more information, see the following threads: 1, 2, 3. Also see the news item about channel splicing in Newsletter #17.

• Wumbo: by agreement among early LN implementations, currently each channel’s capacity is limited by default to about 0.168 BTC (about $40 USD when defined; currently about $750). This was chosen to help prevent users from putting too much money into unproven software.

  Several years later, LN has matured significantly and some participants want to signal that they’re willing to open higher value channels. The 1.1 spec proposal will allow such participants to set a bit named “wumbo” (jumbo) to indicate their willingness to accept larger channels and larger in-channel payments.

  For more information, see the following threads: 1, 2. For etymological reference, the name wumbo appears to come from a segment in the SpongeBob SquarePants cartoon where an “M” is interpreted as standing for Mini, is inverted into a “W”, and redefined as standing for wumbo.

• Hidden destinations: LN payments currently route payments using an onion method similar to sending data to a Tor exit node. Alice wants to ultimately pay Zed, so she finds a path to him through Bob, Charlene, and Dan. To prevent the intermediaries from learning about anything but the two channels they route though (e.g. Charlene knows about Bob and Dan), Alice encrypts each step of the path so that only the next step in disclosed to each recipient. When Zed ultimately receives the payment, he can simply return the success preimage to Dan, who returns it to Charlene, and so forth back to Alice.

  However, Tor also has a hidden service mode where both the sender and the recipient each choose part of the path so that neither of them can determine exactly where the packets came from or went—providing significantly improved privacy. This proposal for LN mirrors that mode. Alice will still choose Bob, Charlene, and Dan, but Zed can prevent Alice from learning about his routes by choosing Edmond, Fran, and George. Zed provides information about how to find Edmond to Alice—but the information about Fran, George, and Zed’s own node is encrypted so that Alice can’t see it. This can allow hidden channels—a current feature of several LN implementations—to stay hidden even when routing payments from arbitrary spenders.

  This feature is also called rendez-vous routing. For more information, see the description on the LN protocol documentation wiki. See also the following mailing list threads: 1, 2, 3.

• 1.1 goals don’t directly address watchtowers that help protect channels for users that are currently offline, autopilots that help users open their initial payment channels, or deterministic preimage generation that allow private keys to stay offline while an online component simply completes acceptance of payments. These are services that can be built on top of the protocol and so don’t currently require any coordination between implementations.
• Source of info: https://bitcoinops.org/en/newsletters/2018/11/20/
 

 

 


---

Posted from my blog with SteemPress : https://bitcointribune.org/2018/11/24/scaling-ln-what-coming-in-1-1-release-of-the-ln/

---