path: root/28/92addd2d23cec6f7cd964e0891a080b19e89c7

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B37C6C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 01:11:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 7C9ED4191D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 01:11:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7C9ED4191D
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=FpxtUFKM
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xtdCSXtoYES5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 01:11:33 +0000 (UTC)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
 [IPv6:2607:f8b0:4864:20::130])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 07F3C4190B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 17 Oct 2023 01:11:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 07F3C4190B
Received: by mail-il1-x130.google.com with SMTP id
 e9e14a558f8ab-35749078a59so21075235ab.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 16 Oct 2023 18:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697505092; x=1698109892;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=XGcQGN9+57vWq9FdjR0rPBuZJ3vIto8mMQt5AlrWm3k=;
 b=FpxtUFKMvT5mDUApyVPJyUf8s9c+xDTexON9TBk2D6xz8wduyyNYbzxU8+HhqFUz2L
 nT5o6tlAE8hH2A5DEJGmMHolmoh8r9TQL+s5fZBd8YgQlWukA+Gu50NRg2qxHp+T3Avv
 XfaudAhIlRDTmV1yoLXDDAOUcfvGQ5TBomtUCfhBb8Rz0v6smyiOcTGGL+SSESk9jIgt
 kx+kSK943/3c2AKF+7j0N1JhJ+D60CFag6f5RnbivIBHP/G6MN6kKu/nqz0qdALKepUa
 HywbS9n8p6Fqrx4kYYIf3SSZQWKsA/c2K780Rdfi6QAFNC6aszWs5GqAIBHqk91vsZot
 zxzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697505092; x=1698109892;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=XGcQGN9+57vWq9FdjR0rPBuZJ3vIto8mMQt5AlrWm3k=;
 b=HZ0BZh70/tcN0EekjeGw1oYIr2MYmw/cYn/fqEcyBiBnne2RS/3ZBRkQsViTKsf35y
 G7DxeofUZfZ6PzVjHY59qycD/v1ArIAhpx+ZEQVMYw04kCF+C4Y80XGD6CR1yFscpZ9Q
 8Q+mROqxYa0fTTVXFswGlsDnlqfFgwyUjcFbdccSvCUGXRexyM7zaEZN+IpvnWu86o8Z
 9M8RWnn0P3oegYM4OY+3SXeXbdRey4wwz3vd19PousyVOoLP4vnhfUkSpNxkWvAaVB3c
 y5JUFPqEF4rgEKzDkiubjZ0osrBIqvArfXkX1P9xiRupcki4+B2ZOa1It/EQ47KVf1nP
 9/lg==
X-Gm-Message-State: AOJu0YxsjfouBBOCetLgbppp3htawsrwvdgufzZFR4XJdBXbDyEEUfpv
 XYSPSc/bZkVz1f1N8wu8MpYP8dWvBKaMk5+fzxwLQ7MxlbuVpA==
X-Google-Smtp-Source: AGHT+IGg4u+qmZGchdcWtbfsSbE7Xq6opKwxSECF1ntnYqPiwEW0W2YwrBxRo5k4imBFK/hDMrt2SWqbQeseQqvzn7E=
X-Received: by 2002:a05:6e02:1d1a:b0:357:54d8:94f6 with SMTP id
 i26-20020a056e021d1a00b0035754d894f6mr1321660ila.3.1697505091970; Mon, 16 Oct
 2023 18:11:31 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org>
In-Reply-To: <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 17 Oct 2023 02:11:20 +0100
Message-ID: <CALZpt+GsRfHvABjhkX=eN_1viVw8Jos4=+sBd7vWQJ_VxNta8g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000002eae50607df349f"
X-Mailman-Approved-At: Tue, 17 Oct 2023 01:21:14 +0000
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"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2023 01:11:34 -0000

--00000000000002eae50607df349f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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 =C3=A0 20:13, Peter Todd <pete@petertodd.org> a =C3=A9=
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 includ=
ed
> >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 chi=
ld
> >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 explai=
n
> 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.
>

--00000000000002eae50607df349f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; I think if you want people to understand this exploit=
, you need to explain in more detail how we have a situation where two diff=
erent parties can spend the same HTLC txout, without the first party having=
 the right to spend it via their knowledge of the HTLC-preimage.<br><div><b=
r></div><div>If I&#39;m correctly understanding your question, you&#39;re a=
sking why we have a situation where the spend of a HTLC output can be in co=
mpetition between 2 channel counterparties.</div><div><br></div><div>LN com=
mitment transactions have offered HTLC outputs where a counterparty Alice i=
s pledging to her other counterparty Caroll the HTLC amount in exchange of =
a preimage (and Caroll signature).</div><div><br></div><div>After the expir=
ation of the HTLC timelock, if the HTLC has not been claimed on-chain by Ca=
roll, Alice can claim it back with her signature=C2=A0(and the pre-exchange=
d Caroll signature).</div><div><br></div><div>The exploit works actually in=
 Caroll leveraging her HTLC-preimage transaction as a replace-by-fee of Ali=
ce&#39;s HTLC-timeout _after_ the expiration of the timelock, the HTLC-prei=
mage transaction staying consensus valid.</div><div><br></div><div>There is=
 nothing in the mempool policy rules that prevent this Caroll&#39;s HTLC-pr=
eimage of being replaced subsequently, once Alice&#39;s HTLC-timeout has be=
en evicted out the mempool.</div><div><br></div><div>The HTLC output does n=
ot have any spend candidate remaining for this block. If this replacement c=
an be successfully repeated until an inbound HTLC on another Alice&#39;s ch=
annel expires, the &quot;forward&quot; HTLC can be double-spent. =C2=A0</di=
v><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 16 oct. 2023 =C3=A0=C2=A020:13=
, Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</=
a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;(cross-posting mempool issues identified are exposing lightning chan to=
<br>
&gt;loss of funds risks, other multi-party bitcoin apps might be affected)<=
br>
&gt;<br>
&gt;As the HTLC-preimage spends an unconfirmed input that was already inclu=
ded<br>
&gt;in the unconfirmed and unrelated child transaction (rule 2), pays an<br=
>
&gt;absolute higher fee of at least the sum paid by the HTLC-timeout and ch=
ild<br>
&gt;transaction (rule 3) and the HTLC-preimage feerate is greater than all<=
br>
&gt;directly conflicting transactions (rule 6), the replacement is accepted=
.<br>
&gt;The honest HTLC-timeout is evicted out of the mempool.<br>
<br>
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 spen=
d the same HTLC txout, without the first party having the right to spend it=
 via their knowledge of the HTLC-preimage.<br>
</blockquote></div>

--00000000000002eae50607df349f--