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
|
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 87855C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 09:29:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 68E984020B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 09:29:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 68E984020B
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=EHaEnZ9b
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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,
SPF_HELO_PASS=-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 z90G5RtRBQ1e
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 09:28:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 105CF40127
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
[185.70.40.134])
by smtp2.osuosl.org (Postfix) with ESMTPS id 105CF40127
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 09:28:58 +0000 (UTC)
Date: Tue, 08 Nov 2022 09:28:44 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1667899736; x=1668158936;
bh=/+an4T7ZdvMtzRXOYWL19oNN0Ri7hrygttb3/YjwEfk=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=EHaEnZ9bjKJdx7lBlaMmMqigRaQ2Hsl61sgcFeWkEl/9raUNN/3PFf9tXa9oeJeyg
7qp+aRaBDWLhw0E7oOFsbXaJN/feNx4aInp+B4a2y9telxlOZzUS+dqtLG5e8kBAtK
PyYPR3T2xd1ZTnFpzy+H9pHYC3DOIpx+4RGPrFMlu0A2uIJl0bX1KM5UZiXg0Eit+i
u6JE4+j1CBLg87Sb+eP+hDqDYBfq7hQ2hIvfpZAFxps1ViZeMFUwMJUaCyxar8jH7J
t/8EBDYGzr/fAJuyKwc4YEIOhE+9kc6O+Ie1IwtSxEPmAPH2TyTwxnKVPjvK1YE95W
OOFywNkdZ2ywA==
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <jzS-a7kpDwvAhO4TJiTgtpsP95Zi8BRvIgUqjOs3hEVI_Uu-ey1LfCnN2D8wkG21yfVPGIujbiDXCfFAyfW56gPtvd8p3SrsOmOE22IWAuA=@protonmail.com>
In-Reply-To: <Y1q+MedepB1qUpBP@erisian.com.au>
References: <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
<CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
<Y1q+MedepB1qUpBP@erisian.com.au>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 08 Nov 2022 10:13:23 +0000
Subject: Re: [bitcoin-dev] On mempool policy consistency
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, 08 Nov 2022 09:29:00 -0000
Hi aj and list,
(questions inline)
------- Original Message -------
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via bitcoin-dev <bi=
tcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
> a DoS issue when utxos are jointly funded by untrusting partners, and,
> aiui, that's the main motivation for addressing this now.
>=20
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00=
3033.html
>=20
> The scenario he describes is: A, B, C create a tx:
>=20
> inputs: A1, B1, C1 [opts in to RBF]
> fees: normal
> outputs:
> [lightning channel, DLC, etc, who knows]
>=20
> they all analyse the tx, and agree it looks great; however just before
> publishing it, A spams the network with an alternative tx, double
> spending her input:
>=20
> inputs: A1 [does not opt in to RBF]
> fees: low
> outputs: A
>=20
> If A gets the timing right, that's bad for B and C because they've
> populated their mempool with the 1st transaction, while everyone else
> sees the 2nd one instead; and neither tx will replace the other. B and
> C can't know that they should just cancel their transaction, eg:
>=20
> inputs: B1, C1 [opts in to RBF]
> fees: 50% above normal
> outputs:
> [smaller channel, refund, whatever]
>=20
> and might instead waste time trying to fee bump the tx to get it mined,
> or similar.
>=20
> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?
>=20
<snip>
>=20
I read Antoine's original post on this and got the general gist, and here a=
lso, it makes sense, but I'd like to ask: is it necessary that (B, C) in th=
e above not *see* A's opt-out "pre-replacement" (inputs: A1, outputs: A, fe=
es: low; call it TX_2)? I get that they cannot replace it, but the idea tha=
t they suffer financial loss from "ignorant" fee bumping is the part that s=
eems weird to me. Clearly TX_2 gets gossiped to other mempools; and underst=
ood that it does not replace the TX_1 (the 3-input) in B's mempool, say, bu=
t why should they not even hear about it? Is it just a matter of engineerin=
g, or is there some deeper problem with that.
About this general flavour of attack, it's never been a *big* concern in Jo=
inmarket imo (though, we did until recently have a bug that made this happe=
n *by accident*, i.e. people double spending an input out of a negotiated j=
oin, albeit it was rare; but it's ofc definitely *possible* to 'grief' like=
this, given the ordering of events; maker sends signature, maker broadcast=
s double spend - 95% of the time they will be first). Interactive protocols=
are yucky and I think there'll always be griefing possibilities; designing=
around multiple-rounds of negotiation amongst not always-on participants i=
s even more yucky, so just having a 'taker is in charge of network fee; if =
it's slow or gets double spent out causing time delay then just wait', comb=
ined with 'there really isn't any economic incentive for an attacker' (i.e.=
ignoring griefing) might sound crappy but it's probably just being realist=
ic.
Of course, off-chain contracting has more sophisticated considerations than=
this.
Cheers,
AdamISZ/waxwing
|
