summaryrefslogtreecommitdiff
path: root/8b/a05f8c485b3a2c8733aa6353ae5dc6ba3db75d
blob: cbe017111f14157e7801d06ed73beb3b5e05a7cf (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
Return-Path: <daniel@gap600.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D1F15C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 14 Jan 2023 20:15:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9F71860DE5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 14 Jan 2023 20:15:44 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9F71860DE5
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com
 header.a=rsa-sha256 header.s=google header.b=bZs3Q2N1
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_FILL_THIS_FORM_SHORT=0.01] 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 pelocmIR5VMz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 14 Jan 2023 20:15:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4CC23607F1
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com
 [IPv6:2607:f8b0:4864:20::e32])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4CC23607F1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 14 Jan 2023 20:15:43 +0000 (UTC)
Received: by mail-vs1-xe32.google.com with SMTP id d66so13007101vsd.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 14 Jan 2023 12:15:43 -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=3RyWvYSVam3/PXIaGCdpimFhXOVxnub2IynAsbz8B60=;
 b=bZs3Q2N10UkQQ2rs4NLxeLuXX/O5AqaqTbwtpLl8Rp9w4BPA3TnZMmHjsoM8WJQyVB
 4a3J6w9wv7EKC5kI4EutqtHiqN1U25GKJCSYs5qQHk3qQ5YIgHspAGKKh+7OYpcqchEl
 KlkmiEDZ7qQcSQrXN/CNtpMaDOK0BLPlvtow5VE/nMCF3SPyyA+ZLy0sSTDjj49u+AQc
 EZL+EyuPGpI1YWwImaNTm1pADK+dsQk9UUQlPZ1CNhWEZNI40OkyBA0u9iTBKkJa9Ly4
 t1DOd/yQfrxnMZ/Dw62uCw3XAhcqbjC6zu9amV7DQnCbQVCkZ9TKdSuK1zpQ+39k0nfz
 Ka9Q==
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=3RyWvYSVam3/PXIaGCdpimFhXOVxnub2IynAsbz8B60=;
 b=f9JwrBlOFDkKt5hZDhVu50FF3piJtekT6DnYtlHbJlOidtQfOwm01cCdNFTCQc8P6F
 23UJX57190y4JISsDb2wJ1N1Xq5ccz6iBO5Q5UM+x4fdaZxZqdwzrx0iicxWZ6rT+qhP
 gWlFdDRJVTfwbf8c0d4w319laKkJpJ3IOZGiy3g/rWG54tKFKaNaIfBRh21ugaiw70x5
 UCTn0Wtnwwl/V6VQOcLDW1G7akm87wFgAG6pToO+TTjI9sGsIHDMGQErmdYYsPQOlrkB
 D1eK8U2D0ho29jgy/r/2ddnz7UddJLyIzyTlCvvDCdtHRzy8riqSjDefvQy9GP1rA9FP
 Vn5w==
X-Gm-Message-State: AFqh2kq9McdPBfzbXcdKIZcjOBFhLMuhw0HM41Pj3+9b4+FgylxW0zY/
 3u61OR1sHapo6DQpA+q4S4NBBI5Ap1xQJ0FoUk1jNA==
X-Google-Smtp-Source: AMrXdXtNFl6JIaTID73EOSuE5BQY6OEtRYRENwR/Iq573KKvvDjV8JnjrE4C+btuFDcQzL4bZ6BSNJupG9T7u39krh8=
X-Received: by 2002:a05:6102:66a:b0:3d3:c9b6:5d3f with SMTP id
 z10-20020a056102066a00b003d3c9b65d3fmr2061vsf.29.1673727341843; Sat, 14 Jan
 2023 12:15:41 -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>
 <CACkWPs_6z7UyXzejTqjy=i+SkSz-76VdzZ20K1DzcVJxan_HZg@mail.gmail.com>
 <Y8HvCbBd5+pm8Uj2@petertodd.org>
In-Reply-To: <Y8HvCbBd5+pm8Uj2@petertodd.org>
From: Daniel Lipshitz <daniel@gap600.com>
Date: Sat, 14 Jan 2023 22:15:30 +0200
Message-ID: <CACkWPs_Nqm1663c1q8xHX=A0Gpa7m1kV_QX6t0s8uPOEh3WQLA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000a969df05f23f03e5"
X-Mailman-Approved-At: Sat, 14 Jan 2023 21:04:21 +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: Sat, 14 Jan 2023 20:15:44 -0000

--000000000000a969df05f23f03e5
Content-Type: text/plain; charset="UTF-8"

On Sat, Jan 14, 2023 at 1:53 AM Peter Todd <pete@petertodd.org> wrote:

> On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
> > 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 checked and to sign up for your service, you ask for the name, phone
> number,
> email, and company name.
>
> That is an example of AML/KYC. By learning the tx hash and output address,
> you
> learn which addresses are associated with what real world entity is paying
> for
> your service. You learning that information for what you claim is ~10% of
> all
> transactions is a significant privacy concern. On that basiss alone, I
> would
> argue that full-rbf should be implemented specifically to destroy your
> business
> and stop the collection of that data.
>
> We have standard commercial information about the payment processors, non
custodial liquidity providers and merchants which become our clients - we
do not have any kyc/aml information or telephone number on who is sending
our clients the bitcoin for deposit.  For us these are just bitcoin Trx
which our clients choose to benefit from 0-conf deposit recognition. Our
service is provided via API with the only information our clients share
with us, regarding a specific bitcoin transaction, being public bitcoin
information like trx hash and output address.

