Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 69AF5C0032; Fri, 3 Nov 2023 05:28:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 363B040017; Fri, 3 Nov 2023 05:28:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 363B040017 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=S9hZVZ8x 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjIjubtWXYKe; Fri, 3 Nov 2023 05:28:06 +0000 (UTC) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by smtp2.osuosl.org (Postfix) with ESMTPS id 93A2B41AE1; Fri, 3 Nov 2023 05:28:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 93A2B41AE1 Received: by mail-ot1-x333.google.com with SMTP id 46e09a7af769-6ce2fc858feso924094a34.3; Thu, 02 Nov 2023 22:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698989285; x=1699594085; 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=0ag4+Iwsn/OAzMz3nPidWiGfZyV522zysq1dS6UVx64=; b=S9hZVZ8x3KHVjNTLeQZBJ1YaEMNLdWhvkwJg5GOe9MCODWTzyHhtZRdNj94nLNlVsQ AT3CB4bPbvVgKim+KhZ2JZYmsf8zscWrBbuBefOiynMyPLIDy9gc61BPEXd+2EXg6RW9 fCHEiIRUp6ChWb/AbFhnfrV8DipvCnwROP/Th3WXzbhM4E+r+F/GxhXUvF037gh4fhGf Z2nEdidHFOFR9fZLegpmi2Qmmg51hQ9jM3wrcl6jNdmH+9KEDLl5+wagENx/rILkjOsR 51zvy/xDdnY47gOdbGIq9i4VT6KucmP/Fau2Yo1E8PPOnH3BWLGoL1d11eHIg5dkBpex TSgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698989285; x=1699594085; 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=0ag4+Iwsn/OAzMz3nPidWiGfZyV522zysq1dS6UVx64=; b=t49OqqaSe8AXS07Rr2ptmVqs51Ao1tQ3/H+aRuuX2G7TAFwtEtM0NEoZMIa4h5AncX KnTgGrQiJErjEIkYbpPpQ2zPDQvOeHR/WpVeSoOHV4zYcLfWvm2zBksKdOqp5cTeVHhH VeTQrpfBfQT7tZg8jpqFsIxfx/awDKUMQqc4SXMHkTpbvWwMR3Ag6IsljGEQ3Y2xrIxQ fOJHeBxyJZhN+UbhdyY2hBThACW7vNKdB+vXBrYTuJ+NDs++2VsBJeIuLlpRcldeku1s b3jRw0lbkFjuBbTDG526I7Z+ZIrvHq/3O51d7HROZ75jZJDdQxUd6I1MRWvjXYe5Cqai 5hRw== X-Gm-Message-State: AOJu0YzT658B8nL/hj/fU/2a5GhfSQZ+rfvDh0kMTnZk4agFUOd20ePI WimPXt+x+5PhAcsafpAQs5epBazoJ7EL3xcW9CU= X-Google-Smtp-Source: AGHT+IFuqr/lZKSGLGu6AaebLBq/5Z6ufyXfZp7PYWb9G+ttWy0cSKAhbbgX7J2dCICIwjc/TuUvmuKDravWbHClq4s= X-Received: by 2002:a05:6808:2013:b0:3b5:84b0:6bea with SMTP id q19-20020a056808201300b003b584b06beamr4040546oiw.22.1698989285582; Thu, 02 Nov 2023 22:28:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Fri, 3 Nov 2023 05:27:54 +0000 Message-ID: To: Matt Morehouse Content-Type: multipart/alternative; boundary="000000000000d82dfd060938c462" X-Mailman-Approved-At: Fri, 03 Nov 2023 09:41:01 +0000 Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" , security@ariard.me Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely 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, 03 Nov 2023 05:28:11 -0000 --000000000000d82dfd060938c462 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The idea with package relay is that commitment transaction fees will > be zero and that fees will always be paid via CPFP on the anchor > output. Yes, even if multiple commitment transactions are pre-signed with a RBF range of more than zero, an attacker can always select the lowest fees pre-signed states and adjust in consequence the CPFP paid, and then evict out the bumping CPFP. Le jeu. 2 nov. 2023 =C3=A0 17:07, Matt Morehouse = a =C3=A9crit : > On Thu, Nov 2, 2023 at 6:27=E2=80=AFAM Peter Todd via bitcoin-dev > wrote: > > > > On Thu, Nov 02, 2023 at 05:24:36AM +0000, Antoine Riard wrote: > > > Hi Peter, > > > > > > > So, why can't we make the HTLC-preimage path expire? Traditionally, > we've > > > tried > > > > to ensure that transactions - once valid - remain valid forever. We > do > > > this > > > > because we don't want transactions to become impossible to mine in > the > > > event of > > > > a large reorganization. > > > > > > I don't know if reverse time-lock where a lightning spending path > becomes > > > invalid after a block height or epoch point solves the more advanced > > > replacement cycling attacks, where a malicious commitment transaction > > > itself replaces out a honest commitment transaction, and the > > > child-pay-for-parent of this malicious transaction is itself replaced > out > > > by the attacker, leading to the automatic trimming of the malicious > > > commitment transaction. > > > > To be clear, are you talking about anchor channels or non-anchor > channels? > > Because in anchor channels, all outputs other than the anchor outputs > provided > > for fee bumping can't be spent until the commitment transaction is > mined, which > > means RBF/CPFP isn't relevant. > > IIUC, Antoine is talking about a cycling attack of the commitment > transaction itself, not the HTLC transactions. It seems possible for > future (ephemeral) anchor channels in a world with package relay. > > The idea with package relay is that commitment transaction fees will > be zero and that fees will always be paid via CPFP on the anchor > output. > > Consider this scenario: Mallory1 -> Alice -> Mallory2. > Mallory2 claims an HTLC from Alice off chain via the preimage. Alice > attempts to claim the corresponding HTLC from Mallory1, but Mallory1 > refuses to cooperate. So Alice publishes her commitment transaction > along with a CPFP on the anchor output. Mallory1 publishes her > competing commitment transaction with a higher CPFP fee on the anchor > output, thereby replacing Alice's package in the mempool. Mallory1 > then replacement-cycles the anchor output child transaction, causing > her commitment transaction to lose its CPFP and the package feerate to > go to zero, which is below the minimum relay fee. Thus, Mallory1's > commitment transaction is also evicted from the mempool. Mallory1 > repeats this process every time Alice broadcasts her commitment, until > the HTLC timeout expires. At that point the preimage path becomes > unspendable, and Mallory1 can claim the HTLC via timeout at her > leisure. > > > > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000d82dfd060938c462 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The idea with package relay is that commitment transa= ction fees will
> be zero and that fees will always be paid via CPFP = on the anchor
> output.

