Channel jamming - Revision history

NotATether: Add Attack forms and Mitigations sections

2026-09-13T07:29:40Z

Add Attack forms and Mitigations sections

← Older revision		Revision as of 07:29, 13 September 2026
Line 2:		Line 2:

	Each Lightning channel can hold only a limited number of in-flight HTLCs (483 is the usual maximum) and a limited amount of value in those HTLCs. While an HTLC is pending, the corresponding outbound balance and slot cannot be used for other payments. HTLCs are designed to wait on the order of hours because each hop needs a [[Timelock\|timelock]] gap that covers worst-case on-chain confirmation.		Each Lightning channel can hold only a limited number of in-flight HTLCs (483 is the usual maximum) and a limited amount of value in those HTLCs. While an HTLC is pending, the corresponding outbound balance and slot cannot be used for other payments. HTLCs are designed to wait on the order of hours because each hop needs a [[Timelock\|timelock]] gap that covers worst-case on-chain confirmation.

			== Attack forms ==

	In 2015 this property was described as a loop attack: an attacker routes a payment to itself over many hops and delays settlement, so the same funds lock many times their value along the path. The attack is often split into liquidity jamming (occupying value along a path) and slot jamming (filling pending-payment slots with small HTLCs). The two forms can be combined. No Bitcoin consensus change is required; the attack uses existing HTLC and onion-routing rules.		In 2015 this property was described as a loop attack: an attacker routes a payment to itself over many hops and delays settlement, so the same funds lock many times their value along the path. The attack is often split into liquidity jamming (occupying value along a path) and slot jamming (filling pending-payment slots with small HTLCs). The two forms can be combined. No Bitcoin consensus change is required; the attack uses existing HTLC and onion-routing rules.

	The attacker constructs an onion-routed payment whose destination is itself or a colluding node, or whose final hop will fail after holding the HTLC. Intermediate nodes forward according to BOLT 4 and wait for a preimage, a failure, or the deadline. During that wait, honest traffic that needs those slots or that liquidity is rejected. Because onion routing hides the destination, a forwarding node cannot tell a jammer from an ordinary slow payment. Reputation based on node identity is weak: an attacker can open many cheap channels and discard a peer identity after it is down-ranked.		The attacker constructs an onion-routed payment whose destination is itself or a colluding node, or whose final hop will fail after holding the HTLC. Intermediate nodes forward according to BOLT 4 and wait for a preimage, a failure, or the deadline. During that wait, honest traffic that needs those slots or that liquidity is rejected. Because onion routing hides the destination, a forwarding node cannot tell a jammer from an ordinary slow payment. Reputation based on node identity is weak: an attacker can open many cheap channels and discard a peer identity after it is down-ranked.

			Slot jamming is especially cheap when the attacker uses the minimum HTLC size the peer will accept. A few hundred tiny payments can exhaust the 483-slot budget while locking little of the attacker's capital. Liquidity jamming instead pushes large amounts through a target hop so that hop cannot forward other value even if slots remain. Long CLTV expiry deltas lengthen the hold window and increase the damage per jam.

			== Mitigations ==

	Proposed mitigations (none a deployed network-wide standard) include upfront or hold fees so occupying a path has a cost, local reputation or HTLC endorsement, fidelity bonds against cheap Sybil identities, and local rate limits outside the BOLT specification. [[Watchtower]]s address on-chain cheat detection, not forwarding DoS; some operators still combine always-on infrastructure with jamming defenses.		Proposed mitigations (none a deployed network-wide standard) include upfront or hold fees so occupying a path has a cost, local reputation or HTLC endorsement, fidelity bonds against cheap Sybil identities, and local rate limits outside the BOLT specification. [[Watchtower]]s address on-chain cheat detection, not forwarding DoS; some operators still combine always-on infrastructure with jamming defenses.

	~~Slot jamming is especially cheap when~~ the ~~attacker uses the minimum~~ HTLC ~~size the~~ peer ~~will accept~~. A ~~few hundred tiny payments can exhaust the 483~~-~~slot budget while locking little of the~~ attacker~~'s capital. Liquidity~~ jamming ~~instead pushes large amounts through a target hop so that hop cannot forward other value even if slots~~ remain~~. Long CLTV expiry deltas lengthen the hold window and increase the damage per jam~~.		Operator tooling such as Circuit Breaker limits how many pending HTLCs a peer may open, which raises the cost of slot spam without changing BOLTs. Research on upfront fees and HTLC endorsement aims to make long holds expensive while preserving onion privacy. Until such fees are widely deployed, forwarding nodes rely on local peer scoring, channel sizing, and refusing peers that repeatedly stall payments.

			Local defenses remain unevenly deployed. A well-connected attacker can still shift jamming load across fresh channels faster than reputation systems update, which is why fee-based holds remain an active research topic.

	Operator tooling such as Circuit Breaker limits how many pending HTLCs a peer may open, which raises the cost of slot spam without changing BOLTs. Research on upfront fees and HTLC endorsement aims to make long holds expensive while preserving onion privacy. Until such fees are widely deployed, forwarding nodes rely on local peer scoring, channel sizing, and refusing peers that repeatedly stall payments.

	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-13T07:19:10Z

Expand See also links

← Older revision		Revision as of 07:19, 13 September 2026
Line 19:		Line 19:
	* [[Watchtower]]		* [[Watchtower]]
	* [[Lightning service provider]]		* [[Lightning service provider]]
			* [[PTLC]]

	== External links ==		== External links ==

