ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2020-02-28 đź“ť Original message: Good morning Gleb, > In ...
đź“… Original date posted:2020-02-28
đź“ť Original message:
Good morning Gleb,
> 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.Â
A concern I have been ruminating upon for a good while already is that dynamic fee-bumping violates Initiator Pays.
Suppose I have a permanent LN node somewhere on the network.
Then I trivially make up a completely-new identity and fund a channel to your node, over Tor.
Then I transfer out as much of those funds as possible to my permanent LN node.
Afterwards, after creating a signature from your commitment transaction, spending the `to_remote` (i.e. mine, as the commitment transaction is yours), I burn the private keys for the temporary alias and disconnect from you.
This leaves you with a channel containing a chunk of your funds in an illiquid dead-end channel and you are forced to eventually close the channel unilaterally.
It seems to me that the reserve system, plus the fact that channel-funder-pays-closing-fee, helps deter against the above attack, since I have to (1) leave a little of my money in the channel (reserve) and this is as well reduced by (2) since I am the original channel funder I am forced to pay for the closing fee on the unilateral close as well.
Removing the channel-funder-pays-closing-fee (i.e. adding dynamic pay-for-your-own-close) worries me as it seems to reduce the cost of this attack.
Though the attack remains costly, as I still have to pay for onchain fees to establish the channel in the first place, and is the reason why I cannot find myself bringing this up otherwise.
If onchain feerates rise quickly, then you should really consider dropping the channel onchain if I am offline, so as to not have the feerate *too* obsolete.
Unfortunately due to feerate disagreements this behavior has a lot of leeway in current implementations, as otherwise feerate changes tend to make the LN drop channels across the network, especially between different implementations (which tend to use slightly different feerate estimations / heuristics).
>
> 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.
I suggest that a node that has been online for a good amount of time, that is still connected to you and has been willing to sign fee updates, and has other published channels as well, would probably be better given some leeway and should not be dropped as easily as some unknown node with bad uptime and low liquidity.
>
> 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.
If the spend of the channel funding output is valid, then the miner has to somehow have access to one or more closing transactions of that channel in order to put them in an otherwise-invalid block.
Even if a BIP157 server lies and claims that a block at blockheight N spends your channel, you can download that block and check that it contains a transaction that does spend your channel.
Even if the place where you downloaded that block lies, it somehow had to have access to *some* transaction that spends your channel funding output, and is a *valid* spend of that output, and if you did not broadcast that transaction yourself, it must have come from your counterparty (only the two of you working together can make a valid spend of the funding output), in which case dropping the channel onchain would be the correct behavior, whether the block itself is valid or not: if somebody released a valid spend of the channel funding output you should presume that you did not do this yourself (else you would know about it) and therefore either your counterparty wants to close, is malicious, or is compromised (or you are amnesiac....).
Unless I misunderstand something?
>
> 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.
"beyond UX" yet if the UX is bad, nobody will use the software.
> 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
My understanding is that the pay-your-own-commitment spec is still in-flux, unless you mean some other mechanism?
Regards,
ZmnSCPXj
đź“ť Original message:
Good morning Gleb,
> 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.Â
A concern I have been ruminating upon for a good while already is that dynamic fee-bumping violates Initiator Pays.
Suppose I have a permanent LN node somewhere on the network.
Then I trivially make up a completely-new identity and fund a channel to your node, over Tor.
Then I transfer out as much of those funds as possible to my permanent LN node.
Afterwards, after creating a signature from your commitment transaction, spending the `to_remote` (i.e. mine, as the commitment transaction is yours), I burn the private keys for the temporary alias and disconnect from you.
This leaves you with a channel containing a chunk of your funds in an illiquid dead-end channel and you are forced to eventually close the channel unilaterally.
It seems to me that the reserve system, plus the fact that channel-funder-pays-closing-fee, helps deter against the above attack, since I have to (1) leave a little of my money in the channel (reserve) and this is as well reduced by (2) since I am the original channel funder I am forced to pay for the closing fee on the unilateral close as well.
Removing the channel-funder-pays-closing-fee (i.e. adding dynamic pay-for-your-own-close) worries me as it seems to reduce the cost of this attack.
Though the attack remains costly, as I still have to pay for onchain fees to establish the channel in the first place, and is the reason why I cannot find myself bringing this up otherwise.
If onchain feerates rise quickly, then you should really consider dropping the channel onchain if I am offline, so as to not have the feerate *too* obsolete.
Unfortunately due to feerate disagreements this behavior has a lot of leeway in current implementations, as otherwise feerate changes tend to make the LN drop channels across the network, especially between different implementations (which tend to use slightly different feerate estimations / heuristics).
>
> 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.
I suggest that a node that has been online for a good amount of time, that is still connected to you and has been willing to sign fee updates, and has other published channels as well, would probably be better given some leeway and should not be dropped as easily as some unknown node with bad uptime and low liquidity.
>
> 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.
If the spend of the channel funding output is valid, then the miner has to somehow have access to one or more closing transactions of that channel in order to put them in an otherwise-invalid block.
Even if a BIP157 server lies and claims that a block at blockheight N spends your channel, you can download that block and check that it contains a transaction that does spend your channel.
Even if the place where you downloaded that block lies, it somehow had to have access to *some* transaction that spends your channel funding output, and is a *valid* spend of that output, and if you did not broadcast that transaction yourself, it must have come from your counterparty (only the two of you working together can make a valid spend of the funding output), in which case dropping the channel onchain would be the correct behavior, whether the block itself is valid or not: if somebody released a valid spend of the channel funding output you should presume that you did not do this yourself (else you would know about it) and therefore either your counterparty wants to close, is malicious, or is compromised (or you are amnesiac....).
Unless I misunderstand something?
>
> 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.
"beyond UX" yet if the UX is bad, nobody will use the software.
> 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
My understanding is that the pay-your-own-commitment spec is still in-flux, unless you mean some other mechanism?
Regards,
ZmnSCPXj