Gleb Naumenko [ARCHIVE] on Nostr: đź“… Original date posted:2020-02-26 đź“ť Original message: In this email, myself ...
đź“… Original date posted:2020-02-26
đź“ť Original message:
In this email, myself (gleb) and ariard want to discuss some aspects of the LN implementations when it comes to massive channel closing.
LN security model relies on the unilateral capability to timely confirm on-chain commitment transaction. Currently, fee rates of both commitment transaction and HTLC-timeout/HTLC-Success are pre-committed at signatures and can be interactively updated with a `update_fee` message. In case of mempool fee rates surge and a counterparty being adversarial or irresponsive (by being offline by occasion or under attack), this mechanism isn’t reliable because a low-fee rate commitment transaction may never make it into network mempools. Switching to automatic single-party dynamic fee-bumping of *their* commitment transaction via CPFP/package relay would solve this issue, while potentially opening new attack vectors.
If dynamic fee-bumping is used by a significant fraction of LN nodes, this security measure may be exploited by a miner, a massive LN channels closing would choke the mempool, dynamic fee-bumpers would react in consequence and fee rates raise to the roof. Miners would harvest abnormal high-fees for multiple blocks.
A massive channel closing may be provoked by feeding an invalid block to light clients (in the BIP157 paradigm), as they don’t have utxo access, they can’t verify input signatures (note: the only utxo spend they can check is the funding_output and they should do so) and lead to think than their channel is closed. This may provoke a spurious broadcast of their local commitment transaction, this one being valid and propagating on the base layer. Even if an invalid block isn’t fetched, the secure strategy on what to do when your chain view is messed up by an attacker is still an open question. Note that one invalid block may be used to force-close multiple channels, making this attack more economically feasible.
Another attack building block could be to exploit any LN protocol/implementation vulnerability like a malicious HTLC-of-death which would provoke honest parties to close their mutual channel when routed through [0]
LN light clients should disable HTLC routing and avoid any aggressive fee-bumping for a broadcast of local commitment transactions as time-sensitivity doesn’t matter in this case beyond UX and funds stuck in-flight.
Bounding dynamic-fees engine may be viewed as a game-theoretic aspect between LN parties (burn the maximum in fee rate to avoid an attacker to make any profit) and macro-considerations (prevent miner to exploit the whole LN network, conservative mempool/resources usage).
Considering that most of the block reward is currently subsidized, the incentives for miners to launch this attack are questionable. However, this might change when the fraction of fees in the reward becomes higher.
As LN becomes an important part of the Bitcoin ecosystem, it’s important to acknowledge the mining-related incentives and risks, as these may at the end be used to influence protocol development.
Since the LN infrastructure seems to be moving towards the heavy use of light clients, and the attacks we mentioned are expected to appear again (at least in some of the implementations), we believe it’s important to understand the mechanics of these attacks and countermeasures.
It would be interesting to have an empirical study (based on the historical data) and a simulation of the fee spikes, with parameterized:
- how many channels are vulnerable to force-closing (based on the particular LN implementations)
- what are the properties of those channels (amount, timelocks)
- what is the distribution of those channels across nodes
- how many nodes implement dynamic bumping
- mining reward allocation
What are your opinions on these issues?
– gleb
[0] One example with this RL issue:
(https://github.com/rust-bitcoin/rust-lightning/pull/513)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200226/d529ce9f/attachment-0001.html>;
đź“ť Original message:
In this email, myself (gleb) and ariard want to discuss some aspects of the LN implementations when it comes to massive channel closing.
LN security model relies on the unilateral capability to timely confirm on-chain commitment transaction. Currently, fee rates of both commitment transaction and HTLC-timeout/HTLC-Success are pre-committed at signatures and can be interactively updated with a `update_fee` message. In case of mempool fee rates surge and a counterparty being adversarial or irresponsive (by being offline by occasion or under attack), this mechanism isn’t reliable because a low-fee rate commitment transaction may never make it into network mempools. Switching to automatic single-party dynamic fee-bumping of *their* commitment transaction via CPFP/package relay would solve this issue, while potentially opening new attack vectors.
If dynamic fee-bumping is used by a significant fraction of LN nodes, this security measure may be exploited by a miner, a massive LN channels closing would choke the mempool, dynamic fee-bumpers would react in consequence and fee rates raise to the roof. Miners would harvest abnormal high-fees for multiple blocks.
A massive channel closing may be provoked by feeding an invalid block to light clients (in the BIP157 paradigm), as they don’t have utxo access, they can’t verify input signatures (note: the only utxo spend they can check is the funding_output and they should do so) and lead to think than their channel is closed. This may provoke a spurious broadcast of their local commitment transaction, this one being valid and propagating on the base layer. Even if an invalid block isn’t fetched, the secure strategy on what to do when your chain view is messed up by an attacker is still an open question. Note that one invalid block may be used to force-close multiple channels, making this attack more economically feasible.
Another attack building block could be to exploit any LN protocol/implementation vulnerability like a malicious HTLC-of-death which would provoke honest parties to close their mutual channel when routed through [0]
LN light clients should disable HTLC routing and avoid any aggressive fee-bumping for a broadcast of local commitment transactions as time-sensitivity doesn’t matter in this case beyond UX and funds stuck in-flight.
Bounding dynamic-fees engine may be viewed as a game-theoretic aspect between LN parties (burn the maximum in fee rate to avoid an attacker to make any profit) and macro-considerations (prevent miner to exploit the whole LN network, conservative mempool/resources usage).
Considering that most of the block reward is currently subsidized, the incentives for miners to launch this attack are questionable. However, this might change when the fraction of fees in the reward becomes higher.
As LN becomes an important part of the Bitcoin ecosystem, it’s important to acknowledge the mining-related incentives and risks, as these may at the end be used to influence protocol development.
Since the LN infrastructure seems to be moving towards the heavy use of light clients, and the attacks we mentioned are expected to appear again (at least in some of the implementations), we believe it’s important to understand the mechanics of these attacks and countermeasures.
It would be interesting to have an empirical study (based on the historical data) and a simulation of the fee spikes, with parameterized:
- how many channels are vulnerable to force-closing (based on the particular LN implementations)
- what are the properties of those channels (amount, timelocks)
- what is the distribution of those channels across nodes
- how many nodes implement dynamic bumping
- mining reward allocation
What are your opinions on these issues?
– gleb
[0] One example with this RL issue:
(https://github.com/rust-bitcoin/rust-lightning/pull/513)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200226/d529ce9f/attachment-0001.html>;