From #reckless to Wumbology: Lightning Network’s Infrastructural Build Out - Year One


via TheBlockCrypto

From #reckless to Wumbology: Lightning Network’s Infrastructural Build Out

QUICK TAKE

  • The Lightning Network has incredible momentum heading into 2019 with upgrades across liquidity provisioning, privacy, security, and usability
  • The first apps are starting to be built as developer confidence improves and barriers to entry drop

Lightning Network’s infrastructural build-out was one of the most anticipated developments of the second half of 2018. Significant progress in both R&D and implementation has increased hype and anticipation for what is setting up to be a year of major improvements to the network.

The Lightning Network’s goal is simple: provide a way for users to easily facilitate off-chain payments as fast and reliably as possible while keeping the design accessible to the average user. Expecting users to run full nodes as a prerequisite or attempting to have them manage channel liquidity manually is infeasible.

As such, the primary focus of Lightning development in 2019 is centered around four areas: (1) improving security guarantees in the system (2) maximizing liquidity at all steps of the process (from ease of funding to liquidity provisioning within channels) (3) improving privacy and (4) simplifying UX as much as possible.

This is not a gentle introduction to the Lightning Network. Aaron van Wirdum’s excellent four part series on how the Lightning Network works is an excellent resource for those looking for an introduction. This article is aimed at informing users who are familiar with the basic mechanics of the network about what’s in the development pipeline.

For those interested in a more in-depth treatment, the Bitcoin Op-Tech newsletter and lightning-dev mailing lists are a treasure trove of debate over protocol specifications, progress updates, and indications of what’s on the roadmap.

Lightning Infrastructure & Products

It’s important to start with infrastructure: that’s where much of the development has been focused, laying the groundwork for both future use for payments and more advanced application development.

There are several Lightning Network clients, the three most popular being lnd from Lightning Labs (written in Go), eclair from ACINQ (Scala), and Rusty Russel’s c-lightning (C, of course).

New interfaces like Pierre Rochard’s Node Launcher allow for easy set up with both a Bitcoin and Lightning node with very simple GUIs (which can then be connected to a host of wallets including Zap, Spark, Wallet of Satoshi, etc.). User-oriented products like Bitrefill are aimed at making it easier for users to open and fund channels.

Casa’s Node is an out-of-the-box Bitcoin & Lightning Node that looks good in your apartment. Similarly, BTCPayServer, OpenNode, Coingate, and ACINQ’s Strike allow developers to easily integrate Lightning payments.

Lightning Joule is an open-source MetaMask-like wallet built by Will O’Beirne that allows for easy, browser-based LN payments. While it’s still in alpha, it hints at what future UX will look like — including a potential identity solution. It wouldn’t be surprising to see other Ethereum dApp design patterns similarly adopted. Apps that have integrated Lightning Joule already includelightningspin.com and LightningK0ala’s LN Chess.

There are also some fun products being built integrating Lightning. It’s important to note, while the apps appear simplistic, the Lightning Network hasn’t yet reached full maturity. Further improvement of developer tooling like WebLN will allow for easier integration in the future as the barrier to entry drops. Some of my favorite nascent demos include Microbet, a LN-enabled prediction market, and Y’alls, a micropayment enabled content site.

Will O’Beirne’s Lightning Joule offers a MetaMask-style wallet for Lightning users.

Technical Improvements

Lightning development in 2018 was showcased at the second Lightning Development Summit in Adelaide, Australia. Just two years after the initial Lightning Network specification was presented in Milan, the spec for version 1.1 was kicked off with dozens of potential proposals fighting for inclusion.

Since Lightning is built on Bitcoin, many future improvements are downstream of technical improvements to the base layer.

The majority of improvements in the latest Lightning spec focus on the key areas specified above: usability, security, liquidity provisioning, and privacy. The features explored are in various stages ranging from proposal to working implementation. A bulk of these improvements are slated for inclusion over the course of the year, setting up for a big year for the Lightning Network.

Neutrino

Unlike full nodes which have a full historical record of transactions, lightweight nodes only sync block headers and use a method called Simple Payment Verification, originally described in theBitcoin whitepaper, to verify transactions. Mobile devices—underpowered, with limited bandwidth and power—instead have lightweight nodes operating behind their wallets.

Lightweight nodes still need to be connected to full nodes to validate transactions. In this process, clients send a filter (called a Bloom filter) to a full node, which then returns a set of relevant transactions,which are then used locally by the wallet for validation. Unfortunately, this process has shown to cause privacy loss as it’s possible for a listening node to detect wallet addresses. In addition, a potentially malicious node may choose to omit relevant transactions. Since Lightning transactions are responsive to on-chain events, an omission would be problematic.

