1 of 19

Probing Lightning Channel Balances

⚡

Sergei Tikhomirov (University of Luxembourg)

Joint work with Rene Pickhardt, Alex Biryukov, Mariusz Nowostawski

Full paper: https://arxiv.org/abs/2004.00333

Lightning Hackday, 2020-04-04

2 of 19

Outline

Lightning introduction (very brief)
Path finding in Lightning
Our channel probing technique
Results (on testnet)
Can we have privacy and efficiency at the same time?

3 of 19

LN intro (for completeness, I know you know this ;)

Second-layer scaling solution for Bitcoin
Payment channel: 2-of-2 multisig + off-chain updates
Revocation: if Alice cheats, Bob retaliates (before timeout)
Multi-hop payments: paths of channels re-balance atomically

4 of 19

LN routing

Nodes gossip about new channels
Sender sets the route based on the local view of the network graph
If payment fails, an error indicates which channel failed
Repeat with another route until the payment succeeds

5 of 19

Example: LN as seen by ACINQ (node 0386..3f8f)

6 of 19

Why do payments fail anyway?

The sender doesn’t know the true state of the network!
A node may be offline
A node may refuse to forward for whatever reason
A channel may lack capacity

7 of 19

Lightning privacy: are local balances private?

Let’s only consider public channels (for now)
Total capacities are known (confirmed on-chain): definitely public

What about local balances?

There is no API call to query local balances, but can we still discover them?

8 of 19

Probing one channel

Consider a channel: [Alice 3 --- 7 Bob].
Mallory connects to Alice and forwards payments to Bob
Random values as payment hashes => all payments fail…
… but with different error messages!
Try sending 5 => “insufficient capacity” (“channel temporarily unavailable”)
Try sending 2 => “unknown hash” (“incorrect or unknown payment details”)

9 of 19

Probing a route

Mallory can probe along a route of channels: [c₁ -- c₂ -- … c_n].

Let’s say some channel failed while probing with amount a.

This means that balance (at the side closer to Mallory):

balance > a before the failing channel
balance < a at the failing channel

10 of 19

Our actual probing algorithm

Get a list of all nodes
Select only live nodes

Heuristic 1: connect via P2P
Heuristic 2: send 1000 satoshis

For each channel: send binary-search probes to both its ends

To probe channels with only one direction available for routing
Also, better to probe unbalanced channels from “smaller” end

Save the info we obtain about intermediary channels along the way

Implemented in Python as a c-lightning plugin (the plugin system is so cool!)

11 of 19

Technical challenges

Parallel channels: are we probing what we think we’re probing?

The sender sets the order of nodes in the route, but what about channels?
Non-strict forwarding is a thing: Alice can choose which channel to Bob to use
Multi-path routing would be a game changer

Large channels: should use concurrent in-flight HTLCs to fully probe

Requires malicious receiver to keep capacity blocked
Max channel size is ~0.16 BTC, but max HTLC amount is ~0.04 BTC
Can fully probe large channels only if they are “unbalanced” (~1:3)

In-flight HTLC hanging: our capacity is blocked if recipient is dead

Attacker must have enough capacity to send probes; hanging HTLCs occupy it

12 of 19

Results: we can probe the whole testnet overnight

We probed the whole testnet (200+ live nodes, 1600+ live channels) in 14 hours.

Mainnet has ~20x more channels, but optimizations are possible (see paper).

13 of 19

50% of channels can be probed in ~20 seconds

14 of 19

We can probe nearly all small channels

Can’t fully probe large channels:

max channel size ~ 0.16 BTC
max tx amount ~ 0.04 BTC

Can fully probe only if balance is in 1^st or 4^th “quarter”.

15 of 19

Are local balances worth protecting?

It may look like local balances are private, but their probing is very cheap
Hard to ban probing nodes because of onion routing
At the same time, knowing local balances improves routing!
Instead of sending 5 coins via [3 -- 7] channel, simply query its balance first

16 of 19

A privacy-efficiency tradeoff

As protocol designers, we can go two ways:

Protect local balances, i.e., don’t report where exactly routes fail
Improve efficiency: reveal local balances if queried

Let users set individual policies for their nodes / channels w.r.t. this tradeoff?..

Interesting questions for future research!

17 of 19

Q&A

Follow me on Twitter @serg_tikhomirov

Read the whole paper for more detail:

https://arxiv.org/abs/2004.00333

Huge thanks to Rene, Alex, and Mariusz!

18 of 19

19 of 19

Channels are either well or poorly balanced