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, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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 this PR to bitcoin core (c.f. > https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it > correctly with that we could always have low fees and ask the person who want > to claim their outputs to pay fees. This excludes overpayment and could > happen at a later stage when fees are not spiked. Still the victim who > offered the htlcs would have to spend those outputs at some time. > 3. Don't overpay fees in commitment transactions. We can't foresee the future > anyway 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). As a rough sketch, a client contacts a fee insurance service. For a fixed fee, the client arranges such that the fee insurance service pays for fees in case of a condition where feerates increase. This is done by arranging a 2-of-2 output spending the insurance premium payment and some maximum fee the insurance service provides. Initially sign an `nLockTime`d transaction that represents the end of the insurance service contract. Then at each commitment tx, sign a variety of feerates spending the CPFP carve-out and the insurance 2-of-2, utilizing the insurnace funds for doing the CPFP. > 4. Don't add htlcs for which the on chain fee is higher than the HTLCs value > (like we do with sub dust amounts and sub satoshi amounts. This would at > least make the attack expensive as the attacker would have to bind a lot of > liquidity. Seems a reasonable heuristic. > 5. Somehow be able to aggregate htlc's. In a world where we use payment > points instead of preimages we might be able to do so. It would be really > cool if separate HTLC's could be combined to 1 single output. I played around > a little bit but I have not come up with a scheme that is more compact in all > cases. Thus I just threw in the idea. This seems impossible; once you add the points of two unrelated PTLCs, in order to separate them again once you learn the aggregate scalar, you need to learn the scalar of one separately from the scalar of the other, but the aggregate PTLC does not impose the requirement from the receiver to reveal each of the scalars separately. You *could* require multiple signatures instead of a single signature, in which case each completed signature can reveal a separate scalar behind a point. Revealing the points and the signatures is 96 bytes, plus a few more bytes for opcodes, divided by 4 because witness, so about equivalent to 24 block space per PTLC you merge. This cost would be paid by the receiver of the HTLC. The timelock branch can be made not to have to reveal any of the points, by Taproot-signing the timelock branch, or using a separate tapscript (at the cost of additional 32 witness bytes to select branches, if my taproot understanding holds). -- Combining timelocks is also bad. If you combine two PTLCs with different timelocks, which do you choose, the larger or the smaller? * If you choose the larger, the sender of the PTLCs could have a larger outgoing timelock than the its incoming PTLC, then possibly might lose money when the incoming PTLC times out but the outgoing timelock is not yet timed out and can still be claimed by scalar revelation. * If you choose the smaller, then the next hop might not have enough block time to deliver the payment, in which case later hops on the route will fail more often (possibly an acceptable tradeoff? c-lightning does shadow routing which overallocates timelock anyway...). * If you cannot combine different timelocks, the attacker can arrange PTLCs with timelocks from now+2 to now+484 to mount the attack. -- You could try aggregating using `OP_CHECKTEMPLATEVERIFY`, or equivalently with a pre-signed transaction, but that just moves the revelation cost to the receiver of the PTLC, which multiple signatures above does just as well. It does have the advantage of retaining the timelocks. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[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). This attack is similar to the one that was possible with tx malleability on the funding transaction without the segwit upgrade (c.f. https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf&page=126). Meaning an attacker can force a victim to lose money and use this fact to blackmail the victim, to potentially gain / steal some of the lost funds. TL;DR: = * Depending on the circumstances this attack allows an attacker to make channel partners lose a substantial amount of BTC without substantial costs for the attacker. * Depending on the exact circumstances this could be for example ~0.15 BTC. In particular it demonstrates why opening a channel is not an entirely trustless activity. * The attacker will reliably only be able to force the victim to lose this amount of Bitcoin. * It is not clear how in practice the attacker could gain this amount or parts of it as this would involve not only game theory but also rather quick communication between attacker and victim and customized Lightning nodes which at least for the victim would be unlikely to exist. * None of the suggested fixes seems to be satisfying though the current solution of lowering the maximum amount of HTLCs that can concurrently be in flight seems to be a reasonable start for now. Timeline on Disclosure = I have disclosed this attack on Sunday July 21st 2019 to Fabrice Drouin (and shortly after to Christian Decker) in a phone call who in turn has discussed it with people from the other implementations. From his feedback I understood that people working on implementations have been more or less aware of the possibility of this attack. Fabrice also mentioned that he believed implementations currently try to mitigate this by setting low limits of allowed / accepted HTLCs in flight. However at that time this was only true for e-clair. It is now also true for c-lightning and as far as I know still not true for lnd. Fabrice said that the people he talked to have suggested that I should eventually describe the attack in public to raise awareness (also from the group of node operators) for the problems related to this attack. He also suggested that - if I wanted to - I should update the rfc with recommendations and warnings. While I already have in mind how to change the rfc I wanted to start the discussion first. Maybe some people find better fixes than just a warning that I have in mind. So far I didn't do anything because I wanted to also give lnd the chance to handle the problem. There are two reasons I disclose this attack today: 1.) I think almost 1 year is enough time to do something about it. The only implementation that afaik didn't yet is lnd (see below) but I got roasbeefs ok last week to go ahead and publish the attack anyway so that we can have a broader discussion on mitigation strategies. 2.) The attack seems actually very similar to the one described in the "Flood & Loot: A Systemic Attack On The Lightning Network" - paper which came out 2 days ago (c.f.: https://arxiv.org/abs/2006.08513 ). I believe any person reading that paper will understand the possibility of the attack that I describe anyway so I believe it is now more or less public anyway and thus time for an open / public discussion. The main difference between the two attacks (if I understand this novel paper correctly) is: In the "flood and loot"-attack one tries to steal the HTLC output of the victims. Where in the "flood and blackmail"-attack that I describe I try to to force the victim to lose almost all its funds due to high on chain fees (Which I could use to blackmail the victim) Description of the attack === Let us assume the victim has funded a channel with an attacker meaning it will have to pay the fees for the commitment transaction in case of a force close. During a fee spike (let us assume fee estimators suggest 150 sat / byte) the attacker spams this channel with the maximum possible amount of HTLCs that the protocol allows. The HTLCs can be of a small value but need to be bigger than the dust limit so that additional outputs are actually added to the commitment transaction which makes it quite large in Bytes. According to the BOLTs these are 483 additional outputs to the commitment transaction. The direction of HTLCs are chosen so that the amount is taken from the `to_remote` output of the attacker (obviously on the victims side it will be the `to_local` output) For the actual attack it does not matter in which direction the HTLCs are spammed but economically the direction I propose makes even more sense for the atta
