summaryrefslogtreecommitdiff
path: root/01/e0a27849dfd3afa0978c8ef46549717e88688d
blob: a63d6525aff437bf3559b5fb3b9e7640c4c6dec0 (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
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
Return-Path: <daniel@gap600.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6752CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Dec 2022 08:06:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 334EA40A05
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Dec 2022 08:06:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 334EA40A05
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com
 header.a=rsa-sha256 header.s=google header.b=j7ic/5/r
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001,
 LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 WzowEMpjAOff
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Dec 2022 08:06:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 274FC4092B
Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com
 [IPv6:2001:4860:4864:20::2c])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 274FC4092B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Dec 2022 08:06:29 +0000 (UTC)
Received: by mail-oa1-x2c.google.com with SMTP id
 586e51a60fabf-1443a16b71cso8232526fac.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Dec 2022 00:06:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=CFyVQJpqoLW2JRcGx6hYZ8VEoI/j9Gj8FL+j81Q/bxQ=;
 b=j7ic/5/r8GrZ4cZe6i0QhcWBMEN/1l4KF7mVrKA8h5cAe26EasgsBqcjpB1cDkJrMy
 k5qNPKsIfM/kIPG6WVsg9V1cPIkt44eEKl4feWyM+X7OCUuElW8bstXHXylZ6ZzigNe1
 5bEok+pufpxJw/w4+F42KX7xo/Plb8l9MDZxvxrm5JuBR2U3OfuGv5hcnx7fZME94UXg
 lU2yfOR3KVv4q1sqS0TWekQwH/h9h3aCGeNE33bex2L6IBkAIR8mtlPYBOwibwseE+t/
 5HLex9FruQU2gFfB+9HXCYqn+ngX+R0+SprzMby0enpUFGPVM2ArqPWrU3vk/XgyIq25
 szCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=CFyVQJpqoLW2JRcGx6hYZ8VEoI/j9Gj8FL+j81Q/bxQ=;
 b=WVh3GmPfnO5X0RA9Y7ZS2sQ3k3C0rWpTjfPKix4b1lXixvBIZCwcaDydyeVNIdnPuu
 a9xsWGj7/UzAaW18UpcaFWcNdSUNyMyUURr1sVy5LlWodIF/1QlxICSMmcbvAkk/t16J
 j6TCxbR3Q4hoUgzNPJswcKxV+9CGHWkZp7iF0ZReMkT9sfGe+aGDGOE2G54Ld1o1mUI1
 0fJD3V46sG9SPk52ye/Bu7GFZSEiLEFeBIPP2S1MjuE3ZAXEtWCiwBQJfl/iVZjcddOn
 eyz3VVppQUzyy4d0yr3zIx9xRXuCUW4R4uvksxv/rEFdkcEMT97BG81/SWyWz8pcUdnD
 JR8Q==
X-Gm-Message-State: AFqh2koq7lRnKUMBMNzY9EipDKMXfdW7faPmmhzSEXvxRyqkkotyaKlY
 MTV/Jw5oJmpELMzSTzvNP2RfA5i3LJ1ow6TmXfhLSQ==
X-Google-Smtp-Source: AMrXdXsepvnoIHokOoS3VMxFfzBHcWykQwciHYvJGqoOIYc5kLIyhToeUSpF9vV1ZeV5yUjvhKmh1+JKxoPK10WosTM=
X-Received: by 2002:a05:6870:ee0c:b0:143:dea4:c591 with SMTP id
 ga12-20020a056870ee0c00b00143dea4c591mr1475129oab.106.1671350787816; Sun, 18
 Dec 2022 00:06:27 -0800 (PST)
MIME-Version: 1.0
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>
 <Y5zfuVGpRGaknwaU@petertodd.org>
In-Reply-To: <Y5zfuVGpRGaknwaU@petertodd.org>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Sun, 18 Dec 2022 10:06:15 +0200
Message-ID: <CACkWPs_6z7UyXzejTqjy=i+SkSz-76VdzZ20K1DzcVJxan_HZg@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000000d91505f015ae65"
X-Mailman-Approved-At: Sun, 18 Dec 2022 11:02:50 +0000
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: Sun, 18 Dec 2022 08:06:31 -0000

--00000000000000d91505f015ae65
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

GAP600 is not a trxs processor or liquidity provider we service merchants,
payment processors & non-custodial liquidity providers - our service is
purely the 0-conf enabling our clients to accept 0-conf. Clients access our
service via API - sending us the Trx hash & output address. Our service is
not based on AML/KYC it is purely an analysis of the Bitcoin network.

I am not at liberty to share names of other services which have developed
their own 0-conf service - they include a payment processor on a gambling
platform which services multiple gambling operators, a standalone gaming
payment processor, and a payment processor recently I have come across. We
also do not have a significant presence in Asia - so I don't have
visibility there.

I see from the Wallet of Satoshis website that they are a custodial wallet
provider.