NotATether: Add local defenses and research fees

2026-09-13T07:19:08Z

Add local defenses and research fees

← Older revision		Revision as of 07:19, 13 September 2026
Line 10:		Line 10:

	Slot jamming is especially cheap when the attacker uses the minimum HTLC size the peer will accept. A few hundred tiny payments can exhaust the 483-slot budget while locking little of the attacker's capital. Liquidity jamming instead pushes large amounts through a target hop so that hop cannot forward other value even if slots remain. Long CLTV expiry deltas lengthen the hold window and increase the damage per jam.		Slot jamming is especially cheap when the attacker uses the minimum HTLC size the peer will accept. A few hundred tiny payments can exhaust the 483-slot budget while locking little of the attacker's capital. Liquidity jamming instead pushes large amounts through a target hop so that hop cannot forward other value even if slots remain. Long CLTV expiry deltas lengthen the hold window and increase the damage per jam.

			Operator tooling such as Circuit Breaker limits how many pending HTLCs a peer may open, which raises the cost of slot spam without changing BOLTs. Research on upfront fees and HTLC endorsement aims to make long holds expensive while preserving onion privacy. Until such fees are widely deployed, forwarding nodes rely on local peer scoring, channel sizing, and refusing peers that repeatedly stall payments.

	== See also ==		== See also ==

NotATether: Add mechanism: slot versus liquidity cost

2026-09-13T07:19:06Z

Add mechanism: slot versus liquidity cost

← Older revision		Revision as of 07:19, 13 September 2026
Line 8:		Line 8:

	Proposed mitigations (none a deployed network-wide standard) include upfront or hold fees so occupying a path has a cost, local reputation or HTLC endorsement, fidelity bonds against cheap Sybil identities, and local rate limits outside the BOLT specification. [[Watchtower]]s address on-chain cheat detection, not forwarding DoS; some operators still combine always-on infrastructure with jamming defenses.		Proposed mitigations (none a deployed network-wide standard) include upfront or hold fees so occupying a path has a cost, local reputation or HTLC endorsement, fidelity bonds against cheap Sybil identities, and local rate limits outside the BOLT specification. [[Watchtower]]s address on-chain cheat detection, not forwarding DoS; some operators still combine always-on infrastructure with jamming defenses.

			Slot jamming is especially cheap when the attacker uses the minimum HTLC size the peer will accept. A few hundred tiny payments can exhaust the 483-slot budget while locking little of the attacker's capital. Liquidity jamming instead pushes large amounts through a target hop so that hop cannot forward other value even if slots remain. Long CLTV expiry deltas lengthen the hold window and increase the damage per jam.

	== See also ==		== See also ==

NotATether: Create Channel jamming stub (LN liquidity/slot DoS)

2026-09-12T04:13:23Z

Create Channel jamming stub (LN liquidity/slot DoS)

New page

'''Channel jamming''' is a denial-of-service attack on the [[Lightning Network]] in which an adversary occupies channel liquidity, pending-payment slots, or both, so that honest payments cannot be forwarded. The attacker can often recover the funds used in the attack after a delay and pay little or no forwarding fee, because a failed [[Hash Time Locked Contracts|HTLC]] does not produce a success fee.

Each Lightning channel can hold only a limited number of in-flight HTLCs (483 is the usual maximum) and a limited amount of value in those HTLCs. While an HTLC is pending, the corresponding outbound balance and slot cannot be used for other payments. HTLCs are designed to wait on the order of hours because each hop needs a [[Timelock|timelock]] gap that covers worst-case on-chain confirmation.

In 2015 this property was described as a loop attack: an attacker routes a payment to itself over many hops and delays settlement, so the same funds lock many times their value along the path. The attack is often split into liquidity jamming (occupying value along a path) and slot jamming (filling pending-payment slots with small HTLCs). The two forms can be combined. No Bitcoin consensus change is required; the attack uses existing HTLC and onion-routing rules.

The attacker constructs an onion-routed payment whose destination is itself or a colluding node, or whose final hop will fail after holding the HTLC. Intermediate nodes forward according to BOLT 4 and wait for a preimage, a failure, or the deadline. During that wait, honest traffic that needs those slots or that liquidity is rejected. Because onion routing hides the destination, a forwarding node cannot tell a jammer from an ordinary slow payment. Reputation based on node identity is weak: an attacker can open many cheap channels and discard a peer identity after it is down-ranked.

Proposed mitigations (none a deployed network-wide standard) include upfront or hold fees so occupying a path has a cost, local reputation or HTLC endorsement, fidelity bonds against cheap Sybil identities, and local rate limits outside the BOLT specification. [[Watchtower]]s address on-chain cheat detection, not forwarding DoS; some operators still combine always-on infrastructure with jamming defenses.

== See also ==
* [[Lightning Network]]
* [[Hash Time Locked Contracts]]
* [[Timelock]]
* [[Watchtower]]
* [[Lightning service provider]]

== External links ==
* [https://bitcoinops.org/en/topics/channel-jamming-attacks/ Bitcoin Optech: Channel jamming attacks]
* [https://eprint.iacr.org/2022/1454 Unjamming Lightning: A Systematic Approach (IACR ePrint 2022/1454)]
* [https://github.com/lightningequipment/circuitbreaker Circuit Breaker]

[[Category:Technical]]