Choosing the Right Lightning Network Implementation
The Lightning network is an open protocol that follows the B.O.L.T open standard. There are multiple implementations of the lightning network and they should all go by the B.O.L.T. standards. When in doubt, always refer to the B.O.L.T. standards.
Popular Implementations
Below are a few popular lightning network implementations that follow the BOLT standards, LND, C-Lightning, Eclair, Rust LDK, and Electrum. They mostly vary by language, C-Lightning is written in C, Eclair is written in Scala, LND is written in Go, Rust LDK is written in Rust, and Electrum is written in Python.
Criteria
Besides language preferences, here are a few additional considerations to take into account when choosing the right Bitcoin Lightning implementation.
Bitcoin client support (regular and light)
🖊 Partially Signed Bitcoin Transactions (PSBT) Support
💻 Platform Support
Platform support is about where we can run these implementations, like can you run on a mobile Android, iOS, Linux Desktop, etc. This criterion is dependent on what hardware you have available and mostly what use case you’re trying to solve for.
Bitcoin client support (regular and light)
An implementation that supports both full and light (SPV) Bitcoin clients offers more flexibility. Full clients provide higher security but require more resources, whereas light clients are easier to run but might offer less security.
💰💰Dual Funded Channels
Dual-funded channels allow both parties to contribute to the funding transaction when initiating a channel. This brings lower transaction fees because they can jointly construct and sign the funding transactions and allows for a large payment capacity because both parties fund it. In a regular channel, only one party can fund the channel.
💰💰💰Multi-Funded Channel
A multi-funded channel is similar to a dual-funded channel, except now more than one party can contribute to the funding transaction when initiating a channel.
🖊 Partially Signed Bitcoin Transactions (PSBT) Support
PSBTs are a binary transaction format that allows multiple parties to sign on the same transaction at different times and share information on the transaction. This is useful if another signer is offline (ex. they are using an air-gapped wallet or hardware wallet) or a watch-only wallet that just creates transactions but can’t sign.
🗼Watchtower Support
Watchtowers act as third-party services that monitor the blockchain for malicious activities related to your Lightning channels. This adds a layer of security when you’re unable to actively monitor your channels.
Check out the description of Watchtower in the article below:
🗄 Database Required
Many of these implementations use embedded databases but can use more robust database solutions like PostgreSQL. Databases in Lightning are used to manage transaction and channel state management, routing details, and auditing.
🔑 Keysend Support
Keysend allows funds to be sent to a node without an invoice, which means you can spontaneously send someone funds without them ever asking for it. In non-keysend payments, the receiver needs to send an invoice presented by email or a QR code, with keysend payments this isn’t necessary, the receiver just has to share their node ID (a public key) once to receive payments.
What is the difference between a regular transaction and a keysend transaction?
In both cases, using onion routing helps preserve privacy by making it difficult for observers to see the identities of the sender and receiver and the payment amount. However, the use of keysend in the second transaction simplifies the process by allowing Bob to send the preimage directly to Alice’s node without the need for intermediate nodes to forward the packet.
Why you shouldn’t use the same pre-image?
Using the same preimage can allow an observer to link multiple payments together. All those payments will be tied to the same hash value, and an observer can link the payments by identifying transactions that have the same hash value.
Disadvantages of Keysend
This all sounds wonderful, but there are disadvantages to using this approach. Accepting payments without an invoice can open you up to:
- Dusting attacks (a small amount of satoshis are sent to track an address),
- Spammed wallet (someone from an unsanctioned country can send funds to your wallet and raise flags)
- Lack of payment confirmation, since an invoice isn’t required, there is no way a sender can confirm that the payment received by the intended recipient
📺 Channel Backup
Data Loss Prevention is crucial when planning for your lightning node. To handle DLP scenarios, lightning has different channel backup strategies.
Static Channel Backups (SCB): Backup files (in LND files called channel.backup) that are encrypted using a key derived from your wallet seed. This file will allow users to recover both their on-chain funds and funds settled (base commitment outputs but not HTLC’s) within their channels. It’s called static because the file is only obtained once and is valid till the channel is closed.
Note: This file sits on the node, so there needs to be a script that copies this file whenever there are changes to another instance outside of the node.
Dynamic channel backup: This is a more advanced method of backing up a channel that involves creating a backup channel that runs in parallel to the primary channel. The backup channel is updated with the latest state of the primary channel and can be used to recover funds in the event of a channel failure.
Database backup: Some Lightning Network nodes offer a feature to automatically backup channel data to a database or other storage location. This can provide an easy way to recover channels in the event of a node failure or other issues.
Offline storage: Another option is to back up the channel information to an offline storage device such as a USB drive or external hard drive. This can provide a secure backup that is not vulnerable to online attacks.
Below are instructions on how to recover funds when using the LND implementation:
Summary
No single implementation reigns supreme; different implementations cater to various priorities and use cases. If features are your priority, then considerations like keysend, dual-channel, and multi-channel funding are crucial. For those prioritizing security, watchtower support, database management, Bitcoin client support, and channel backup are crucial. And if flexibility and use-case adaptability are paramount, then platform support is crucial.
Resources
LDK Lightening Dev Kit
Lightning Implementation Features by Fulgur Ventures (Inspiration for this blog)
Keysend Payment
Voltage Keysend Payment Explained
PSBT Formats — BIP 174
PSBT Version 2 — BIP 370
BOLT Standards