> 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.
>
> No, I asked you for information on what companies are actually using *your*
> service. You claim to be involved with a huge % of all transactions. If
> that is
> in fact true, obviously it shouldn't be hard to provide some examples of
> merchants using GAP600 to accept unconfirmed txs.
>

As already posted here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html
Max CEO from Coinspaid who has provided Cpoinspaid address clusters, see
link, is available to discuss further and may choose to share further
information on the merchants they support.

>
> > 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.
>
> You are not correct. One of the most important use-cases for full-rbf is
> multi-party transactions; adding that limitation to full-rbf negates that
> usecase. See my post on why full-rbf makes DoS attacks on multiparty
> protocols
> significantly more expensive:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html


I also note that there is ongoing debate as to the need for full RBF see
here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html
.

This seems to be an extreme edge case - with Opt-in RBF, FSS Full RBF and
common sense - offering enough coverage to mitigate.

0-conf although may not be liked by some actors in Bitcoin, is engaged with
free choice and understanding of the risks. 0-conf is a long standing and
significant use case which should not be ignored. 0-conf demise should be
viewed as being a major and unnecessary cost to FullRBF as currently
implemented.

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

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_sign=
ature"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-size:12.8px"><b=
r></div></div></div></div></div><br></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 14, 2023 at 1:53 AM Peter T=
odd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Dec=
 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:<br>
&gt; GAP600 is not a trxs processor or liquidity provider we service mercha=
nts,<br>
&gt; payment processors &amp; non-custodial liquidity providers - our servi=
ce is<br>
&gt; purely the 0-conf enabling our clients to accept 0-conf. Clients acces=
s our<br>
&gt; service via API - sending us the Trx hash &amp; output address. Our se=
rvice is<br>
&gt; not based on AML/KYC it is purely an analysis of the Bitcoin network.<=
br>
<br>
I checked and to sign up for your service, you ask for the name, phone numb=
er,<br>
email, and company name.<br>
<br>
That is an example of AML/KYC. By learning the tx hash and output address, =
you<br>
learn which addresses are associated with what real world entity is paying =
for<br>
your service. You learning that information for what you claim is ~10% of a=
ll<br>
transactions is a significant privacy concern. On that basiss alone, I woul=
d<br>
argue that full-rbf should be implemented specifically to destroy your busi=
ness<br>
and stop the collection of that data.<br>
<br></blockquote><div>We have standard commercial information about the pay=
ment processors, non custodial liquidity providers and merchants which beco=
me our clients - we do not have any kyc/aml information or telephone number=
 on who is sending our clients the bitcoin for deposit.=C2=A0 For us=C2=A0t=
hese are just bitcoin Trx which our clients choose to benefit from 0-conf d=
eposit recognition. Our service is provided via API with the only informati=
on our clients share with us, regarding a specific bitcoin transaction, bei=
ng public bitcoin information like trx hash and output address.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; I am not at liberty to share names of other services which have develo=
ped<br>
&gt; their own 0-conf service - they include a payment processor on a gambl=
ing<br>
&gt; platform which services multiple gambling operators, a standalone gami=
ng<br>
&gt; payment processor, and a payment processor recently I have come across=
. We<br>
&gt; also do not have a significant presence in Asia - so I don&#39;t have<=
br>
&gt; visibility there.<br>
<br>
No, I asked you for information on what companies are actually using *your*=
<br>
service. You claim to be involved with a huge % of all transactions. If tha=
t is<br>
in fact true, obviously it shouldn&#39;t be hard to provide some examples o=
f<br>
merchants using GAP600 to accept unconfirmed txs.<br></blockquote><div><br>=
</div><div>As already posted here=C2=A0<a href=3D"https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2022-December/021240.html">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html</a> Max CE=
O from Coinspaid who has provided Cpoinspaid address clusters, see link, is=
 available to discuss further and may choose to share further information o=
n the merchants they support.=C2=A0=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
<br>
&gt; I don&#39;t see it being necessarily an either/or approach here. The r=
isk<br>
&gt; looking to be mitigated with FullRBF seems to be able to be mitigated =
with<br>
&gt; FullRBF but with a swop limitation of at least the Inputs of Trx1 bein=
g in<br>
&gt; Trx2 - no flagging required. Added to this all these trxs always have =
the<br>
&gt; OptinRBF so if these platforms need to be able to recreate completely =
their<br>
&gt; trxs they have that option as well. The option to Swop out or bump up =
trxs<br>
&gt; seems to be well covered under those two options.<br>
<br>
You are not correct. One of the most important use-cases for full-rbf is<br=
>
multi-party transactions; adding that limitation to full-rbf negates that<b=
r>
usecase. See my post on why full-rbf makes DoS attacks on multiparty protoc=
ols<br>
significantly more expensive:<br>
<br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Jan=
uary/021322.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-January/021322.html</a></blockquot=
e><div><br></div><div>I also note that there is ongoing debate as to the ne=
ed for full RBF see here=C2=A0<a href=3D"https://lists.linuxfoundation.org/=
pipermail/bitcoin-dev/2023-January/021331.html">https://lists.linuxfoundati=
on.org/pipermail/bitcoin-dev/2023-January/021331.html</a> .=C2=A0</div><div=
><br></div><div>This seems to be an extreme edge case - with Opt-in RBF, FS=
S Full RBF and common sense - offering enough coverage to mitigate.=C2=A0</=
div><div><br></div><div>0-conf although may not be liked by some actors in =
Bitcoin, is engaged with free choice and understanding of the risks. 0-conf=
 is a long standing and significant use case which should not be ignored. 0=
-conf demise should be viewed as being a major and unnecessary cost to Full=
RBF as currently implemented.<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
-- <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>

--000000000000a969df05f23f03e5--