summaryrefslogtreecommitdiff
path: root/c0/c67eff720349db98e492c4cf712ec6daa7ac0a
blob: fab1e37e9406d3a30e85d7267b7e490671ec9ee6 (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
Return-Path: <bnagaev@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 64232C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 14:22:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 3E5F0435FE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 14:22:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3E5F0435FE
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=QTZUOsl4
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id E09U0DP1-w7D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 14:22:27 +0000 (UTC)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
 [IPv6:2607:f8b0:4864:20::130])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4EDC8400D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 14:22:27 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4EDC8400D0
Received: by mail-il1-x130.google.com with SMTP id
 e9e14a558f8ab-357c9dc1068so530615ab.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 07:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697898146; x=1698502946;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=0e9nC9HUc1PZ2rM/Oh+d75eULxOTtTMQyPFzQVNmnCQ=;
 b=QTZUOsl47HoRcbRyMms1f7LGfywzpcfJrxK3t2L3Z0UKOzPyoIkIuzdLEv0QyZftqs
 Ts2gJEnt5SPcU1YZwckzVS6HeyO/MeSWUGUCs1Op1LUsQXQiVSXjTBis567ADiwl2jdW
 FJJ1y9syTum3sb5xKLEfAvQxDQ2PJQRaEVd45vEZ5P1L74WwDBjGACYe7GbT+gSykVvQ
 JQ494tb1QUIx+loxYxn6Ly0xtLNCNPg+iQJajkkaHldA/E3lTKFT3V+nUN9p7hASk06h
 LaFBTyxY62BKUszqFKgSL7fHmKpV5/6+1/4w8PK3+ibRIAxnSkQQWydNwiNBUZ7UKFRr
 Qdvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697898146; x=1698502946;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=0e9nC9HUc1PZ2rM/Oh+d75eULxOTtTMQyPFzQVNmnCQ=;
 b=n7sYoBPLw9jDsR9BQFONSVT2abJPjtXPOVmTcORrEQr+Hf/5VZJMjpyX240mNemr0B
 mlB2plsMyTFQivOs64WsFXk5qIcdcEi/I6xWEnLdXW3QfSs9bqGvS/TNJ/gcbkGnX4PK
 ceky0fgP6entYL9mdMeqksYUVRAMNUpE6y29E6lJLF3yOBDm9/rqfa5M0o8S1WfwQTm9
 EOov80NMQZH7IZX1YkaJan2EZGKPecF0QOmS0MHrQYFIl7vokI2WzugzbXHpZHWREGpW
 y/LEALmKNPymFIWrJ5DoYtoO0VBC+wYqCYTtmLAmiou/5oEvCtzGzwSbHrfqnDKinHo6
 sZ4Q==
X-Gm-Message-State: AOJu0YxNjdNzmLqqch8Esb5MVu6zmasonYLCz/6Qaxpmd7r8Pp8CMbRT
 X4tDqnI89EFqdTs6uGg4cKLjp695qEfSNDsQF53Fum7sRoU=
X-Google-Smtp-Source: AGHT+IHg8G/t+XFzneJmqgbycRBPHyAobuv2j9zwjjMCcKLiBgt63eZdXGxFvxO7VxEnahDu5Cq6UEJAf7ANtfIcC1Y=
X-Received: by 2002:a05:6e02:1a6c:b0:357:a272:dbc with SMTP id
 w12-20020a056e021a6c00b00357a2720dbcmr5403055ilv.9.1697898146140; Sat, 21 Oct
 2023 07:22:26 -0700 (PDT)
MIME-Version: 1.0
From: Nagaev Boris <bnagaev@gmail.com>
Date: Sat, 21 Oct 2023 11:21:48 -0300
Message-ID: <CAFC_Vt4-DXkEPZEfXzZQET7P9KSyOrgojGqr8w-xvTECeRn7Zw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Sat, 21 Oct 2023 14:35:22 +0000
Subject: Re: [bitcoin-dev] [Lightning-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: Sat, 21 Oct 2023 14:22:28 -0000

I think the presigned transactions should be interleaved fee-wise:
1.1 to Alice
1.2 to Bob
1.3 to Alice
1.4 to Bob
...

Then any such transaction evicts all previous transactions in the
chain. It reduces risks of mempool split.

If there are two transactions to Alice and to Bob both with fee 1.1,
then it is possible that half of nodes have the transaction to Alice
in their mempools and another half of nodes has the transaction to
Bob. Though I don't see how exactly this can be used in replacement
cycling attacks, I think it is safer to prevent this scenario.

On Fri Oct 20 18:35:26 UTC 2023, Matt Morehouse via bitcoin-dev wrote:
> I think if we apply this presigned fee multiplier idea to HTLC spends,
> we can prevent replacement cycles from happening.

> We could modify HTLC scripts so that *both* parties can only spend the
> HTLC via presigned second-stage transactions, and we can always sign
> those with SIGHASH_ALL.  This will prevent the attacker from adding
> inputs to their presigned transaction, so (AFAICT) a replacement
> cycling attack becomes impossible.

> The tradeoff is more bookkeeping and less fee granularity when
> claiming HTLCs on chain.


-- 
Best regards,
Boris Nagaev