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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id EC164C0032;
Tue, 17 Oct 2023 17:17:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id CED0241C60;
Tue, 17 Oct 2023 17:17:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CED0241C60
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=T3zUx8kO
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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 5SjXbDFsETll; Tue, 17 Oct 2023 17:17:21 +0000 (UTC)
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
by smtp4.osuosl.org (Postfix) with ESMTPS id 2C41641B94;
Tue, 17 Oct 2023 17:17:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2C41641B94
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1697563038; x=1697822238;
bh=6KRDyoYaywgs23839RZVshICyAYDMtdg5Ucw3auhV6Q=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=T3zUx8kO7sNMIIzxVzcNyV2MaciTFEYbg5dFCqeIvYD6vMxFGNC5Zdbn5IplG1Ia6
qJxFpOF6CpM5SslxQ/g3O2v9AM14jffExqnYahZTMTDFFOeucj6hD/8gEXCayOaf0D
6G/UC3/sA0UfNfre8/J9p4TELeL3Pg+eRMBpBrwK/iLXDbpa4iEmmdXrLebXUkAJ0b
kFZBqdrgKVAcgUlQ7h3lMBLNXSgHdDYxc1ioenb5V0dzVKaO5++z1F3E7hPQ0L7iOV
EEGjk/FYF6tRpOFjGCTqYMbsl9gibDuJIviWJuLOGTzCxDQkA7pB+ZdgvCfTAOjZ0G
tOPewf2wfUGQg==
Date: Tue, 17 Oct 2023 17:17:04 +0000
To: Greg Sanders <gsanders87@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <xq5SXj5Qx2uuhwui_Xoc0K0WBxoJj98cYBCoumHLi101ofbMCET_-4athmHvDvDl0H9GKHlsRo73j9iUuSx9OmHbfQNjDDYAx-JzFNLMNtI=@protonmail.com>
In-Reply-To: <CAB3F3Dtb2s7gCjV6ok3=XjOx174DEuRksij4GOoFD20atwJfig@mail.gmail.com>
References: <CACdvm3MuKmzQ1EFMJDc0ahhrG6xpD6Rr9Vh=ZTpVHa12ZALB0w@mail.gmail.com>
<Ckp3N2cHGyyFyTp8IkjqYwnXsef1KxzhFs9vHQvFCpdWKUCrCfpxLBAgIXsKEtTNQqvfdyywt7weJd2pVz8UKn6egfRy46-xd17pnltcQyU=@protonmail.com>
<CAB3F3Dtb2s7gCjV6ok3=XjOx174DEuRksij4GOoFD20atwJfig@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Batch exchange withdrawal to lightning requires
covenants
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 17:17:22 -0000
Good morning Greg,
> > I do not know if existing splice implementations actually perform such =
a check.
> Unless all splice implementations do this, then any kind of batched splic=
ing is risky.
> As long as the implementation decides to splice again at some point when =
a prior
> splice isn't confirming, it will self-resolve once any subsequent splice =
is confirmed.
Do note that there is a risk here that the reason for "not confirming" is b=
ecause of an unexpected increase in mempool usage.
In particular, if the attack is not being performed, it is possible for the=
previous splice tx that was not confirming for a while, to be the one that=
confirms in the end, instead of the subsequent splice.
This is admittedly an edge case, but one that could potentially be specific=
ally attacked and could lead to loss of funds if the implementations naivel=
y deleted the signatures for commitment transactions for the previously-not=
-confirming splice transaction.
Indeed, as I understood it, part of the splice proposal is that while a cha=
nnel is being spliced, it should not be spliced again, which your proposal =
seems to violate.
Regards,
ZmnSCPxj
|
