|
| 1 | +--- |
| 2 | +title: Expiration floods |
| 3 | + |
| 4 | +## Optional. Shorter name to use for reference style links e.g., "foo" |
| 5 | +## will allow using the link [topic foo][]. Not case sensitive |
| 6 | +# shortname: foo |
| 7 | + |
| 8 | +## Optional. An entry will be added to the topics index for each alias |
| 9 | +aliases: |
| 10 | + - Forced expiration spam |
| 11 | + - Flood and loot |
| 12 | + |
| 13 | +## Required. At least one category to which this topic belongs. See |
| 14 | +## schema for options |
| 15 | +categories: |
| 16 | + - Contract Protocols |
| 17 | + - Lightning Network |
| 18 | + - Security Problems |
| 19 | + - Security Enhancements |
| 20 | + |
| 21 | +## Optional. Produces a Markdown link with either "[title][]" or |
| 22 | +## "[title](link)" |
| 23 | +primary_sources: |
| 24 | + - title: "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" |
| 25 | + link: https://lightning.network/lightning-network-paper.pdf |
| 26 | + |
| 27 | + - title: "Flood & Loot: A Systemic Attack On The Lightning Network" |
| 28 | + link: https://arxiv.org/abs/2006.08513 |
| 29 | + |
| 30 | +## Optional. Each entry requires "title" and "url". May also use "feature: |
| 31 | +## true" to bold entry and "date" |
| 32 | +optech_mentions: |
| 33 | + - title: LN developer discussion about flood and loot attacks |
| 34 | + url: /en/newsletters/2020/08/05/#chicago-meetup-discussion |
| 35 | + |
| 36 | + - title: Concern about forced expiration spam in very large channel factories |
| 37 | + url: /en/newsletters/2023/09/27/#using-covenants-to-improve-ln-scalability |
| 38 | + |
| 39 | + - title: Mitigating expiration floods with fee-depedent timelocks |
| 40 | + url: /en/newsletters/2024/01/03/#fee-dependent-timelocks |
| 41 | + |
| 42 | +## Optional. Same format as "primary_sources" above |
| 43 | +see_also: |
| 44 | + - title: HTLCs |
| 45 | + link: topic htlc |
| 46 | + |
| 47 | + - title: PTLCs |
| 48 | + link: topic ptlc |
| 49 | + |
| 50 | +## Optional. Force the display (true) or non-display (false) of stub |
| 51 | +## topic notice. Default is to display if the page.content is below a |
| 52 | +## threshold word count |
| 53 | +#stub: false |
| 54 | + |
| 55 | +## Required. Use Markdown formatting. Only one paragraph. No links allowed. |
| 56 | +## Should be less than 500 characters |
| 57 | +excerpt: > |
| 58 | + **Expiration floods** occur when many timelock-contingent payments |
| 59 | + need to be settled onchain within a limited period of time. If not |
| 60 | + all of the settlement transactions can fit into blocks before |
| 61 | + timelocks begin expiring, then not all of the contingent payments will |
| 62 | + resolve as expected, likely resulting in some users losing money. |
| 63 | +
|
| 64 | +--- |
| 65 | +For example, Mallory runs a very popular LN node with many users. Each |
| 66 | +channel has the maximum-allowed number of incoming and outgoing pending |
| 67 | +[HTLCs][topic htlc], making the cost to resolve each of those channels |
| 68 | +onchain around 100,000 vbytes. A full block can only fit about 10 of |
| 69 | +those channels. If the most critical [timelocks][topic timelocks] on |
| 70 | +some of the HTLCs might expire in 10 blocks or less, Mallory can force |
| 71 | +close more than 100 of those channels to eliminate the guarantee that |
| 72 | +her honest counterparties will receive their money. |
| 73 | + |
| 74 | +Although an expiration flood can be triggered deliberately by a |
| 75 | +malicious counterparty, it can also happen accidentally either by |
| 76 | +coincidence or by a situation that causes many users to attempt to close |
| 77 | +their channels simultaneously, e.g. a bug in a software implementation. |
| 78 | +In the accidental case, some honest users will get their money and other |
| 79 | +honest users may not, even though they all followed the protocol |
| 80 | +correctly. |
| 81 | + |
| 82 | +Expiration floods were described in the original [Lightning Network |
| 83 | +paper][] under the name **forced expiration spam**. A later |
| 84 | +[paper][flood and loot] called the attack **flood and loot**. Concern |
| 85 | +about expiration floods has heavily influenced the development of LN and |
| 86 | +other offchain protocols. |
| 87 | + |
| 88 | +Mitigations that don't require consensus changes include: |
| 89 | + |
| 90 | +- **Minimizing onchain enforcement data:** designing protocols and |
| 91 | + setting limits so that timelock-contingent payments are small. For |
| 92 | + example, many LN implementations default to accepting and creating |
| 93 | + much less than the protocol-allowed maximum number of pending HTLCs. |
| 94 | + (That also helps mitigate other attacks.) |
| 95 | + |
| 96 | +- **Using long timelocks when possible:** in our example above, Mallory |
| 97 | + needs to close at least 100 channels with 10-block timelocks. If the |
| 98 | + timelocks were 100 blocks, she'd need to close 1,000 channels |
| 99 | + simultaneously. It would take more effort on her part to find that |
| 100 | + many victims and get their channels into an exploitable state. |
| 101 | + |
| 102 | +- **Improving counterparty decentralization:** someone who is a |
| 103 | + counterparty to 100 users has more power to execute an expiration |
| 104 | + flood attack than someone who is only counterparty to 10 users. |
| 105 | + This suggests that a less centralized distribution of counterparties |
| 106 | + might be safer against deliberately triggered expiration floods. |
| 107 | + Of course, in privacy-protecting protocols, it may be impossible to |
| 108 | + prove that two counterparties are distinct entities and not colluding. |
| 109 | + |
| 110 | +Proposed mitigations that require consensus changes include: |
| 111 | + |
| 112 | +- **Dynamic bounded block sizes:** this would allow miners to create larger |
| 113 | + blocks during high periods of demand so that they can confirm more |
| 114 | + transactions during an expiration flood. [Proposals][friedenbach |
| 115 | + dynamic] of this [nature][maxwell dynamic] |
| 116 | + usually require miners to pay a cost for creating higher blocks, such |
| 117 | + as destroying bitcoins or generating more proof of work. The lost |
| 118 | + bitcoins and work are expected to be compensated for by the extra fee |
| 119 | + income they will receive from confirming urgent transactions. |
| 120 | + |
| 121 | +- **Fee-dependent timelocks:** [this][fdt] would prevent a timelock from |
| 122 | + expiring when feerates were above a specified amount. If too many |
| 123 | + timelock-contingent payments entered the mempool at once; the users |
| 124 | + would bid up their feerates in competition with each other to get |
| 125 | + their transactions confirmed before the regular timelocks expired. |
| 126 | + When feerates exceeded the fee-dependent timelock, expiration of those |
| 127 | + timelocks would be delayed, keeping those users safe until feerates |
| 128 | + reduced. As long as the user paid a feerate above their fee-dependent |
| 129 | + timelock amount, their transaction should confirm before the timelock |
| 130 | + expires, ensuring the user's desired transaction gets confirmed before |
| 131 | + the timelock expires. |
| 132 | + |
| 133 | +{% include references.md %} |
| 134 | +{% include linkers/issues.md issues="" %} |
| 135 | +[lightning network paper]: https://lightning.network/lightning-network-paper.pdf |
| 136 | +[flood and loot]: https://arxiv.org/abs/2006.08513 |
| 137 | +[friedenbach dynamic]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html |
| 138 | +[maxwell dynamic]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html |
| 139 | +[fdt]: /en/newsletters/2024/01/03/#fee-dependent-timelocks |
0 commit comments