pull down to refresh
120 sats \ 3 replies \ @anon 17 Oct 2023
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
0 sats \ 2 replies \ @theariard 17 Oct 2023
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.
See 2.3 of https://arxiv.org/pdf/2006.08513.pdf
reply
0 sats \ 1 reply \ @petertodd 22 Oct 2023
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
0 sats \ 0 replies \ @theariard 30 Oct 2023
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
10 sats \ 1 reply \ @newnym 17 Oct 2023
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
388 sats \ 0 replies \ @theariard 17 Oct 2023 freebie
Ask all the other developers which are listed in the full disclosure.
reply
10 sats \ 6 replies \ @k00b 16 Oct 2023
I was spooked for a second. LND only recently released v0.17. Roasbeef followed up:
reply
388 sats \ 2 replies \ @TonyGiorgio 16 Oct 2023
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
388 sats \ 1 reply \ @theariard 17 Oct 2023 freebie
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
100 sats \ 0 replies \ @TonyGiorgio 17 Oct 2023
deleted by author
reply
0 sats \ 2 replies \ @theariard 17 Oct 2023
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
100 sats \ 1 reply \ @k00b 17 Oct 2023
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
2489 sats \ 0 replies \ @theariard 18 Oct 2023
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