To solve this, Lightning Labs’ Olaoluwa Osuntokun (roasbeef), Alex Akselrod, and Jim Posen presented Neutrino, an experimental lightweight client aimed at “[minimizing] bandwidth and storage use…while attempting to preserve privacy” via BIP 157 and BIP 158. Neutrino uses filters, specifically Golomb coding sets, or GCS filters. GCS filters offer a much greater degree of compression, enabling Neutrino clients to use much less storage and bandwidth.

Neutrino is currently in active development and is expected to fully hit mainnet this year. Currently, users have to run a full node in order to operate a Lightning wallet. Neutrino is currently available in lnd and Lightning App’s alpha (testner). Once it’s merged into Bitcoin Core, mobile LN wallets will be able to offer extremely straightforward UX as sync times drop to minutes and users won’t have to run full nodes to use Lightning.

Submarine Swaps

Submarine Swaps were developed by Alex Bosworth (and originally termed by roasbeef) as a way to make off-chain and on-chain payments more seamless. Today, most wallets delineate between bitcoin that exists on-chain and bitcoin that exists in Lightning channels.

Even though both are theoretically fungible bitcoins, bitcoin that exists on-chain can’t be used to settle a Lightning transaction. Submarine Swaps allow users to send Lightning payments to middlemen who then settle transactions on-chain (or vice versa). Though these middlemen can charge fees, stealing bitcoin in this type of transaction is impossible as the entire process happens atomically.

Submarine Swaps also go a long way to assuage concerns over routing imbalances. While Submarine Swaps appear to be a temporary stop-gap in light of potentially better solutions, it exists today and can be used to improve the UX of atomically moving between on-chain and off-chain bitcoin balances.

Dual Funded Channels

Currently, Lightning channels can only be funded by a single party: if Arjun and Mike want to open a channel between them and Arjun funds a channel with 0.1 BTC, Arjun can send Mike a payment and route through Mike but can’t receive payments directly from or routed through Mike until Mike has funded the transaction.

Sourcing this inbound capacity for payments is difficult: in Lightning’s nascent growth, it often requires offline coordination. In a dual-funded channel, Arjun would fund a channel with 0.1 BTC if Mike also funds a channel with 0.1 BTC, this comes with cost: opening a channel requires an on-chain transaction and opportunity cost (of the capital committed). However, Mike can earn routing fees, earned by merit of providing liquidity to the network.

While there are concerns that fees may be too low to provide incentive for large liquidity providers (e.g. merchants), proposals like Lisa Neigut’s are in the works to potentially allow channels to signal their willingness to provide inbound capacity for Lightning channels (along with a certain fee expectation).

While dual-funded channels are already in Lightning Network’s lnd , they’re not really exposed to the network. With adoption growth, dual-funded channels allow even larger liquidity provisioners like exchanges to more easily onboard users to the Lightning Network by providing incoming channel capacity.

Atomic Multi-Path Payments (AMP)

Atomic Multi-Path Payments (AMP) came out of a 2018 mailing list proposal from roasbeef and Conner Fromknecht answering the question: “I have five $2 channels, is it possible for me to atomically send $6 to fulfill a payment?” The way payments are currently routed is through a single path, from Arjun’s channel, through Mike’s, to Larry’s.

This works well for small payments where there’s enough liquidity in each channel to seamlessly route a payment, but comes with a serious limitation. If Arjun’s funds are spread across multiple channels, Arjun has limited access to liquidity.

AMP solves this by allowing multiple partial payments to go through different channels and guarantee proper receipt, using the same security mechanism of single-path payments. The smaller bits of a payment can only be redeemed if all parts are sent, which avoids issues with partial payments.

While the specification of AMP isn’t finalized, there are several proposals including the OG AMPand Base AMP. Full deployment of AMP will meaningfully improve the UX around payment routing and improve liquidity in the Lightning Network.

Splicing

For now, increasing a channel’s capacity or taking money on-chain requires closing a channel and takes time. A new proposed feature, splicing, originated from Rusty Russell last October, allows users to coordinate an on-chain transaction to add or remove funds from a channel.

Right now, many Lightning Network wallets have both on-chain and off-chain balances. Once splicing is fully integrated, users will be able to send on-chain transactions from their off-chain balances. Splicing also allows users to directly deposit into channel addresses so it materially improves routing efficiency in the network in addition to providing flexibility over expanding and contracting channel balances.

Splicing serves as a significant improvement to today’s Submarine Swaps as it cuts out the need for a middleman in the settlement process. This is strongly synergistic with AMP: a world with both AMP and splicing allows users to receive an invoice in their Lightning wallet, make a payment, allow their wallet to draw from on-chain balances and off-chain channels (from a number of different channels) seamlessly without worrying about manually managing liquidity.

The future of Lightning UX is promising. You can imagine a world where users have the option to make different decisions about the speed of their payment being routed (v. the cost, for example) and different tradeoffs that come out of a robust, liquid routing fee market.

Wumbology