I don't see it being necessarily an either/or approach here. The risk
looking to be mitigated with FullRBF seems to be able to be mitigated with
FullRBF but with a swop limitation of at least the Inputs of Trx1 being in
Trx2 - no flagging required. Added to this all these trxs always have the
OptinRBF so if these platforms need to be able to recreate completely their
trxs they have that option as well. The option to Swop out or bump up trxs
seems to be well covered under those two options.

The case of creating multiple wallets with the same seeds seems to be an
edge case - and to do that and then recreate accidental double spends as a
result sounds like an extreme edge case which I would not think should be a
protocol consideration.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Fri, Dec 16, 2022 at 11:14 PM Peter Todd <pete@petertodd.org> wrote:

> On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:
> > > With multi-party transactions such as coinjoins and multi-party
> lightning
> > > channels, we want full-rbf behavior because it avoids accidental
> > > double-spends
> > > holding up progress in these protocols.
> >
> > 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 maximal=
ly
> trying to exploit transaction pinning. For example, Wasabi has found many
> cases
> of users imported the same seed into different wallets. This is quite har=
d
> to
> avoid in decentralized wallets.
>
> > Second, for intentional DoS attacks, it
> > > makes those attacks much more expensive by forcing the attacker to us=
e
> > > tx-pinning.
> >
> > 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.
> Fortunately,
> the mempool regularly empties right now. But that has not been true in th=
e
> 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
> services
> > > such as yours that benefit from the first-seen status quo, and the mu=
ch
> > > larger
> > > group of users that use Lightning and coinjoins.
> >
> > 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/1603812141966016520
>
> 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
> volume
> 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.
> Which
> 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 t=
he
> blockspace used. But Wasabi have published (reproducable) data showing th=
at
> 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 mai=
n
> coinjoin implementations.
>
> > > We've already been through
> > > such a political tradeoff before with the blocksize debate - again, t=
he
> > > centralized payment providers lost the debate.
> >
> > 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 ha=
s
> > 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
> understand
> it, AML/KYC to handle 10% of all transactions. Probably an even higher
> percentage when you take into account that only a minority of transaction=
s
> 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
> you
> 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
> what
> 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/021=
239.html
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--00000000000000d91505f015ae65
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">GAP600 is not a trxs processor or liquidi=
ty provider we service merchants, payment processors &amp; non-custodial li=
quidity providers - our service is purely the 0-conf enabling our clients t=
o accept 0-conf. Clients access=C2=A0our service via API - sending us the T=
rx hash &amp; output address. Our service=C2=A0is not based on AML/KYC it i=
s purely=C2=A0an analysis of the Bitcoin network.=C2=A0</div><div dir=3D"lt=
r"><br><div>I am not at liberty to share names of other services which have=
 developed their own 0-conf service - they include a payment processor=C2=
=A0on a gambling platform which services multiple gambling operators, a sta=
ndalone gaming payment processor, and a payment processor recently I have c=
ome across. We also do not have a significant presence in Asia - so I don&#=
39;t have visibility there.</div><div><br></div><div>I see from the Wallet =
of Satoshis website that they are a custodial wallet provider.</div><div><b=
r></div><div>I don&#39;t=C2=A0see it being necessarily an either/or approac=
h here. The risk looking to be mitigated with FullRBF seems to be able to b=
e mitigated with FullRBF but with a swop limitation of at least=C2=A0the=C2=
=A0Inputs of Trx1 being in Trx2 - no flagging required. Added to this all t=
hese trxs always have the OptinRBF=C2=A0so if these platforms need to be ab=
le to recreate completely their trxs they have that option as well. The opt=
ion to Swop out or bump up trxs seems to be well covered under those two op=
tions.</div><div><br></div><div>The case of creating multiple wallets with =
the same seeds seems to be an edge case - and to do that and then recreate =
accidental double spends as a result sounds like an extreme edge case which=
 I would not think should be a protocol consideration.</div><div><br></div>=
<div><div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div>=
<div dir=3D"ltr"><div style=3D"font-size:12.8px">__________________________=
______</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-si=
ze:12.8px"><font face=3D"tahoma, sans-serif">Daniel Lipshitz</font></div><d=
iv style=3D"font-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-s=
erif">GAP600|=C2=A0<a href=3D"http://www.gap600.com/" target=3D"_blank">www=
.gap600.com</a></font></div><div style=3D"font-size:12.8px;color:rgb(0,0,0)=
"><font face=3D"tahoma, sans-serif">Phone:=C2=A0</font><span style=3D"font-=
family:tahoma,sans-serif;font-size:12.8px">+44 113 4900 117</span></div><di=
v style=3D"font-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-se=
rif">Skype: daniellipshitz123</font></div><div style=3D"font-size:12.8px;co=
lor:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">Twitter: @daniellipshitz<=
/font></div></div></div></div></div></div><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Dec 16, 2022 at=
 11:14 PM Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@peterto=
