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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
Return-Path: <pete@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id A5EE6C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jan 2023 23:37:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 64ABE400D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jan 2023 23:37:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 64ABE400D3
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=messagingengine.com header.i=@messagingengine.com
header.a=rsa-sha256 header.s=fm3 header.b=GCSWWDvD
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7, 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 Kk_Ap3adI6Ho
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jan 2023 23:37:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 87997400C8
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com
[64.147.123.19])
by smtp2.osuosl.org (Postfix) with ESMTPS id 87997400C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 Jan 2023 23:37:15 +0000 (UTC)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.west.internal (Postfix) with ESMTP id 85C1F3200927;
Fri, 13 Jan 2023 18:37:09 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute5.internal (MEProxy); Fri, 13 Jan 2023 18:37:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-type:date:date:feedback-id
:feedback-id:from:from:in-reply-to:in-reply-to:message-id
:mime-version:references:reply-to:sender:subject:subject:to:to
:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
fm3; t=1673653029; x=1673739429; bh=rHyHXbAqGHCaZSx3VFm8/xE+lbCE
nbrdwujDAbN4dIU=; b=GCSWWDvDCAoDC0pdsAY9BIFjlMmW6SYKCEFf05hE+ogd
meT5LT1Pf2axqD1sXSGeoxOYtghNt3x0KnTIUTcW9KWlwpNNygXxAuC4sKA/0qAy
iS2iEJBCvGW2okY/cC5PWEuXHpaaOWISnCToVs15mVO/2DVa/TaICfUjbj6rnYUW
Fps3DaJ5bSsjqg6REUHMAm/J8M5hzFyHVB27JrU1x/7/Xtz+cvX5a4HRAwJMFWpO
z7en2+KTCAUWAOJYpy3p5gp8Y1j1bTtnniUaz2EWI3lonOaPQPLig7/3VGwA+zQW
6RxP+rS1yINY4nJ4lkMXIn+zzKom0CD3elzQW535oQ==
X-ME-Sender: <xms:JOvBY4N0DEFnl6zgqvdJv3AUQ0AxSf2cfq8ToNi7BGc2BI0JgT-mYw>
<xme:JOvBY-9ptS2XrnQ_96rFryJuDNDTjUGgNlhicOpuuCze3TjbrjAN9PkREnNroqI_d
ih9bvTctoSfQp4MBkk>
X-ME-Received: <xmr:JOvBY_QsH1V-RIkwEwfg8n5vf5EDgHim1qU8l7i4-d4tf2nEneMaJoavKsoaXQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrleelgdduvdcutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesghdtre
ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
uggurdhorhhgqeenucggtffrrghtthgvrhhnpeelvdellefftddukeduffejgfefjeeuhe
eileeftdfgteduteeggeevueethfejtdenucffohhmrghinhepphgvthgvrhhtohguugdr
ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
hpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:JOvBYwvIfI43eOtme1FU2QSr_ax-Gmfp3YResGTnSRsetK-m9tC49w>
<xmx:JOvBYwfTQvcL7V5mXMebU_iQI1lFtD83C438-TCZ9K-PdrbvK9wHrQ>
<xmx:JOvBY03AZm7ni9KW52GG9LHW-Cy2E4ET5J5kLpL4tJLPUdpdWTOmqQ>
<xmx:JevBY44CeJCtnqo9zvLJgLoVy4uVwX5nbOh6MqWKGXmi_zfwG4-RBA>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
13 Jan 2023 18:37:08 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id 5AA9C5F82C; Fri, 13 Jan 2023 18:37:04 -0500 (EST)
Date: Fri, 13 Jan 2023 18:37:04 -0500
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Message-ID: <Y8HrINYYYiw+V9v+@petertodd.org>
References: <Y7ySzDjzx5eDjOH9@petertodd.org>
<aaaeda2950e61127a3218c523927a0d8@dtrt.org>
<Y70mNHsX4JcKYZyi@petertodd.org>
<6089e1f0140684435bf5e87b0c13d561@dtrt.org>
<Y704non5DD5mtxs1@petertodd.org>
<6cebd312ca960e634729cc574c2e97b0@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="V0vev2iJbgUJXWrn"
Content-Disposition: inline
In-Reply-To: <6cebd312ca960e634729cc574c2e97b0@dtrt.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Full-RBF Makes DoS Attacks on Multiparty
Protocols Significantly More Expensive
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: Fri, 13 Jan 2023 23:37:17 -0000
--V0vev2iJbgUJXWrn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote:
> On 2023-01-10 00:06, Peter Todd wrote:
> > Remember, we'd like decentralized coinjoin implementations like
> > Joinmarket to
> > work. How does a decentralized coinjoin implement "conflict monitoring"?
>=20
> 1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core
> with -debug=3Dmempoolrej will tell you when it rejects a transaction
> for conflicting with a transaction already in the mempool, e.g.:
>=20
> 2022-11-01T02:53:17Z
> 867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from
> peer=3D58 was not accepted: txn-mempool-conflict
>=20
> I think it would be easy to extend this facility to list the inputs
> which conflicted. So if Alice sees a conflict created by Mallory,
> she can create a new coinjoin transaction without Mallory. This
> method has the advantage of being fast and attributing fault,
> although it does require Alice's node be online at the time Mallory's
> conflict is propagated.
So for something as simple as reliable coinjoining - an important privacy
feature that we'd like all wallets to use - you expect people to run
well-connected 24/7 nodes running specialty software?
Even if you run a node as you suggest, there's certainly no guarantee that
you'd learn about any double-spend without doing a severe sybil attack agai=
nst
the network; the 8 outgoing nodes a typical node has samples a tiny fractio=
n of
the network. And *even if* you sybil attack to try to detect conflicts ther=
e's
still no guarantee as attackers can use all kinds of special techniques to =
get
transactions into miner mempools and not others.
> 2. Simply assume a conflict exists for otherwise unexplainable failures.
> For example, if Alice sees several new blocks whose bottom feerates
> are well below the feerates of an unconfirmed coinjoin transaction
> that Alice helped create and broadcast, she can assume it's a
> conflict that is preventing preventing confirmation of the coinjoin.
> She can find an entirely different set of collaborators and create a
> non-conflicting transaction without ever needing to know which inputs
> from the original transaction conflicted. This method has the
> disadvantage of being slow (on the order of hours) and not attributing
> fault, although it doesn't require Alice has any information beyond
> copies
> of recent blocks.
You're suggesting that to avoid enabling full-rbf, coinjoin's and other
decentralized multi-party protocols risk getting coins tied up for hours tr=
ying
to do conflict resolution rather than just fixing the underlying problem wi=
th
what's literally a one-line code change that 17% of the v24.x nodes have
decided to enable.
> I didn't list these methods or others before because the specific method
> used to
> detect conflicts doesn't matter to the realization that software which
> uses conflict detection and evasion to defeat the $17.00 attack also
> defeats the $0.05 attack without any need for full-RBF.
Fact is, full-rbf defeats those attacks much better. And I'm amazed that you
don't consider raising the cost of attacks on coinjoins and similar
decentralized protocols by almost three orders of magnitude to be important:
why are you prioritizing a few highly centralized, often AML/KYC'd, unconfi=
rmed
tx acceptance services over decentralized protocols which provide privacy a=
nd
security to a lot more users?
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--V0vev2iJbgUJXWrn
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmPB6x8ACgkQLly11TVR
LzeAuBAArPiq6tF53SMPKYvaTtWAIB4bptWJkw+a+1YpQZNi2Z2M12ECyun2lVIu
x04xYuanmgHDZ2D7fNiK58pMQjVp73Q9ZSc/EYAr67/S/AuSLo9IWh3NaLnaZVtE
+4yuJiJlREV3b6hIaQmqoog/LYsDEYJLW/pv5C+NMqmsi2c5TIEX9AtozOWGcNqG
lPNYggJBFx9Lm0jMmoLECYXBfICZbgJulJNKSl8aZoCTB1bbK2LSYz7tE4WNNgyA
C2NyDSKDG0I1/ltEhz0fXP1bXCZYmjMzRC2CwUlrIxwgzTfbabQpBGi+T0JQAEYL
rpL9/LENZgY/3puoU9/MY43/6Bhdh5lIls/J0f/PxSW5zp14qflmm61ZYJu1qZne
WUqs4ySoPxf4I5xIdz4llfHEJP7X6i5GYBIoM+zD08yJbyOHfxNQbKn0MC0aok76
X/ncpMpNBe3MJT1nEeQrkqiG1D9ErLV2/vR6y+KYXuqIcj6Zbcx52alxZLoaKXq2
4xFw1Q8LUH8CU6bGhf0onqJFNlcB5L+LVdTHEbuFe80qlwfvEOumz1V9OJvfTfiN
mv/DhFD2rT8MvxrtqraU2qhN81y9Jrx7JKUy04HIOp+XqwOZKk4bdPXQ15MdY+Hx
nN8tLR03Ro7+Ru34obaRTbGoXRWPO8dj7rsollyTJgUExdB9vXc=
=g6ko
-----END PGP SIGNATURE-----
--V0vev2iJbgUJXWrn--
|
