> I think if you want people to understand this exploit, you need to explain in more detail how we have a situation where two different parties can spend the same HTLC txout, without the first party having the right to spend it via their knowledge of the HTLC-preimage.
If I'm correctly understanding your question, you're asking why we have a situation where the spend of a HTLC output can be in competition between 2 channel counterparties. LN commitment transactions have offered HTLC outputs where a counterparty Alice is pledging to her other counterparty Caroll the HTLC amount in exchange of a preimage (and Caroll signature). After the expiration of the HTLC timelock, if the HTLC has not been claimed on-chain by Caroll, Alice can claim it back with her signature (and the pre-exchanged Caroll signature). The exploit works actually in Caroll leveraging her HTLC-preimage transaction as a replace-by-fee of Alice's HTLC-timeout _after_ the expiration of the timelock, the HTLC-preimage transaction staying consensus valid. There is nothing in the mempool policy rules that prevent this Caroll's HTLC-preimage of being replaced subsequently, once Alice's HTLC-timeout has been evicted out the mempool. The HTLC output does not have any spend candidate remaining for this block. If this replacement can be successfully repeated until an inbound HTLC on another Alice's channel expires, the "forward" HTLC can be double-spent. Le lun. 16 oct. 2023 à 20:13, Peter Todd <p...@petertodd.org> a écrit : > > > On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >(cross-posting mempool issues identified are exposing lightning chan to > >loss of funds risks, other multi-party bitcoin apps might be affected) > > > >As the HTLC-preimage spends an unconfirmed input that was already included > >in the unconfirmed and unrelated child transaction (rule 2), pays an > >absolute higher fee of at least the sum paid by the HTLC-timeout and child > >transaction (rule 3) and the HTLC-preimage feerate is greater than all > >directly conflicting transactions (rule 6), the replacement is accepted. > >The honest HTLC-timeout is evicted out of the mempool. > > I think if you want people to understand this exploit, you need to explain > in more detail how we have a situation where two different parties can > spend the same HTLC txout, without the first party having the right to > spend it via their knowledge of the HTLC-preimage. >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
