Project Updates: Hybrid Channel Jamming Mitigation #1218
Description
This issue will be regularly updated to provide meta updates the ongoing work to mitigate channel jamming attacks in lightning. We'll still use delving / spec calls for detailed discussions.
⚠️ You only need to read this paragraph ⚠️
Currently: ✨ Seeking review of #1280 ✨
TLDR:
- We have early simulation results for the following attacks and found (so far) that:
- To build enough reputation to fully occupy a channel's resources, an attacker must pay the target more than it would have earned in times of peace.
- There is no revenue loss when an attacking node passively builds reputation by forwarding payments then general jams and holds any forwards from the target node.**
- With the introduction of access to general resources, both attacks require either:
- Opening of many channels with the target to gain access to all resources.
- Opening several channels in strategic locations within the network to gain access to all resources.
- We simulated the impact of limiting access to the general bucket of resources using the mainnet graph:
- Three months simulation with 10x today's estimated activity and $10 expected payment value find no increase in payment failure rate.
- We'll be reviewing/improving our attacks to report final results in the next meeting.
** Note that this attack is highly topology-dependent, so we'll be trying a few different versions of it to get the full picture.
Last update: September 22
Estimated Results™️: 6 October spec meeting
Update Log
Previous Updates - Timeline
- 13 August - Updated proposal in Outgoing reputation and HTLC Accountability #1280 - take a look!
- 16 July - Finalizing outgoing reputation + accountability simulator
- 6 May - Investigating ways to drive up the cost of general jamming resources
- 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
13 August - Updated proposal in #1280 - take a look!
- We have opened up a new PR which outlines our updated proposal based on feedback / attacks on the first PR.
- We're going to re-simulate known attacks against this solution and see what the numbers look like.
16 July - Finalizing outgoing reputation + accountability simulator
- Given the insight that we're only relying on reputation for slow jamming attacks, we've decided to focus purely on outgoing reputation
- In order for a slow-jamming attack to occur, there must be a downstream/receiving attacker to hold the payment
- The upstream node may or may not be malicious (because honest nodes payments could just be held)
- We focus reputation entirely on protecting against the malicious downstream party
- We have also changed the meaning of our signaling to represent this change in direction:
- Endorsement: you may hold my reputation accountable for the behavior of this HLTC
- Accountability: I will hold your reputation accountable for the behavior of this HTLC
- By switching from endorsement to accountability we:
- Put the decision about forwarding to downstream peers on our downstream counterparty, who has more information about them
- Are able to upgrade this signal only when we need it (if resources are saturated)
- A full draft of this writeup is available here; the spec PR will be updated once we've cleaned it up.
6 May - Investigating ways to drive up the cost of general jamming resources
- 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
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.
- JamLN: simulator that implements reputation for a mock lightning network where we can run attacks.
- SimLN: network agnostic payments simulator which can run with a "mocked" network that forwards payments, including the ability to add arbitrary interception logic.
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.