Wumbology is a reference to an episode of SpongeBob where Patrick Star invents the word to mean “big.” In the Lightning Network, this means channels are getting bigger. Currently, the Lightning Network has a channel size limit of 0.16 BTC and a payment limit of 0.04 BTC.

As developers gain comfort with the security of their implementations, bits that indicate that a client can expand channel capacity will be available, allowing double opt-in support for much larger channels than were previously possible.

The power of wumbology will bring greater liquidity to the network as channel capacities increase (and payments can more easily be routed through the system). While Lightning started out #reckless (indicating that upon 2018’s launch it was still immature and funds could be lost), the proposal to increase channel limits represents a major step in the maturity of the network.

RIP Stephen Hillenburg (November 2018), thank you for giving us this incredible meme.

Sphinx-send

Just this week, roasbeef landed a pull request for the “sphinx send” feature, building on an older non-Bitcoin paper that proposed in Lightning, payments are rooted from an origin node (Arjun) to a final node (Mike). While Arjun and Mike may trust each other, they don’t know all the owners of all of the channels along which their payment is being routed. As a privacy improvement to the Lightning Network, Sphinx constructed routes allow the sender’s identity to be obfuscated in this process.

In addition, Sphinx construction allows Lightning to work without having recipients request invoices first. This was previously a major Lightning UX headache so it constitutes a major improvement.

“Sphinx send” is currently in development but can be used today once it’s merged and nodes are fully upgraded. Sphinx sends potentially unlock new kinds of one-way payment use cases.

eltoo and Channel Factories

eltoo is a protocol first proposed in an April 2018 paper from Blockstream’s c-lightning team. In the current implementation of the Lightning Network, older off-chain balances are unsafe. Broadcasting these older balances constitutes “cheating” and funds are slashed (with users being penalized). This is not ideal. There are lots of reasons why users may broadcast an old state however, including bugs and latency issues from backups.

In Eltoo , if a user broadcasts an old state, their counterparty has a window to broadcast the latest transaction to correct the final balance. This arbitration system “makes it much easier and computationally efficient for payment channels to be opened between many users in a single onchain transaction” per Bitcoin’s Op-Tech update.

This also enables downstream improvements like Channel Factories. Today, operating a Lightning channel requires two on-chain transactions (to open and close). Channel Factories are aimed at making this process more efficient.

While two on-chain transactions per channel (which could offer a theoretically unlimited number of off-chain transactions) doesn’t seem like very much, Channel Factories allow multiple users to open unlimited intra-group channels. Particularly as product offerings implementing the Lightning Network are built by larger companies, this could significantly decrease the number of on-chain transactions required to participate.

Both proposals require a soft fork to add a new signature hash flag (BIP 118), SIGHASH_NOINPUT_UNSAFE, which allows signatures to authorize the spending of all UTXOs that could be spent by a given private key (rather than individual UTXOs). Core developers are optimistic that this could potentially be rolled into a larger soft fork, potentially with Schnorr signatures.

One of the major concerns voiced by critics early on about the Lightning Network was “Won’t high on-chain transaction fees increase Lightning centralization?” due to the inaccessibility of opening channels. Channel Factories help mitigate this concern by enabling easier opening and closing of channels. Further on-chain improvements (like Schnorr signatures) should help compress signature sizes even further, making Lightning even more accessible.

Watchtowers

While Lightning users will be able to use more advanced filtering features (like Neutrino’s GCS) to grab relevant on-chain transactions, Watchtowers provide an additional guarantee that users aren’t being cheated by their counterparties on the Lightning Network.

Watchtowers were first described in the Lightning white paper though the initial design has been significantly improved upon. One of the initial concerns with the Lightning Network was “since the payments are off-chain, what if a counterparty cheats me by broadcasting an invalid state (for ex, if I’m offline)?”

Outsourcing monitoring for malicious to watchtowers is one potential solution to this problem and a similar design is included in other payment channel systems, like Ethereum’s Raiden (which calls them “monitoring services”).

In the Watchtower system, when Arjun and Mike have a channel open, Arjun would broadcast a signature authorizing all funds to be transferred back to Arjun in the event of malicious activity by Mike. This broadcasted data should be enough to detect invalid states while preserving the privacy of the individual payments in the channel. If there’s an invalid state broadcast by Mike (where the funds are then locked for some time), Arjun has the opportunity to claim all funds deposited in the Lightning channel.

While some may cry “centralization”, watchtowers are not part of the core protocol design. They will be run and operated by third parties. Watchtowers may charge fees for watching transactions as they have operating costs. In the future, watchtowers may be a service offering from exchanges or other large businesses seeking to help onboard users to the Lightning Network though their design pose some privacy concerns.

I couldn’t be more excited to see the growth of Lightning in 2019 as it finally grows out of initial infrastructural and design pains with accelerated product development and liquidity. Follow along with Lightning’s growth and stay #reckless.

2 Likes

💰 YEN · YouTube ·️ YEN.CAMP 🧠