Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Yes -- to be clear, most of the feature-wise benefits of CTV for Lightning are only in the initial channel setup phase, lessening interactivity requirements. Everything else can be emulated via multisig layers, but that can add substantial latency in doing either 2pECDSA for each layer or on chain

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

On Sun, Jun 21, 2020 at 06:09:28PM -0700, Olaoluwa Osuntokun wrote: > IMO this is mostly mitigated by anchor commitments. The impact of this > attack is predicated on the "victim" paying 5x on-chain fees (for their > confirmation target) to sweep all their HTLCs. I think the attack is more clea

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Hi Jeremy, The up-front costs can be further mitigated even without something like CTV (which makes things more efficient) by adding a layer of in-direction w.r.t how HTLCs are manifested within the commitment transactions. To do this, we add a new 2-of-2 multi-sig output (an HTLC indirect block)

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Hi Rene, IMO this is mostly mitigated by anchor commitments. The impact of this attack is predicated on the "victim" paying 5x on-chain fees (for their confirmation target) to sweep all their HTLCs. Anchor commitments let the initiator of the channel select a very low starting fee (just enough t

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Good morning Jeremy, > My understanding is that you can use the CTV deferral to also get independent > HTLC relative timelocks start points per output. This would help with this > sort of issue right? > > And you're correct that there's overhead of indirection, but it's not super > large (minim

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Hi ZmnSCPxj, My understanding is that you can use the CTV deferral to also get independent HTLC relative timelocks start points per output. This would help with this sort of issue right? And you're correct that there's overhead of indirection, but it's not super large (minimally complicated somet

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Good morning Jeremy, > I am not steeped enough in Lightning Protocol issues to get the full design > space, but I'm fairly certain BIP-119 Congestion Control trees would help > with this issue. > > You can bucket a tree by doing a histogram of HTLC size, so that all small > HTLCs live in a comm

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

I am not steeped enough in Lightning Protocol issues to get the full design space, but I'm fairly certain BIP-119 Congestion Control trees would help with this issue. You can bucket a tree by doing a histogram of HTLC size, so that all small HTLCs live in a common CTV subtree and don't interfere w

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Hi Rene, Thanks for disclosing this vulnerability, I think this blackmail scenario holds but sadly there is a lower scenario. Both "Flood & Loot" and your blackmail attack rely on `update_fee` mechanism and unbounded commitment transaction size inflation. Though the first to provoke block conges

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Good morning all, > > Fee futures could help against this. > I remember writing about this some time ago but cannot find where (not sure > if it was in lightning-dev or bitcoin-dev). `harding` found it: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html Regards,

Re: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Good morning Rene, Thank you for the report, this is good. > 1. The current solution is to just not use up the max value of htlc's.  > Eclaire and c-lightning by default only use up to 30 htlcs. > 2. Probably the best fix (not sure if I understand the consequences > correctly) is coming from thi

[Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes

Hey everyone and of course good morning ZmnSCPxj (: about 11 months ago I discovered a potential blackmail attack with HTLCs after answering this question on stack exchange (c.f https://bitcoin.stackexchange.com/questions/89232/why-is-my-spendable-msat-much-lower-than-msatoshi-to-us/89235#89235).