summaryrefslogtreecommitdiff
path: root/41/e401a1797cccb26b6a4a62b57345f2f4f8bd96
blob: 3789f942a8140552c34ac69ec9c72e23e6a78ab5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
Return-Path: <mattmorehouse@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3EB2FC0032;
 Thu,  2 Nov 2023 17:07:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1513F706A5;
 Thu,  2 Nov 2023 17:07:56 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1513F706A5
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=FMDliHV5
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 ybDGqRyMi5Y0; Thu,  2 Nov 2023 17:07:51 +0000 (UTC)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com
 [IPv6:2607:f8b0:4864:20::232])
 by smtp3.osuosl.org (Postfix) with ESMTPS id BB12560783;
 Thu,  2 Nov 2023 17:07:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BB12560783
Received: by mail-oi1-x232.google.com with SMTP id
 5614622812f47-3b2e330033fso688927b6e.3; 
 Thu, 02 Nov 2023 10:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1698944870; x=1699549670;
 darn=lists.linuxfoundation.org; 
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=5r+o4ATHgKT58QXZbiAEn/is1WwWeMEaTrtSA5oONLM=;
 b=FMDliHV5CDgmnGBaALXO7Ah/YIUfxbvSyNfMMlvSGHxoLarg3JXyQNNOc0zHLiYRNC
 ucIlKQntD75sQhhiEirAX9U153wdTjNHqylOWAJwLHUhNp6AYQ4lnm12h1sgXcYRgyEy
 lNsdoMbfAzjUDgFvqo0YS5RDCFFs+LOWdi7q0kTQs8uqk2s49I0m/Zhh1Kz2t8pJ/+NC
 mRohvnmgQ7e3fBglEr937PkLiSK8oYt88Nzr9/ltmpCBPzAQ5QB+kw0BG1JDfpeF0i5A
 qBX+ACTGA9FlOg7S01hyhVLqFl861EizqAylSek5k6OaUlc31wLwVubS1fxcBS1GoMIT
 gehg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1698944870; x=1699549670;
 h=content-transfer-encoding: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=5r+o4ATHgKT58QXZbiAEn/is1WwWeMEaTrtSA5oONLM=;
 b=t98lpUsp7QxRTT44rkulaK/sX+iRUD448RpD61TIgHZ/kXvu2C0snxgGNTu3nlOkpL
 li5NCgtDDGcefneRFIvuOg3a+aabJH/SqONOpToC7FWwgsBV3YlJp8zDGZBuoy41QTsF
 WaaVe3p/4N0+FtMF+bq30kO898I9ha42f8XuZ9K4tBXXGiqQz6AmchzBbUFa3K/LkRpD
 esmrYD8rKVc+D7IHVY9U7B/h4GRujvuRchJwhksuudxxUTvlm+vlFjU0PsUHoUZ5mIPx
 EtG4kFcl9RsvQenP/yTTA6sQA4aXLyzWZ91R0C2yYNGGFO3Fg7dF6tNVHbRay1ooYT+e
 m3bw==
X-Gm-Message-State: AOJu0Yz3cch2z4x/9d02ZQzb//d9sVhbQ2KBqC4Un/MKOAa5wrYSXhIi
 aobfEpiXowVeZR/zDX+O/gPcpsMxhT2JVsLpDNI=
X-Google-Smtp-Source: AGHT+IEliIQ/upGSPVEHvm4D2BbiXTN+X1LPM9i6HL0+Bp+JzXGyNpk+GlPEGN4pb67AwyUI89ZzmK9Ge9b5Mzl4mug=
X-Received: by 2002:a05:6808:16a3:b0:3b2:f588:5a9c with SMTP id
 bb35-20020a05680816a300b003b2f5885a9cmr22151542oib.6.1698944870599; Thu, 02
 Nov 2023 10:07:50 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
 <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
 <ZUNBHsw2BldPLvPc@petertodd.org>
In-Reply-To: <ZUNBHsw2BldPLvPc@petertodd.org>
From: Matt Morehouse <mattmorehouse@gmail.com>
Date: Thu, 2 Nov 2023 17:07:39 +0000
Message-ID: <CAGyamEXYJN0qGKzWPsN8-T1URqmeTbUH7JJjwuFKMHByCwEG3A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 02 Nov 2023 18:12:35 +0000
Cc: security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
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 <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: Thu, 02 Nov 2023 17:07:56 -0000

On Thu, Nov 2, 2023 at 6:27=E2=80=AFAM Peter 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? Traditionally, w=
e've
> > tried
> > > to ensure that transactions - once valid - remain valid forever. We d=
o
> > this
> > > because we don't want transactions to become impossible to mine in th=
e
> > event of
> > > a large reorganization.
> >
> > I don't know if reverse time-lock where a lightning spending path becom=
es
> > 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 o=
ut
> > 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 pro=
vided
> 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