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
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
|
Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B310AC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 15:51:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 725C641D1A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 15:51:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 725C641D1A
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=UN/Uhdy5
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level:
X-Spam-Status: No, score=-1.838 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01]
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 Q0IlCwz_Zrky
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 15:51:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F236541D06
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
[IPv6:2a00:1450:4864:20::529])
by smtp4.osuosl.org (Postfix) with ESMTPS id F236541D06
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 15:51:55 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id a67so25870611edf.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 08:51:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=Va/0eDYWP1k5v+KTymD4g6CbwoOwPTTqqBLVBXUm3D8=;
b=UN/Uhdy5/csGHNk2fCD1DwFRG4XN+0RPGUE/wDfsbAvjtG2s3Am1FzTocWUTYw7ru5
FbV8B28PZTWVb2ovNvQ6Op39zeqMl/X8mTJRK9Qw+4YRiOppJUeyxCIUbfoCf+y2eoGR
gcUPufwgvBvBvVdDOsCia3WVyQ9vDalD/ZN/vjIn+ICpHDX3Vqj3q9vOQcbpxh0eyg+j
KUFjpomR8SFM4OjYJYhD6M//6nrFolsIGQcdpLUM9XlZadf+i/Ykbp+x7HAT/q3Td2xQ
mK6ZQDAd14GyBx82IMh+5/MYL4bh25oAMWadvwUEL3a16i4qNf1sc2HsunbtpEl0LDQ/
cSAg==
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=Va/0eDYWP1k5v+KTymD4g6CbwoOwPTTqqBLVBXUm3D8=;
b=4h0vaM12fNFvcGjA45T8DTvZw+CEWw1CpJLKZ565XOiOXzL16BMPgZGp3ZuS68H5pt
Q8mV+RlErdU9p5z1IKSGpV6sYPxKyKZMUai0Cft1JkQCTS2pDjBlG+d0JdCpuAzbYUFk
YHkHiT7pZL+ftcbD2Bcdi0KbwWq02Of3wkRWDUY5J4O1G3mLW1OMR+S29xcNXcF9/k39
4SFDTvdXtfLm1JGBe587chjRYsqHX8x2Ymx6ThK3wDE7q1+PCow/hQl1axdoiuLHwsla
pOtJ7jIczqSCdXf7q8kMzIwSmeh01zFod1CX+UCOuh75C29Z7Cc5dYVm6NkemHDXwpTz
e/OA==
X-Gm-Message-State: ACrzQf0jPiE6unPv+26snWew3oRhM7lNAjqZM1mQcxYqkxA7qKZsXLA7
8F+BI97gyQenw8YYL+gEuZr/lelMSpWN/Xg+q/7XtKCC
X-Google-Smtp-Source: AMsMyM5aNBz7UewTHH/aOn8CxgaXcbS5VGWafZWNOxt/QpHPXuoHzLB/Te0FLcom9hMyQTi1O88F1UHh3hcQG+xKcXo=
X-Received: by 2002:a05:6402:d43:b0:459:b4a:18b5 with SMTP id
ec3-20020a0564020d4300b004590b4a18b5mr8307605edb.171.1666194713930; Wed, 19
Oct 2022 08:51:53 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
<CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
<CAD5xwhjFWgNTT5URX31jrULMb-iTxWih7673tpueD10AGbV=Gg@mail.gmail.com>
In-Reply-To: <CAD5xwhjFWgNTT5URX31jrULMb-iTxWih7673tpueD10AGbV=Gg@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 19 Oct 2022 11:51:41 -0400
Message-ID: <CAB3F3DtuewSY=A6u2iKs=5gTwNiJHuYds70cCk-h8VESYTc_rA@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000cf17c05eb6530dc"
Cc: Sergej Kotliar <sergej@bitrefill.com>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
danger
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: Wed, 19 Oct 2022 15:51:59 -0000
--0000000000000cf17c05eb6530dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Isn't the extreme of this that the merchant tries to lock in gains on the
upswing via CPFP, and users on the downswing, both doing scorched earth,
tossing the delta to fees?
Seems like a MAD situation?
On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If they do this to you, and the delta is substantial, can't you sweep all
> such abusers with a cpfp transaction replacing their package and giving y=
ou
> the original txn?
>
> On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about =
the
>> zero-conf (I'll get to that) but there is an even bigger danger called t=
he
>> american call option, which risks endangering the entirety of BIP21 "Sca=
n
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF wou=
ld
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD move=
s
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens ou=
t
>> in the end. But if there is an _easily accessible in the wallet_ feature=
to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on many payments that's easy to systematically
>> abuse is more scary than a rare risk of losing 100% of one occasional
>> payment. It's already possible to execute this form of abuse with opt-in
>> RBF, which may lead to us at some point refusing those payments (even wi=
th
>> confirmation) or cumbersome UX to work around it, such as crediting the
>> bitcoin to a custodial account.
>>
>> To compare zeroconf risk with FX risk: I think we've had one incident in
>> 8 years of operation where a user successfully fooled our server to acce=
pt
>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>> zeroconf one needs to have access to mining infrastructure and probabili=
ty
>> of success is the % of hash rate controlled. This is simply due to the f=
act
>> that the network currently won't propagage the replacement transaction t=
o
>> the miner, which is what's being discussed here. American call option ri=
sk
>> would however be available to 100% of all users, needs nothing beyond th=
e
>> wallet app, and has no cost to the user - only upside.
>>
>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>> us, a world where bitcoin becomes de facto RBF by default, means that we
>> would likely turn off the BIP21 model for onchain payments, instruct
>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>> account that we have.
>> This option is however not available for your typical
>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>> from other merchants or payment providers how they see this new behavior
>> and how they would counteract it.
>>
>> Currently Lightning is somewhere around 15% of our total bitcoin
>> payments. This is very much not nothing, and all of us here want Lightni=
ng
>> to grow, but I think it warrants a serious discussion on whether we want
>> Lightning adoption to go to 100% by means of disabling on-chain commerce=
.
>> For me personally it would be an easier discussion to have when Lightnin=
g
>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>> users simply don't have access to Lightning, and of those that do and ho=
ld
>> their own keys Muun is the biggest wallet per our data, not least due to
>> their ease-of-use which is under threat per the OP. It's hard to assess =
how
>> many users would switch to Lightning in such a scenario, the communicati=
on
>> around it would be hard. My intuition says that the majority of the curr=
ent
>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore=
,
>> probably shift to an alt. The benefits of Lightning are many and obvious=
,
>> we don't need to limit onchain to make Lightning more appealing. As an
>> anecdote, we did experiment with defaulting to bech32 addresses some yea=
rs
>> back. The result was that simply users of the wallets that weren't able =
to
>> pay to bech32 didn't complete the purchase, no support ticket or anythin=
g,
>> just "it didn't work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F" and user m=
oved on. We rolled it back, and later
>> implemented a wallet selector to allow modern wallets to pay to bech32
>> while other wallets can pay to P2SH. This type of thing is clunky, and
>> requires a certain level of scale to be able to do, we certainly wouldn'=
t
>> have had the manpower for that when we were starting out. This why I'm
>> cautious about introducing more such clunkiness vectors as they are
>> centralizing factors.
>>
>> I'm well aware of the reason for this policy being suggested and the
>> potential pinning attack vector for LN and other smart contracts, but I
>> think these two risks/costs need to be weighed against eachother first a=
nd
>> thoroughly discussed because the costs are non-trivial on both sides.
>>
>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> After interacting with users during high-fee periods I've come to not
>> appreciate RBF as a solution to that issue. Most users (80% or so) simpl=
y
>> don't have access to that functionality, because their wallet doesn't
>> support it, or they use a custodial (exchange) wallet etc. Of those that
>> have the feature - only the power users understand how RBF works, and
>> explaining how to do RBF to a non-power-user is just too complex, for th=
e
>> same reason why it's complex for wallets to make sensible non-power-user=
UI
>> around it. Current equilibrium is that mostly only power users have acce=
ss
>> to RBF and they know how to handle it, so things are somewhat working. B=
ut
>> rolling this out to the broad market is something else and would likely
>> cause more confusion.
>> CPFP is somewhat more viable but also not perfect as it would require
>> lots of edge case code to handle abuse vectors: What if users abuse a
>> generous CPFP policy to unstuck past transactions or consolidate large
>> wallets. Best is for CPFP to be done on the wallet side, not the merchan=
t
>> side, but there too are the same UX issues as with RBF.
>> In the end a risk-based approach to decide on which payments are
>> non-trivial to reverse is the easiest, taking account user experience an=
d
>> such. Remember that in the fiat world card payments have up to 5%
>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer th=
an
>> 1 in a million" accepted transactions successfully reversed. These days =
we
>> have very few support issues related to bitcoin payments. The few that d=
o
>> come in are due to accidental RBF users venting frustration about waitin=
g
>> for their tx to confirm.
>> "In theory, theory and practice are the same. In practice, they are not"
>>
>> All the best,
>> Sergej Kotliar
>> CEO Bitrefill.com
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000000cf17c05eb6530dc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Isn't the extreme of this that the merchant tries to l=
ock in gains on the upswing via CPFP, and users on the downswing, both doin=
g scorched earth, tossing the delta to fees?<div><br></div><div>Seems like =
a MAD situation?</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
class=3D"gmail_attr">On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bit=
coin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<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"><div dir=3D"auto">If they=
do this to you, and the delta is substantial, can't you sweep all such=
abusers with a cpfp transaction replacing their package and giving you the=
original txn?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-de=
v <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><div dir=3D"ltr">Hi all,<div><br></div><div>Chiming in on this =
thread as I feel like the real dangers of RBF as default policy aren't =
sufficiently elaborated here. It's not only about the zero-conf (I'=
ll get to that) but there is an even bigger danger called the american call=
option, which risks endangering the entirety of BIP21 "Scan this QR c=
ode with your wallet to buy this product" model that I believe we'=
ve all come to appreciate. Specifically, in a scenario with high volatility=
and many transactions in the mempools (which is where RBF would come in ha=
ndy), a user can make a low-fee transaction and then wait for hours, days o=
r even longer, and see whether BTCUSD moves. If BTCUSD moves up, user can c=
ancel his transaction and make a new - cheaper one. The biggest risk in acc=
epting bitcoin payments is in fact not zeroconf risk (it's actually qui=
te easily managed), it's FX risk as the merchant must commit to a certa=
in BTCUSD rate ahead of time for a purchase. Over time some transactions lo=
se money to FX and others earn money - that evens out in the end. But if th=
ere is an _easily accessible in the wallet_ feature to "cancel transac=
tion" that means it will eventually get systematically abused. A risk =
of X% loss on many payments that's easy to systematically abuse is more=
scary than a rare risk of losing 100% of one occasional payment. It's =
already possible to execute this form of abuse with opt-in RBF, which may l=
ead to us at some point refusing those payments (even with confirmation) or=
cumbersome UX to work around it, such as crediting the bitcoin to a custod=
ial account.</div><div><br></div><div>To compare zeroconf risk with FX risk=
: I think we've had one incident in 8 years of operation where a user s=
uccessfully fooled our server to accept a payment that in the end didn'=
t confirm. To successfully fool (non-RBF) zeroconf one needs to have access=
to mining infrastructure and probability of success is the % of hash rate =
controlled. This is simply due to the fact that the network currently won&#=
39;t propagage the replacement transaction to the miner, which is what'=
s being discussed here. American call option risk would however be availabl=
e to 100% of all users, needs nothing beyond the wallet app, and has no cos=
t to the user - only upside.<br></div><div><br></div><div>Bitrefill current=
ly processes 1500-2000 onchain payments every day. For us, a world where bi=
tcoin becomes de facto RBF by default, means that we would likely turn off =
the BIP21 model for onchain payments, instruct Bitcoin users to use Lightni=
ng or deposit onchain BTC to a custodial account that we have.=C2=A0<br></d=
iv><div>This option is however not available for your typical BTCPayServer/=
CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear from other merc=
hants or payment providers how they see this new behavior and how they woul=
d counteract it.</div><div><br></div><div>Currently Lightning is somewhere =
around 15% of our total bitcoin payments. This is very much not nothing, an=
d all of us here want Lightning to grow, but I think it warrants a serious =
discussion on whether we want Lightning adoption to go to 100% by means of =
disabling on-chain commerce. For me personally it would be an easier discus=
sion to have when Lightning is at 80%+ of all bitcoin transactions. Current=
ly far too many bitcoin users simply don't have access to Lightning, an=
d of those that do and hold their own keys Muun is the biggest wallet per o=
ur data, not least due to their ease-of-use which is under threat per the O=
P. It's hard to assess how many users would switch to Lightning in such=
a scenario, the communication around it would be hard. My intuition says t=
hat the majority of the current 85% of bitcoin users that pay onchain would=
just not use bitcoin anymore, probably shift to an alt. The benefits of Li=
ghtning are many and obvious, we don't need to limit onchain to make Li=
ghtning more appealing. As an anecdote, we did experiment with defaulting t=
o bech32 addresses some years back. The result was that simply users of the=
wallets that weren't able to pay to bech32 didn't complete the pur=
chase, no support ticket or anything, just "it didn't work =F0=9F=
=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F" and user moved on. We rolled it bac=
k, and later implemented a wallet selector to allow modern wallets to pay t=
o bech32 while other wallets can pay to P2SH. This type of thing=C2=A0 is c=
lunky, and requires a certain level of scale to be able to do, we certainly=
wouldn't have had the manpower for that when we were starting out. Thi=
s why I'm cautious about introducing more such clunkiness vectors as th=
ey are centralizing factors.</div><div><br></div><div>I'm well aware of=
the reason for this policy being suggested and the potential pinning attac=
k vector for LN and other smart contracts, but I think these two risks/cost=
s need to be weighed against eachother first and thoroughly discussed becau=
se the costs are non-trivial on both sides.<br clear=3D"all"><div><br></div=
><div>Sidenote: On the efficacy of RBF to "unstuck" stuck transac=
tions</div><div>After interacting with users during high-fee periods I'=
ve come to not appreciate RBF as a solution to that issue. Most users (80% =
or so) simply don't have access to that functionality, because their wa=
llet doesn't support it, or they use a custodial (exchange) wallet etc.=
Of those that have the feature - only the power users understand how RBF w=
orks, and explaining how to do RBF to a non-power-user is just too complex,=
for the same reason why it's complex for wallets to make sensible non-=
power-user UI around it. Current equilibrium is that mostly only power user=
s have access to RBF and they know how to handle it, so things are somewhat=
working. But rolling this out to the broad market is something else and wo=
uld likely cause more confusion.=C2=A0</div><div>CPFP is somewhat more viab=
le but also not perfect as it would require lots of edge case code to handl=
e abuse vectors: What if users abuse a generous CPFP policy to unstuck past=
transactions or consolidate large wallets. Best is for CPFP to be done on =
the wallet side, not the merchant side, but there too are the same UX issue=
s as with RBF.=C2=A0</div><div>In the end a risk-based approach to decide o=
n which payments are non-trivial to reverse is the easiest, taking account =
user experience and such. Remember that in the fiat world card payments hav=
e up to 5% chargebacks, whereas we in zero-conf bitcoin land we deal with &=
quot;fewer than 1 in a million" accepted transactions successfully rev=
ersed. These days we have very few support issues related to bitcoin paymen=
ts. The few that do come in are due to accidental RBF users venting frustra=
tion about waiting for their tx to confirm.</div><div>"In theory, theo=
ry and practice are the same. In practice, they are not"</div><div><br=
></div><div>All the best,=C2=A0</div><div>Sergej Kotliar</div><div>CEO Bitr=
efill.com</div><div><br></div><div><br></div>-- <br><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><di=
v dir=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,=
0,0);background-color:transparent;font-weight:700;font-style:normal;font-va=
riant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-w=
rap">Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Ar=
ial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-styl=
e:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;w=
hite-space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38=
;margin-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b>=
</p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,102,102);=
background-color:transparent;font-weight:700;font-style:normal;font-variant=
:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=
<span style=3D"border:none;display:inline-block;overflow:hidden;width:220px=
;height:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o3P=
52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdM=
fBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" width=3D"220" height=3D"80"=
style=3D"margin-left: 0px; margin-top: 0px;"></span></span></p><p dir=3D"l=
tr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-col=
or:transparent;font-weight:400;font-style:normal;font-variant:normal;text-d=
ecoration:none;vertical-align:baseline;white-space:pre-wrap">Twitter: @</sp=
an><a href=3D"https://twitter.com/ziggamon" style=3D"text-decoration:none" =
rel=3D"noreferrer" target=3D"_blank"><span style=3D"font-size:9.5pt;font-fa=
mily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:=
400;font-style:normal;font-variant:normal;text-decoration:underline;vertica=
l-align:baseline;white-space:pre-wrap">ziggamon</span></a><span style=3D"fo=
nt-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tra=
nsparent;font-weight:400;font-style:normal;font-variant:normal;text-decorat=
ion:none;vertical-align:baseline;white-space:pre-wrap">=C2=A0</span></p><p =
dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b =
style=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-heigh=
t:1.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http://www.bitrefill.co=
m/" style=3D"text-decoration:none" rel=3D"noreferrer" target=3D"_blank"><sp=
an style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgr=
ound-color:transparent;font-weight:400;font-style:normal;font-variant:norma=
l;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">w=
ww.bitrefill.com</span></a></p><p dir=3D"ltr" style=3D"line-height:1.38;mar=
gin-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitter.com/bitrefill=
" rel=3D"noreferrer" target=3D"_blank"><span style=3D"font-size:9.5pt;font-=
family:Arial;color:rgb(102,102,102);background-color:transparent;vertical-a=
lign:baseline;white-space:pre-wrap">Twitter</span></a><span style=3D"font-s=
ize:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpa=
rent;vertical-align:baseline;white-space:pre-wrap"> | </span><a href=3D"htt=
ps://www.bitrefill.com/blog/" rel=3D"noreferrer" target=3D"_blank"><span st=
yle=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-=
color:transparent;vertical-align:baseline;white-space:pre-wrap">Blog</span>=
</a><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102)=
;background-color:transparent;vertical-align:baseline;white-space:pre-wrap"=
> | </span><a href=3D"https://angel.co/bitrefill" rel=3D"noreferrer" target=
=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,=
102,102);background-color:transparent;vertical-align:baseline;white-space:p=
re-wrap">Angellist </span></a><br></p></div></div></div></div></div></div><=
/div></div></div></div></div></div></div>
</div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"><div dir=3D"=
ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot=
tom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);=
background-color:transparent;font-weight:700;font-style:normal;font-variant=
:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=
Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;c=
olor:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:nor=
mal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-=
space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><=
p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><=
span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;font-weight:700;font-style:normal;font-variant:norm=
al;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><span=
style=3D"border:none;display:inline-block;overflow:hidden;width:220px;heig=
ht:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o3P52cUT=
KrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRN=
hsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" width=3D"220" height=3D"80" styl=
e=3D"margin-left: 0px; margin-top: 0px;"></span></span></p><p dir=3D"ltr" s=
tyle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"f=
ont-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tr=
ansparent;font-weight:400;font-style:normal;font-variant:normal;text-decora=
tion:none;vertical-align:baseline;white-space:pre-wrap">Twitter: @</span><a=
href=3D"https://twitter.com/ziggamon" style=3D"text-decoration:none" rel=
=3D"noreferrer" target=3D"_blank"><span style=3D"font-size:9.5pt;font-famil=
y:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:400=
;font-style:normal;font-variant:normal;text-decoration:underline;vertical-a=
lign:baseline;white-space:pre-wrap">ziggamon</span></a><span style=3D"font-=
size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transp=
arent;font-weight:400;font-style:normal;font-variant:normal;text-decoration=
:none;vertical-align:baseline;white-space:pre-wrap">=C2=A0</span></p><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b sty=
le=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1=
.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http://www.bitrefill.com/"=
style=3D"text-decoration:none" rel=3D"noreferrer" target=3D"_blank"><span =
style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgroun=
d-color:transparent;font-weight:400;font-style:normal;font-variant:normal;t=
ext-decoration:underline;vertical-align:baseline;white-space:pre-wrap">www.=
bitrefill.com</span></a></p><p dir=3D"ltr" style=3D"line-height:1.38;margin=
-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitter.com/bitrefill" r=
el=3D"noreferrer" target=3D"_blank"><span style=3D"font-size:9.5pt;font-fam=
ily:Arial;color:rgb(102,102,102);background-color:transparent;vertical-alig=
n:baseline;white-space:pre-wrap">Twitter</span></a><span style=3D"font-size=
:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transparen=
t;vertical-align:baseline;white-space:pre-wrap"> | </span><a href=3D"https:=
//www.bitrefill.com/blog/" rel=3D"noreferrer" target=3D"_blank"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-col=
or:transparent;vertical-align:baseline;white-space:pre-wrap">Blog</span></a=
><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);ba=
ckground-color:transparent;vertical-align:baseline;white-space:pre-wrap"> |=
</span><a href=3D"https://angel.co/bitrefill" rel=3D"noreferrer" target=3D=
"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102=
,102);background-color:transparent;vertical-align:baseline;white-space:pre-=
wrap">Angellist </span></a><br></p></div></div></div></div></div></div></di=
v></div></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000000cf17c05eb6530dc--
|