The honest HTLC-timeout is evicted out of the mempool.
How is this this an attack? The HTLC timeout is only supposed to be mined if the preimage is not available. If the preimage is available, the HTLC-timeout is the dishonest transaction, right?
reply
Unless you’re using the HTLC-preimage as a trick to block the confirmation of the “honest” HTLC-timeout until an inbound HTLC expires and double-spend the HTLC.
reply
You really have to explain this stuff better.
The way I would answer that question is to say that the party with the preimage does have the right to spend the output. But in this circumstance, they're deliberately delaying that spend long enough that the HTLC in the channel sending the funds times out first. In that circumstance spending the HTLC output with the preimage is no longer legitimate, as the node in the middle didn't get their money.
reply
Note the “flood and loot” paper is explicitly pointed out in the full disclosure mail post with a discussion of the lightning security model, where spending a HTLC output with a preimage on the outgoing link after the timelock on the incoming HTLC has expired is deemed as illegitimate.
Note, how the issue sounds to generalize to any “revoked” or “invalid” state in off-chain bitcoin protocols, where an attacker might be able to replace cycling package out of the mempool (assuming package relay support and deployment).
reply
From the link:
"From my understanding the following list of Bitcoin protocols and applications could be affected by new denial-of-service vectors under some level of network mempools congestion. Neither tests or advanced review of specifications (when available) has been conducted for each of them:
  • on-chain DLCs
  • coinjoins
  • payjoins
  • wallets with time-sensitive paths
  • peerswap and submarine swaps
  • batch payouts
  • transaction "accelerators""
Is this bad as I think it is?
reply
Ask all the other developers which are listed in the full disclosure.
reply
I was spooked for a second. LND only recently released v0.17. Roasbeef followed up:
One small clarification: all of lnd's relevant mitigations were in place by lnd v0.16.1-beta [1], which was released on April 24th 2023. Since then we've fixed some performance regressions introduced due to some of the mitigations (mempool watching), and in 0.17.1 we'll start to use the new gettxspendingprevout RPC call with bitcoind to further reduce load.
reply
He's got multiple things wrong here. Ldk was also apparently fixed a while back. The version it says in the mailing list isn't even out yet.
reply
Here to answer your questions on what I get wrong.
To the best of my knowledge you never contributed to low-level lightning parts.
I”ll maintain the LDK version number is correct, has been communicated to me privately last Friday by a LDK maintainers and there is currently more hardening under ways
reply
deleted by author
reply
Thanks no thanks for the spook accusation. This is insulting.
Warned for years people the mempool was a bedrock of security issues for L2s: https://github.com/ariard/L2-zoology
reply
I wasn't accusing you of anything! I, me, myself was spooked! I was afraid I was running an effected version of LND.
No offense intended. I'm sorry if my statement wasn't clear. I don't qualify as a critic on this issue, so I would never criticize you on it.
reply
See Laolu comment on the mailing list about LND.
This is always unclear with coordinated disclosure if you give the latest release number (where mitigations are included) or the ones where they have been effectively included. Latest release number might always have some minor bugs.
Thanks for the work you’re doing on stacker.news.
reply