Yes, even if multiple = commitment transactions are pre-signed with a RBF range of more than zero, = an attacker can always select the lowest fees pre-signed states and adjust = in consequence the CPFP paid, and then evict out the bumping CPFP.

Le= =C2=A0jeu. 2 nov. 2023 =C3=A0=C2=A017:07, Matt Morehouse <mattmorehouse@gmail.com> a =C3=A9crit= =C2=A0:
On Thu, Nov 2, 2023 at 6:27=E2=80=AFAM Pe= ter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thu, Nov 02, 2023 at 05:24:36AM +0000, Antoine Riard wrote:
> > Hi Peter,
> >
> > > So, why can't we make the HTLC-preimage path expire? Tra= ditionally, we've
> > tried
> > > to ensure that transactions - once valid - remain valid fore= ver. We do
> > this
> > > because we don't want transactions to become impossible = to mine in the
> > event of
> > > a large reorganization.
> >
> > I don't know if reverse time-lock where a lightning spending = path becomes
> > invalid after a block height or epoch point solves the more advan= ced
> > replacement cycling attacks, where a malicious commitment transac= tion
> > itself replaces out a honest commitment transaction, and the
> > child-pay-for-parent of this malicious transaction is itself repl= aced out
> > by the attacker, leading to the automatic trimming of the malicio= us
> > commitment transaction.
>
> To be clear, are you talking about anchor channels or non-anchor chann= els?
> Because in anchor channels, all outputs other than the anchor outputs = provided
> for fee bumping can't be spent until the commitment transaction is= mined, which
> means RBF/CPFP isn't relevant.

IIUC, Antoine is talking about a cycling attack of the commitment
transaction itself, not the HTLC transactions.=C2=A0 It seems possible for<= br> future (ephemeral) anchor channels in a world with package relay.

The idea with package relay is that commitment transaction fees will
be zero and that fees will always be paid via CPFP on the anchor
output.

Consider this scenario:=C2=A0 Mallory1 -> Alice -> Mallory2.
Mallory2 claims an HTLC from Alice off chain via the preimage.=C2=A0 Alice<= br> attempts to claim the corresponding HTLC from Mallory1, but Mallory1
refuses to cooperate.=C2=A0 So Alice publishes her commitment transaction along with a CPFP on the anchor output.=C2=A0 Mallory1 publishes her
competing commitment transaction with a higher CPFP fee on the anchor
output, thereby replacing Alice's package in the mempool.=C2=A0 Mallory= 1
then replacement-cycles the anchor output child transaction, causing
her commitment transaction to lose its CPFP and the package feerate to
go to zero, which is below the minimum relay fee.=C2=A0 Thus, Mallory1'= s
commitment transaction is also evicted from the mempool.=C2=A0 Mallory1
repeats this process every time Alice broadcasts her commitment, until
the HTLC timeout expires.=C2=A0 At that point the preimage path becomes
unspendable, and Mallory1 can claim the HTLC via timeout at her
leisure.

>
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
--000000000000d82dfd060938c462--