Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 237B5C0032 for ; Fri, 20 Oct 2023 11:19:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 06E9C60FD7 for ; Fri, 20 Oct 2023 11:19:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 06E9C60FD7 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=leI6Pnfu X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm1MHHvAhZ1b for ; Fri, 20 Oct 2023 11:19:02 +0000 (UTC) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by smtp3.osuosl.org (Postfix) with ESMTPS id D9DCF60FB6 for ; Fri, 20 Oct 2023 11:19:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D9DCF60FB6 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-507c50b7c36so883711e87.3 for ; Fri, 20 Oct 2023 04:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697800740; x=1698405540; 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=o+46LUPk+R2ueEuPonwd0UtQ46vQwjWvGdtVAPFO6MM=; b=leI6Pnfu6g6bp+3uExhOFwaq2wQFM9WYY4rCZine1udxEprpR2FO6ftTkysdQuZxy6 JSCcph6ji65z0G2/N1t95vDBZNGQYsJ3fo3qO2wGKbi7B/oo/HYCpcCxsJva83IhCApo SfO/5eZSp3jIoX4EV8Z9L7YfOuLM+9TI9ocQX8jGYvhHQRZhTjzPtcrv4WdaAaInS11o X6uPgNoNevxJs4i/Tn384hugel2x2Pm9uad2cqaYN+xrQqjRIlaBdFH5sv86ORUC4Kyn 0BVeryZwHSiIrU1qXRuknhWxoHGGAd5FrFE/aiMTjE8mciBAuCEyIGdriyjgj6KBRCQT /G8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697800740; x=1698405540; 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=o+46LUPk+R2ueEuPonwd0UtQ46vQwjWvGdtVAPFO6MM=; b=YT5JVnrQs4IDYRowacn8yjqm7OYL/+m6MIsw5B6HI190fcV4JXT7XVbTNzv3UMUliD w3iyN7UyVg95/APDdH+D7nSDS1qxCPiosOE+qRS+ysEe9HygV9ng2mdWwvWRYF8OMj1c rhRNOGuKu0BVIaA3ar1xFl/TqRmCfc6JHfh/oZmcq6fgWf081lx/PWQUIkcqf2SAo6sC hFQisuteYAU5Sxu+2L9mkanBAMJzcnvPhU0PF0uDP8mBwkGPR/yPVIVVcdfiiB7mBFj1 1/q6lZx++CKyiAgcG1l1XvTEmT+T1QJ/D+SntPznuaS2g9dbxiPSySDl/6q0vM3tfl3j FqrA== X-Gm-Message-State: AOJu0Yx1vjWHRjmLRkBIpAe9X8LekKMF/OL5O/lRqf2b0ni7EvowuW9X YKHm3nZ6PQo0RY6/K5c/SqC55LO1XCevcDNbTAw= X-Google-Smtp-Source: AGHT+IH05WGQo92y36E61cn2+a5TU+lUjcWUWk0u0jLDtKXZyboa6Z0bWmPoK8SFaKd6nR9B5L84272e3mOsQTzgXcU= X-Received: by 2002:a19:910f:0:b0:507:a0d6:f178 with SMTP id t15-20020a19910f000000b00507a0d6f178mr981030lfd.35.1697800739402; Fri, 20 Oct 2023 04:18:59 -0700 (PDT) MIME-Version: 1.0 References: <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org> In-Reply-To: From: Jochen Hoenicke Date: Fri, 20 Oct 2023 13:18:46 +0200 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2023 11:19:03 -0000 I found the original explanation a bit confusing. As I understand it, the attack starts by double-spending the timeout HTLC transaction of the victim with a pre-image revealing HTLC transaction. This itself is not an attack: the victim can then use the pre-image to receive its incoming HTLC safely, because its timeout hasn't expired yet. The trick is now that the attacker double-spends their own transaction before it hits the chain (the third transaction only double-spends some attacker controlled input used also by the pre-image HTLC transaction). In ideal condition, the pre-image transaction is never seen by the victim and the victim still doesn't know the pre-image. The attacker may only attack the mempool of the mining nodes. The victim may not even know that their transaction was replaced and are only confused why it didn't get mined. On Fri, 20 Oct 2023 at 12:47, Peter Todd via bitcoin-dev wrote: > > On Tue, Oct 17, 2023 at 02:11:20AM +0100, Antoine Riard wrote: > > > 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. > > No, you are not correctly understanding it. > > It's obvious that an HTLC output can be in competition between 2 different > parties. Obviously, the HTLC-preimage doesn't expire. The problem is you > haven't explained why the party with the HTLC pre-image should not *remain* the > party with the *right* to spend that output, even after the timeout branch > becomes another possible way to spend it. > > > 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. > > That's precisely my point re: you not properly explaining the problem. If > Caroll has the HTLC-preimage, she has the right to spend it. You need to > explain why her right to spend that HTLC-preimage output should expire. > > If anything, the way you've explained it sounds like Bob has stolen the output > from Caroll by virtue of the fact that Caroll wasn't able to spend the > HTLC-preimage output in time. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev