public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Date: Tue, 17 Oct 2023 02:11:20 +0100	[thread overview]
Message-ID: <CALZpt+GsRfHvABjhkX=eN_1viVw8Jos4=+sBd7vWQJ_VxNta8g@mail.gmail.com> (raw)
In-Reply-To: <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

> 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 <pete@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.
>

[-- Attachment #2: Type: text/html, Size: 3196 bytes --]

  parent reply	other threads:[~2023-10-17  1:11 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16 16:57 Antoine Riard
2023-10-16 19:13 ` Peter Todd
2023-10-16 22:10   ` Matt Morehouse
2023-10-17  1:11   ` Antoine Riard [this message]
2023-10-20 10:47     ` Peter Todd
2023-10-20 11:18       ` Jochen Hoenicke
2023-10-16 22:51 ` Olaoluwa Osuntokun
2023-10-17  7:21 ` [bitcoin-dev] [Lightning-dev] " ziggie1984
2023-10-17 10:34   ` ZmnSCPxj
2023-10-17 18:34     ` Antoine Riard
2023-10-20 10:31     ` Peter Todd
2023-10-20 11:03       ` Peter Todd
2023-10-20 18:35         ` Matt Morehouse
2023-10-20 21:05           ` Matt Corallo
2023-10-21  0:15             ` Peter Todd
2023-10-21  1:03               ` Matt Corallo
2023-10-21  1:25                 ` Peter Todd
2023-10-21  1:55                   ` Matt Corallo
2023-10-21  2:43                     ` Peter Todd
2023-10-23 16:09                       ` Matt Corallo
2023-10-17 17:47   ` Antoine Riard
2023-10-17 18:47     ` Antoine Riard
2023-10-18  0:17 ` Matt Corallo
2023-10-18  2:57   ` Antoine Riard
2023-10-19  8:12     ` Bastien TEINTURIER
2023-10-19 16:23   ` Matt Morehouse
2023-10-19 17:22     ` Antoine Riard
2023-10-19 17:53       ` Matt Morehouse
2023-10-19 19:33         ` Antoine Riard
2023-10-21  0:18           ` Olaoluwa Osuntokun
2023-11-17 22:36             ` Antoine Riard
2023-10-19 18:02     ` Matt Corallo
2023-10-20  6:56 ` [bitcoin-dev] " Antoine Riard
2023-10-21 20:05   ` Antoine Riard
2023-10-27  0:43     ` Peter Todd
2023-11-02  4:46     ` Antoine Riard
2023-10-21  0:09 ` [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd
2023-10-21  8:58   ` David A. Harding
2023-10-21 10:31     ` Peter Todd
2023-10-22  8:30   ` vjudeu
2023-10-23 11:10   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-10-23 15:45     ` Peter Todd
2023-11-02  5:24   ` [bitcoin-dev] " Antoine Riard
2023-11-02  6:26     ` Peter Todd
2023-11-02 17:07       ` Matt Morehouse
2023-11-03  5:27         ` Antoine Riard
2023-11-03  5:25       ` Antoine Riard
2023-11-04  7:26         ` Peter Todd
2023-11-06 18:45           ` Antoine Riard
2023-11-07 11:11             ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-11-07 15:44               ` Antoine Riard
2023-11-08  0:51             ` [bitcoin-dev] " Peter Todd
2023-11-08  2:06               ` Peter Todd
2023-11-13  2:18                 ` Antoine Riard
2023-11-14 19:50                   ` Peter Todd
     [not found]                     ` <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
2023-11-15 17:53                       ` [bitcoin-dev] Fwd: " Antoine Riard
2023-10-22  4:49 ` [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi
2023-10-23  8:49   ` David A. Harding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALZpt+GsRfHvABjhkX=eN_1viVw8Jos4=+sBd7vWQJ_VxNta8g@mail.gmail.com' \
    --to=antoine.riard@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=pete@petertodd$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox