pull down to refresh
120 sats \ 3 replies \ @anon 17 Oct 2023 \ on: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 bitcoin
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?
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
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