Description
This issue will be regularly updated to provide meta updates the ongoing work to mitigate channel jamming attacks in lightning.
It will only be used for meta updates on the project, we'll still use delving / spec calls for discussions.
⚠️ You only need to read this paragraph ⚠️
Currently: ✨ Investigating ways to drive up the cost of general jamming resources ✨
TLDR:
- Draft of current approach is available here
- Use outgoing reputation to mitigate the risk of slow jamming attacks from downstream peers.
- Rather than endorsing by default, use "upgradable endorsement" which:
- Sets a signal from the recipient's invoice
- Copies this signal into each onion payload to prevent tampering
- Upgrade endorsement signal only if congestion is present (unnecessary in times of peace)
- Make some resources available in times of congestion to low reputation peers with stringent restrictions on usage
- Protect general resources with addrman-style slot/liquidity allocation
- This works well for direct attacks (peer connects to target), but is subject to fan in/out abuse
Last update: 6 May
Estimated Results™️: no results to report on at present
Update Log
Previous Updates - Timeline
- 14 April - Looking into recovery for nodes post-attack
- 3 March - delving post could use some eyes / looking for simulation suggestions if folks have them
- 10 Feb, post on delving needs some eyes 👀
- 3 Feb - simulator for outgoing reputation complete, running simulations with sink attack
- 21 Jan - simulator with accelerated times for long simulations complete, busy with testing + analytics
- 10 Jan - working on speeding up simulations to run long-term sink attacks
Previous Updates - Full Log
14 April - Looking into recovery for nodes post-attack
- Reputation algorithms work as expected in our simulations so far; the cost of acquiring reputation to perform an attack is comparable to the loss suffered if an attack occurs
- However, the reputation algorithm does not account for the possibility that your node can be general jammed after a two week attack:
- If this happens, your traffic does not go back to normal so reputation can't be re-built for honest peers
- This can happen for long stretches of time, because there is no cost to general jamming
10 Feb - Seeking suggestions for outgoing reputation simulations
- We've run a few simulations looking at how outgoing reputation mitigates "sink" attacks where a downstream node slow-jams traffic after honestly forwarding payments to build up reputation.
- So far, reputation behaves as we expect and cuts off the attacker before they can cause revenue loss.
- However, these simulations depend on the topology and attacker's strategy for opening channels, so we're looking for suggestions on alternative topologies/strategies to try.
3 Feb - Does outgoing reputation protect against a sink attack?
- The originally proposed reputation algorithm looked at incoming reputation - see terminology overview here.
- There was no revenue loss under attack for "typical" slow/fast jamming attacks that aim to fill up slots/liquidity.
- This algorithm did not protect against a "sink" attack, where a downstream node passively holds HTLCs to ruin reputation, because it assumes that the malicious party is upstream.
High Level Tracker:
(1) Is there revenue loss when a node is targeted by a channel jamming attack?
If the price to obtain good reputation is comparable to the cost suffered when it is abused, nodes that are targeted by a jamming attack do not suffer economic loss.
- Incoming reputation attackathon
- No revenue loss for [slow/fast] [liquidity/reputation] attacks
- Revenue loss under a "sink" attack
- Reputation laddering attack is inefficient
- Surge attack has a pathological edge case
- How common / severe is this edge case?
- Outgoing reputation investigation
- Is there revenue loss under a "sink" attack?
- Is there revenue loss for [slow/fast] [liquidity/reputation] attacks?
- Do we need bidirectional reputation?
- Is there a "see-saw" reliability issue (drop if endorsed / drop if not endorsed)?
- Attackathon - try to break it again
(2) Are honest nodes able to obtain reputation?
Honest traffic is protected from jamming attacks in this mitigation if nodes are able to obtain good reputation. We should confirm this with real world data!
- SimLN sanity check: 60-70% of nodes in mainnet sample of 100 nodes can build good reputation*
- Experimental endorsement signaling
- Implementation support:
- BLOCKED: Senders set endorsement signal (waiting on deployment of feature bit in network)
- BLOCKED: Threshold to forward as endorsed for non-binary algorithm
- Data collection
(3) Does resource bucketing have no impact on the steady state?
Under regular operation, the introduction of reputation and resource bucketing should not be a barrier to entry for new/infrequently active nodes because channels are only saturated under attack. We should confirm this with real-world data!
- SimLN sanity check: mainnet sample of 100 nodes processing 2x its capacity per month does not saturate channels*
- Early sanity check with ~10 large nodes in the network: nobody sees > 10 htlcs in flight at once
- BLOCKED: Data collection measuring liquidity/slot usage (will do this alongside (2) )
* Of course, all simulations are highly dependent on assumptions made about traffic patterns. They merely act as a sanity check - if it breaks there, it probably breaks IRL too.
Tooling
We've built out a lot of tooling in our research, listed below. This will be useful if you're interested in running simulations yourself, or testing out some of our results.
- Attackathon branch: this repo allows you to spin up a test network in warnet and run attacks against a network fully implementing outgoing reputation mitigation
- LND branch: runs LND with endorsement signals propagated (NOTE: not using the TLV number set in BLIP-004
⚠️ ) - Circuitbreaker branch: imports golang outgoing reputation library to implement outgoing reputation for LND
- SimLN branch: runs a fully simulated lightning network and records each node's forwards, useful for generating long-term forwarding projects for a topology (supports time speedup)
If you'd like to experiment with any of these HMU! It's a bit of a tangle of branches and dependencies, so can be a bit difficult to navigate.
Background Resources
If you're looking to get up to date with the context of this work, this is a good place to start.
- High level write up: overview of solution
- Original Proposal: this is out of date while we iterate on the proposal!
h/t: Package relay tracking issue in core for the idea for this issue.