dd.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:<br>
&gt; &gt; With multi-party transactions such as coinjoins and multi-party l=
ightning<br>
&gt; &gt; channels, we want full-rbf behavior because it avoids accidental<=
br>
&gt; &gt; double-spends<br>
&gt; &gt; holding up progress in these protocols.<br>
&gt; <br>
&gt; what is meant by accidental double spends ? And do you have any data a=
s to<br>
&gt; how often these occur and would cause harm?<br>
<br>
A double-spend of an input to a multiparty transaction that isn&#39;t maxim=
ally<br>
trying to exploit transaction pinning. For example, Wasabi has found many c=
ases<br>
of users imported the same seed into different wallets. This is quite hard =
to<br>
avoid in decentralized wallets.<br>
<br>
&gt; Second, for intentional DoS attacks, it<br>
&gt; &gt; makes those attacks much more expensive by forcing the attacker t=
o use<br>
&gt; &gt; tx-pinning.<br>
&gt; <br>
&gt; how are these Dos attacks mitigated today if Full RBF is not in place =
?<br>
<br>
They aren&#39;t. During congested mempool conditions an attacker could caus=
e<br>
significant delays to multi-party transactions without full-rbf. Fortunatel=
y,<br>
the mempool regularly empties right now. But that has not been true in the<=
br>
past, we can not guarantee that, and for Bitcoin to remain secure without<b=
r>
inflation or demmurage in the future, we have to operate under full-mempool=
s<br>
with significant backlogs of transactions.<br>
<br>
&gt; &gt; Thus we have a political tradeoff between a handful of centralize=
d services<br>
&gt; &gt; such as yours that benefit from the first-seen status quo, and th=
e much<br>
&gt; &gt; larger<br>
&gt; &gt; group of users that use Lightning and coinjoins.<br>
&gt; <br>
&gt; How many users are currently using Lightning and coinjoins today ?<br>
<br>
Wallet of Satoshi, one of many Lightning wallets, claims to be performing<b=
r>
12,500 transactions/day: <a href=3D"https://twitter.com/kerooke/status/1603=
812141966016520" rel=3D"noreferrer" target=3D"_blank">https://twitter.com/k=
erooke/status/1603812141966016520</a><br>
<br>
Bitcoin as a whole currently does about 300,000 transactions per day(1). So=
 that<br>
one single Lightning wallet represents roughly 4% of the total payment volu=
me<br>
of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+ downloads=
 on<br>
the Google Play store. So a reasonable guess is they&#39;re equally popular=
. Which<br>
means they collectively represent 12% of the total number of transactions o=
n<br>
Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per<br=
>
month(2), or about 10% of total transactions.<br>
<br>
<br>
I don&#39;t have statistics for number of coinjoin transactions per day, or=
 the<br>
blockspace used. But Wasabi have published (reproducable) data showing that=
<br>
currently about 750BTC/day are entering Wasabi 2.0 coinjoins:<br>
<a href=3D"https://mobile.twitter.com/wasabiwallet/status/16033660084373258=
28" rel=3D"noreferrer" target=3D"_blank">https://mobile.twitter.com/wasabiw=
allet/status/1603366008437325828</a><br>
<br>
You claimed GAP600 was responsible for USD $220 million of transaction<br>
volume(2), significantly less than the ~$400 million / month that Wasabi<br=
>
coinjoins alone represent. And of course, Wasabi is just one of three main<=
br>
coinjoin implementations.<br>
<br>
&gt; &gt; We&#39;ve already been through<br>
&gt; &gt; such a political tradeoff before with the blocksize debate - agai=
n, the<br>
&gt; &gt; centralized payment providers lost the debate.<br>
&gt; <br>
&gt; I don=E2=80=99t think this has anything to do with block size debate o=
r<br>
&gt; decentralisation just looking to protect a significant use case that h=
as<br>
&gt; been in place - GAP600 is by no means the only service provider is thi=
s<br>
&gt; place there are many merchants who do 0-conf on there own.<br>
<br>
You claimed that GAP600 handled about 10% of all transactions. Obviously, i=
f<br>
that is true, that indicates a very high degree of centralization. It is<br=
>
extremely undesirable for Bitcoin for one single entity with, as I understa=
nd<br>
it, AML/KYC to handle 10% of all transactions. Probably an even higher<br>
percentage when you take into account that only a minority of transactions =
are<br>
merchant payment-type transactions where unconfirmed transactions would hav=
e<br>
any relevance at all.<br>
<br>
You claim that there are &quot;many merchants&quot; who do 0-conf on their =
own. Can you<br>
list more examples of those merchants? Surely if there are &quot;many&quot;=
 of them, you<br>
could easily give us four or five more examples so this list can evaluate w=
hat<br>
kinds of security guarantees they&#39;re actually relying on.<br>
<br>
1) <a href=3D"https://ycharts.com/indicators/bitcoin_transactions_per_day" =
rel=3D"noreferrer" target=3D"_blank">https://ycharts.com/indicators/bitcoin=
_transactions_per_day</a><br>
2) <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
December/021239.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html</a><br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div></div>

--00000000000000d91505f015ae65--