Deployment of Lightning Network Node
Lightning Network is a payment channel network on top of Bitcoin, enabling off-chain transactions with finality in seconds and fees of single satoshis. Node in Lightning is not just a wallet: it's infrastructure component that routes payments for other participants, manages channel liquidity, and earns routing fees. Incorrectly configured node means blocked liquidity without income and risks of on-chain transactions during force majeure.
Choosing Implementation: LND vs CLN vs Eclair
Three main Lightning implementations with different trade-offs:
LND (Lightning Labs, Go) — largest ecosystem of tools, most widespread in commercial products. REST and gRPC APIs, rich tooling (Ride The Lightning, LNDg, Thunderhub). Recommended as default choice for new nodes.
CLN / Core Lightning (Blockstream, C) — more modular architecture via plugin system. Slightly lower-level, harder to configure, but more flexible. Preferable for developers needing custom routing logic via plugins.
Eclair (ACINQ, Scala) — used in Phoenix and Breez wallets. Less common for standalone nodes.
Infrastructure Requirements
Lightning node requires:
- Full Bitcoin node (bitcoind or btcd) — LND doesn't work without one. Full synchronized node takes ~650 GB on NVMe (pruned mode reduces to ~10 GB, but limits functionality).
- RAM: minimum 4 GB, recommended 8 GB for node with hundreds of channels
- Uptime: node must be online 24/7. Offline node can't route payments and doesn't earn routing fees. On long offline — counterparty can initiate force close.
- Uninterrupted power: UPS or cloud VPS. AWS, Hetzner, Vultr — popular options.
LND Installation and Configuration
# Ubuntu 22.04
wget https://github.com/lightningnetwork/lnd/releases/download/v0.18.0-beta/lnd-linux-amd64-v0.18.0-beta.tar.gz
tar -xzf lnd-linux-amd64-v0.18.0-beta.tar.gz
sudo install -m 0755 lnd-linux-amd64-v0.18.0-beta/lnd /usr/local/bin/
sudo install -m 0755 lnd-linux-amd64-v0.18.0-beta/lncli /usr/local/bin/
Minimal configuration /etc/lnd/lnd.conf:
[Application Options]
alias=MyNode
color=#FF6600
maxpendingchannels=5
minchansize=1000000 # 0.01 BTC minimum channel size
max-cltv-expiry=5000
[Bitcoin]
bitcoin.active=1
bitcoin.mainnet=1
bitcoin.node=bitcoind
[Bitcoind]
bitcoind.rpchost=localhost
bitcoind.rpcuser=bitcoinrpc
bitcoind.rpcpass=STRONG_PASSWORD
bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333
[routing]
routing.strictgraphpruning=true
[tor]
tor.active=1 # Recommended for privacy
tor.socks=127.0.0.1:9050
After first run — wallet initialization:
lncli create # Creates seed phrase (24 words) — save to cold storage
Mandatory: backup channel.backup file. LND creates it automatically on each channel change. Without it on data loss, funds in channels can be lost. Set up automatic backup to S3/Dropbox:
# Watchtower or simple rsync on file change
inotifywait -m -e close_write ~/.lnd/data/chain/bitcoin/mainnet/channel.backup |
while read; do
aws s3 cp ~/.lnd/data/chain/bitcoin/mainnet/channel.backup s3://your-bucket/
done
Channel Liquidity Management
Opening first channels — most important step. Lightning liquidity is asymmetric: when opening channel all funds on your side (outbound liquidity). To receive payments, need inbound liquidity — funds on counterparty side.
Choosing channel partners: open channels with well-connected nodes. Analysis tools:
- lnnodeinsight.com / amboss.space — centrality score, uptime, routing activity
- LNDg (self-hosted) — analysis of own channels, routing history
- Command
lncli describegraph— full network graph for analysis
Good strategy to start: 3–5 channels with top-50 nodes by betweenness centrality, channel size from 0.02 BTC.
Channel balancing: circular rebalancing — send payment to yourself through another route, moving liquidity from one side of channel to another. Tools: bos rebalance (Balance of Satoshis) or charge-lnd.
Submarine Swaps: exchange on-chain BTC for off-chain liquidity (and vice versa) via HTLC. Loop In / Loop Out from Lightning Labs — service for liquidity management without closing channels.
Routing Fees and Node Economics
Each routing hop brings fee = base_fee + fee_rate × amount. Standard values:
lncli updatechanpolicy \
--base_fee_msat 1000 \ # 1 sat base fee
--fee_rate_ppm 100 \ # 100 ppm = 0.01% of amount
--time_lock_delta 40 \
--min_htlc_msat 1000 \
--max_htlc_msat 990000000 # Maximum HTLC (less than channel size)
Profitability depends on volume of routed payments. Well-configured node with $50k liquidity in channels earns $100–500/month in routing fees. Poorly configured — few dollars.
Charge-lnd — tool for dynamic fee management based on channel balance:
# charge-lnd.config
[proportional]
# Raise fee when outbound liquidity low (channel unbalanced)
strategy = proportional
min_fee_ppm = 50
max_fee_ppm = 2000
Watchtower — Protection from Fraud
When offline node counterparty can theoretically publish old channel state and take funds (breach transaction). Watchtower — independent service that monitors blockchain and publishes penalty transaction if attack detected.
# Connect to public watchtower
lncli wtclient add \
0294d1b2cc7cc4f8b4c33dd43b0b6c5abdc3cac2474bf6c8b2e25bb050cbcec2c3@watchtower.example.com:9911
Can also run own watchtower on separate server via --watchtower.active=1 flag in LND.
Monitoring and Operational Aspect
Thunderhub or Ride The Lightning — web interfaces for managing node. See channel state, pending HTLCs, routing history, open/close channels via UI.
Metrics: export to Prometheus via lnd_exporter or built-in in LNDg. Key alerts:
-
lnd_up == 0— node unavailable - Channel with
local_balance_sat / capacity < 0.1— unbalanced, needs rebalance - Force close from counterparty — needs on-chain transaction
Typical timeline from zero to running node with channels: 1–2 weeks (including Bitcoin node sync and channel opening with confirmations).