Lightning This Week #657,227
Lightning This Week #657,227
Swimming pools, blockchain watchdogs, and new LN ecosystem research
Hello World,
IT LIVES — Lightning This Week is reborn! If you didn’t know, LTW is a project I started in November 2019 with the aim of creating a constant log of interesting developments happening in the Lightning Network space, with a deeper focus on the software engineering side of things. Every week I’d gather codebase changes (pull requests/issues) of major implementations, projects and documentation RFCs, new posted releases, discussions in mailing lists, and other general links, and then highlight a few items more in depth. After a few months of hiatus and some project restructuring, I’m happy to say LTW is back, this time as a Substack Newsletter.
The aim of Lightning This Week is to maintain tech-savvy Lightning Network (LN) enthusiasts and engineers at the forefront of the developments in the technology with a simple weekly digest. Short and sweet, straight to the point. I’ll also add in some opinion/interest links that I think might be worth your time.
Ecosystem is Growing
Oleg Mikhalsky and Moritz Kaminski just released a comprehensive research piece on the state of the Lightning Network. As the team states:
“Ongoing qualitative research on the advantages and disadvantages of the technology is providing reasonable evidence of the progress and remaining challenges, and the ecosystem has recently enjoyed more interest from the venture capital industry. But a comprehensive quantitative analysis was yet to be performed and we believe that this attempt paves the way for further systematic exploration of the ecosystem that will help answer questions about the domains of applicability of the Lightning Network and its incredible but yet to be fully uncovered economic and social potential.”
The research was conducted during summer-fall of 2020 and uses similar 2018 and 2019 research studies as base resources. The piece speaks for itself and I would encourage everyone to take a few minutes and read through it all. However, a point I’d highlight is how Gaming seems to be taking quite a central stage in this nascent industry.
We’ve now got game development tools and infrastructure for onboarding Bitcoin and Lightning into games enabled through ZEBEDEE. Lightning-enabled multiplayer games allowing players to earn and transact sats with one another by THNDR Games, Donnerlab, Satoshis Games, and others. And a monthly Bitcoin eSports Gaming event MintGox breaking the 4th-wall of interactions between audience, streamers, and players, enabled by the use of Lightning microtransactions. Be on the lookout for further developments in the Lightning Gaming front in the coming weeks and months.
Swimming in the Lightning Pool
Lightning Labs team recently released the Lightning Pool product — a non-custodial, peer-to-peer marketplace for Lightning node operators to buy and sell channels. I think this is one of the most important Lightning-related product releases I’ve seen in a while, as Pool effectively makes Lightning liquidity a tradeable asset. The expectation that Bitcoin can yield returns is finally real, and it is achieved while maintaining full custody of your funds.
While the initial contract for Lightning Pool offers is set for providing incoming channels for a period of 2,016 blocks (~roughly two weeks / same as difficulty adjustment period), the team hopes to increase the offerings as the product matures and more network participants begin to provide liquidity. No longer must current node operators provide incoming channel liquidity free-of-charge. Pool helps create a market standard for Bitcoin liquidity in the Lightning Network.
At this time, there have been a total of 135 Lightning Pool contract offers that have been matched, totaling over 9.16 BTC in capacity. Long live Lightning financial markets!
Blockchain Eclipse Watchdogs
PR 1545 brings a new feature to the Eclair node daemon: Blockchain Watchdog — a watching tool that helps detect whether the Bitcoin node used by your Eclair Lightning Network node is suffering from an eclipse attack.
Eclipse attacks occur when a node is isolated from all honest peers but remains connected to at least one malicious peer. Without any connections to honest peers, the eclipsed node won’t receive the latest blocks on the most proof-of-work blockchain. This gives the attacker an unlimited amount of time to generate blocks containing double spends, so even an attacker with a small minority of hash rate can trick the victim into accepting confirmed double spends.
To achieve this the Eclair node will attempt to fetch block headers from multiple outside sources to compare with the local block headers from Bitcoin Core. If anomalies are found, the node is likely being eclipsed. The current external sources are set for blockstream.info, mempool.space, blockcypher.com and blockchainheaders.net, but more sources will likely be introduced. As it relates to Lightning specifically, a successful eclipse attack would provide the path for an attacker to hide a malicious channel closing attempt from you (with a false channel state that favors the attacker), as your Bitcoin node would never receive that block/header, and would thus be completely unaware that a Lightning peer is attempting to close a channel / steal funds.
Pubkey-Based HTLC Routing Discussions
Joost Jager recently proposed a change (addition?) to the Lightning Network RFC spec that would allow for a new HTLC routing mode based on a node’s public key instead of short channel IDs. The main advantage of short channel IDs is that they are short (8 bytes), but a great downside is that a channel ID corresponds directly to a channel point onchain. This is not a problem for public channels, as these channel points must be public such that other nodes are able to verify the channel’s validity/existence.
For private channels however, this is a data privacy leak as a channel point presumes the size of a channel, thus revealing the amount of funds deployed to such private channel. This makes nodes with large private channels a larger attack target, especially given Lightning Network nodes are essentially Bitcoin hot wallets. It would be a great upgrade in the context of a node operator with private channels that does not wish to leak information whenever they request an invoice.
Private channels are only disclosed in invoice route hints and don't need to be verified. The invoice is created and signed by the receiver […] Someone can theoretically request an invoice (or multiple invoices) from a service that accepts Lightning payments and inspect the route hints to gauge the service's node capacity.
There’s some discussion in the RFC issue around how to propose this (and future changes) — standalone BIP-style documents or a simple change to the specification. Click here to read more or opine yourself.
Things I Would Share This Week
Rasbperry Pi 400 — If you’re a Raspberry Pi fan, the Pi 400 is a full Pi-based computer built entirely in a slick-looking keyboard. I’ve ordered one and hope to provide more details later.
Bitcoin Bounty Hunt — Donnerlab just posted the latest version of BBH first-person shooter game with Lightning enabled. If you haven’t played it yet, get on it so you can participate on this month’s MintGox Bitcoin eSports Gaming event on Nov. 29th.
NYC Mesh— a mesh network of interconnected nodes/hubs that provide internet access on a donation-based scheme. If you live in a densely populated area, you may have a similar project near you. Help out if you can!
That’s all for Lightning This Week. See you all in ~1,000 blocks.
Disclaimer: I’m always learning. If I have made mistakes or misrepresented you or your project/company please reach out so I can amend any posts.