summaryrefslogtreecommitdiff
path: root/f3/a468e373547e7dbdda2f8ede192a8f36007b96
blob: da4f38c2f65f3c937e384c960176443bc7e47744 (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
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
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8ACB0C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Dec 2022 21:14:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3D47A6113C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Dec 2022 21:14:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3D47A6113C
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm2 header.b=hib7Nyi8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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 WB1xA9aaMP9d
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Dec 2022 21:14:39 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0D16C607F5
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 0D16C607F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Dec 2022 21:14:38 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id 238CC5C00FD;
 Fri, 16 Dec 2022 16:14:37 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute2.internal (MEProxy); Fri, 16 Dec 2022 16:14:37 -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=
 fm2; t=1671225277; x=1671311677; bh=aVfLJw+/m6uful+IvdlQ4LZ9mYvD
 hU4nJNkV6/tOCq8=; b=hib7Nyi8VggI5/7ygE8dE3+G5KgRF1pw5wYPwfGTNSgM
 /wvT22j5hsw6VJErdh3dL52gQ1oClE4M6zT2X5kB4pZzubQ7HEc4Kla4RiFVQV4Q
 jpw0Jqxd07Enm/HMG4MwViARHCYnOHYxGgJHxXJ1Wf3INvpqHHDC+3egY0LOOL/y
 PxJNem7CJYGyejJQXSi8eucwj7sBwGvLY2TioO6wumHQQE1e3wUI2nF2u1/+OC1z
 jU9HxdrE/8hOH/T4lEBf9ifxXIoymLlh4ZgfjUrEDopbTeQdn9MaM0R5Tap9pFxg
 a2ZZrISPGJhUsgNxzCf8ncPui0+pUzkQJC80IOXjOQ==
X-ME-Sender: <xms:vN-cY8vnrvSrm_wCBW-LCWMs16ncLLrF1GCz60mUTSzubkxmKKiCwA>
 <xme:vN-cY5cv01MGiTtWtIXmo5Cg0hBmJ0nO_liPJA_-QBezPy5XtyRswzHkVgdkHJ1N1
 DYrwROowhFNPkX0R5s>
X-ME-Received: <xmr:vN-cY3xFQTZVIghkmIp2XzYBXLFOEz_o9KsO4WqTxhwJY4qi7C-sn63VR16aCYlw8THahn_PEaefQ3k4UZT0R_rtQ_Obkgakqg8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeejgddugeehucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpeeiuddtieehgeegudejhfektdelueetfeduieetieevudeuleehfefgjeeljefg
 keenucffohhmrghinhepthifihhtthgvrhdrtghomhdphigthhgrrhhtshdrtghomhdplh
 hinhhugihfohhunhgurghtihhonhdrohhrghdpphgvthgvrhhtohguugdrohhrghenucev
 lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesph
 gvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:vN-cY_Npa5n0jqWP8XpoOa1Ch6PlYLLkP9ymNqxhv1-5B4be96tbPw>
 <xmx:vN-cY88yNHYtSsqicmEipQiPKAIONbHJ3_jWeWfOJZZo6tQeq4X2Aw>
 <xmx:vN-cY3U4mhPIwfUWzx9rOXzSTeq7egQWdpeO_SN4UcD4t7OGflVF0Q>
 <xmx:vd-cYwZ8FZbwtg4T2Y-nJwUnf24k3_4DBSY6Nf578ptsO5qJxHTTIw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 16 Dec 2022 16:14:36 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 99DC65F83F; Fri, 16 Dec 2022 16:14:33 -0500 (EST)
Date: Fri, 16 Dec 2022 16:14:33 -0500
From: Peter Todd <pete@petertodd.org>
To: Daniel Lipshitz <daniel@gap600.com>
Message-ID: <Y5zfuVGpRGaknwaU@petertodd.org>
References: <CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com>
 <CAAQdECAspoRJRz7j1ubAe=Cen==AVF5bm-Q2=0TiKc7NtbU65A@mail.gmail.com>
 <CACkWPs_4pjTo50=S86KPEznBs0PU7rd30rBGHq2Q5=6n6hYMgQ@mail.gmail.com>
 <CAHTn92wH17Z+p5cFOLpzsVUuTf4-nZc7tOjQr+_xjSU5groa0Q@mail.gmail.com>
 <CACkWPs9VawCYt7maiNqzafkFnHTiGJQkXMT4VXQQcG-rE2TTNw@mail.gmail.com>
 <Y5jxmItJIpIUVY+x@petertodd.org>
 <CACkWPs_jSLDg3seON0uu=ri6iR9cytXo2MEPJ5PVeap+iDreeQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="/kU3wjqoGPNcguY6"
Content-Disposition: inline
In-Reply-To: <CACkWPs_jSLDg3seON0uu=ri6iR9cytXo2MEPJ5PVeap+iDreeQ@mail.gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf
 use case
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, 16 Dec 2022 21:14:41 -0000


--/kU3wjqoGPNcguY6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:
> > With multi-party transactions such as coinjoins and multi-party lightni=
ng
> > channels, we want full-rbf behavior because it avoids accidental
> > double-spends
> > holding up progress in these protocols.
>=20
> what is meant by accidental double spends ? And do you have any data as to
> how often these occur and would cause harm?

A double-spend of an input to a multiparty transaction that isn't maximally
trying to exploit transaction pinning. For example, Wasabi has found many c=
ases
of users imported the same seed into different wallets. This is quite hard =
to
avoid in decentralized wallets.

> Second, for intentional DoS attacks, it
> > makes those attacks much more expensive by forcing the attacker to use
> > tx-pinning.
>=20
> how are these Dos attacks mitigated today if Full RBF is not in place ?

They aren't. During congested mempool conditions an attacker could cause
significant delays to multi-party transactions without full-rbf. Fortunatel=
y,
the mempool regularly empties right now. But that has not been true in the
past, we can not guarantee that, and for Bitcoin to remain secure without
inflation or demmurage in the future, we have to operate under full-mempools
with significant backlogs of transactions.

> > Thus we have a political tradeoff between a handful of centralized serv=
ices
> > such as yours that benefit from the first-seen status quo, and the much
> > larger
> > group of users that use Lightning and coinjoins.
>=20
> How many users are currently using Lightning and coinjoins today ?

Wallet of Satoshi, one of many Lightning wallets, claims to be performing
12,500 transactions/day: https://twitter.com/kerooke/status/160381214196601=
6520

Bitcoin as a whole currently does about 300,000 transactions per day(1). So=
 that
one single Lightning wallet represents roughly 4% of the total payment volu=
me
of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+ downloads=
 on
the Google Play store. So a reasonable guess is they're equally popular. Wh=
ich
means they collectively represent 12% of the total number of transactions on
Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per
month(2), or about 10% of total transactions.


I don't have statistics for number of coinjoin transactions per day, or the
blockspace used. But Wasabi have published (reproducable) data showing that
currently about 750BTC/day are entering Wasabi 2.0 coinjoins:
https://mobile.twitter.com/wasabiwallet/status/1603366008437325828

You claimed GAP600 was responsible for USD $220 million of transaction
volume(2), significantly less than the ~$400 million / month that Wasabi
coinjoins alone represent. And of course, Wasabi is just one of three main
coinjoin implementations.

> > We've already been through
> > such a political tradeoff before with the blocksize debate - again, the
> > centralized payment providers lost the debate.
>=20
> I don=E2=80=99t think this has anything to do with block size debate or
> decentralisation just looking to protect a significant use case that has
> been in place - GAP600 is by no means the only service provider is this
> place there are many merchants who do 0-conf on there own.

You claimed that GAP600 handled about 10% of all transactions. Obviously, if
that is true, that indicates a very high degree of centralization. It is
extremely undesirable for Bitcoin for one single entity with, as I understa=
nd
it, AML/KYC to handle 10% of all transactions. Probably an even higher
percentage when you take into account that only a minority of transactions =
are
merchant payment-type transactions where unconfirmed transactions would have
any relevance at all.

You claim that there are "many merchants" who do 0-conf on their own. Can y=
ou
list more examples of those merchants? Surely if there are "many" of them, =
you
could easily give us four or five more examples so this list can evaluate w=
hat
kinds of security guarantees they're actually relying on.

1) https://ycharts.com/indicators/bitcoin_transactions_per_day
2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/02=
1239.html

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--/kU3wjqoGPNcguY6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmOc37YACgkQLly11TVR
LzffBA/8DLFeSGF/lUA3gH3F4JRoRp4Tmc1XCp7/VIwmi6LxQ87e84Hr/vjppBQH
vU4gcmTRWy98OXKhYszMJ53MhPmcgRt7o3xzGMTWXQ04t7TKCqGj52AaLg2uzmzh
O/1/Fl8Xln9/NLu2hatW0Le6tsLpkckyzdIg0JO6UlUHJ4GgV8BKOSyCBZCdC2pD
aPU2S0Zjfg/+kQYCzRT6gQbEBh4hhuI/p0Nng+1PRd7JPJU8TX7GFa+iiyn7KW8S
i10xjv2lwIZlgz92prm87s3iaZIwSFocH7+M+SCsSau0Zj6Qu7utyOgrf4Gc7DZ/
b1Q9R5RPSE5GeIv2RcLCZlQmrSizVpbRxKmnLB3kLS2sKmVA8F3BkIJdZGCu8lh1
YE8Va7gYrrT6JVuxdXMXCRUf7LAJjlqKLLqcee0eiufs41Fi3ZQSrDuJIAyI/0Fe
dVkYpND4HLze5KKQczVsfr22iPEwk3/ygB/5D+YUaZjHYaz1ACOlJZ53UP7XrDDQ
89HX4zx/upCwlMxk+7cAMJ20QqI44k+OS4VxPKvZWMfppiom0ogAAzfn8RCj2Q/E
vVk9znFgDw4y8PXlJZ5Pxpej/V9pybo7OUWXzrDN/9iwc9LQtPHj9/urb0CpwR6B
qHv3XU1oXugTYeDLCcKeeac4KqELeMPi96KYf3h4/3e72kUwk9A=
=Ed53
-----END PGP SIGNATURE-----

--/kU3wjqoGPNcguY6--