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
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
|
Return-Path: <sergej@bitrefill.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 89FB0C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 14:12:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 657C36FAEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 14:12:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 657C36FAEA
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=bitrefill.com header.i=@bitrefill.com
header.a=rsa-sha256 header.s=b header.b=Wvx+BLb9
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_KAM_HTML_FONT_INVALID=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 kGnLbj7JL0tt
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 14:12:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C46776FAE7
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
[IPv6:2a00:1450:4864:20::232])
by smtp3.osuosl.org (Postfix) with ESMTPS id C46776FAE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 14:12:02 +0000 (UTC)
Received: by mail-lj1-x232.google.com with SMTP id r22so26539781ljn.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 07:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitrefill.com; s=b;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=wTRFKGRIQJa3PLj/f2yq00dojOAJ4ghsOcC5NR72Eik=;
b=Wvx+BLb9xyBczPPwbicE/QkFHBQZdE5asWVaL+HimqKCM2Gb8KiJHysi/6iJzJzrmj
vWUVL9XRAZsmtfTfJ3k3snw5NXGvXpDsJxiDIIbgwIi5TlY1ZubUIXOx5Gv8V464509Z
fcMytnDNHHZKeSgDHYf2Wpdrq+cc1C8TZvVMEtg5ADfbShAU4i2Tf1fLV7biZJihgCZx
sc8/fChsR+zA+cI29c7K9vQjjRbWr/oXbvqxbFXgwhLIWNY7qqSMXv5DNWVHtZlZFfTX
wvKV6nNmvd3TJQBrPGSoi6FlAOujSon7dl4P7p+Al1ZfQ/iHmGOigMG8tJ0030sLMiJi
6bBg==
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=wTRFKGRIQJa3PLj/f2yq00dojOAJ4ghsOcC5NR72Eik=;
b=8QL1ssiTj0tSXoFwRiLx60inJMQgEAyKYiVEI8OAF0mIZNWdXM+PXYjwjxAD7U9/Pd
l8ksLMr+80h82fuMIneZcUoIzJzGnYnTIz4Nv7tAfa0Q/u7VBxjH0fK43SVVgq0QqmXR
ajJ3ylGGKjyEutiqLSibV2Crf/eWU+PlLXbUukyxpMPjK73i+WOeednVXEwVHBD4qxhZ
jKdWhg5JJ7VCWbZsipcmWXkYRIEy+4fMRkQqtmjCHB5n0/EvU+WbCSldbXa5i1CdjqTD
VBF9bmSEgDSRuKL/1wcQ72cE45p2Hx1NsXesgLGrXP1k1AzfuA6eosxAix4VQjicbQfS
OtUA==
X-Gm-Message-State: ACrzQf2A8RmoaW2+S7SDmijMryRdykMewWgsxyOf0F4AzNMnUJ96nnfn
EadT3//8NADpVLDMAbJHojqbfpj+hmHofdRmAsVHEc7sGNw=
X-Google-Smtp-Source: AMsMyM6NmucHjhKLTyfuXetrHPIKdOHi5XFBdLqeFJwTZRcIvY/GoGFChKjD3G5LEFw3S2hrum9VWYj8t064Jw0uIR4=
X-Received: by 2002:a2e:b8ca:0:b0:26f:c7a1:577a with SMTP id
s10-20020a2eb8ca000000b0026fc7a1577amr5274794ljp.77.1666275120523; Thu, 20
Oct 2022 07:12:00 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
<CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
<CALZpt+ELLFMJstnTxUjKR6Q2OD-xuLTkt4q3BCHUHyz7NV123w@mail.gmail.com>
In-Reply-To: <CALZpt+ELLFMJstnTxUjKR6Q2OD-xuLTkt4q3BCHUHyz7NV123w@mail.gmail.com>
From: Sergej Kotliar <sergej@bitrefill.com>
Date: Thu, 20 Oct 2022 16:11:48 +0200
Message-ID: <CABZBVTBMoYJqBP8_4kOybdYoxYePfPJYSP=HO7NEjTfD-QeM7Q@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a83e3f05eb77e8d4"
X-Mailman-Approved-At: Thu, 20 Oct 2022 14:15:19 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 20 Oct 2022 14:12:06 -0000
--000000000000a83e3f05eb77e8d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard@gmail.com> wrote=
:
> Hi Sergej,
>
> Thanks for the insightful posting, especially highlighting the FX risk
> which was far from being evident on my side!
>
> I don't know in details the security architecture of Bitrefill zeroconf
> acceptance system, though from what I suppose there is at least a set of
> full-nodes well-connected across the p2p network, on top of which some
> mempools reconciliation is exercised
> and zeroconf candidate sanitize against. While I believe this is a
> far-more robust deployment against double-spend attempts, there is still
> the ability for a sophisticated attacker to "taint" miner mempools, and
> from then partition judiciously the transaction-relay network to game suc=
h
> distributed mempool monitoring system. There is also the possibility of a=
n
> attacker using some "divide-and-conquer" transaction broadcast algorithm =
to
> map Bitrefill monitoring point, though as far as I'm aware such algorithm
> has not been discussed. I agree with all of that, easier said than done.
>
There is a long list of countermeasures that can be built to reduce these
attacks, but to be frank we've only implemented a small subset of these and
not had any issues, so even a lower level of security is more than fine
today to have basically zero abuse. If issues arise we could implement more
of the countermeasures as appropriate to the abuse that has happened in the
wild.
> On the efficacy of RBF, I understand the current approach of assuming
> "manual" RBFing by power users ill UX thinking. I hope in the future to
> have automatic fee-bumping implemented by user wallets, where a fee-bumpi=
ng
> budget and a confirmation preference are pre-defined for all payments, an=
d
> the fee-bumping logic "simply" enforcing the user policy, ideally based o=
n
> historical mempool data. True fact: we don't have such logic in consumer
> wallets today.
>
In deed. And the vast majority of bitcoin users don't even have access to
any RBF functionality today, so we're not even seeing gradual development
of these things yet. I think this fact needs to be taken into account when
designing breaking changes to bitcoin policy. Had these things been in
place and widely used the conversation would have been much easier.
Fundamentally, my view is that all the UX problems related to RBF alone are
sufficient of an issue to hold off on rolling out these upgrades for the
foreseeable future and think of other ways of solving the pinning issue and
other issues w the current policy. Might be that it's just a fundamental
goal conflict that different people want different behavior but I remain
optimistic for creative solutions from both sides. UX issues are soft as
opposed to theoretical attack vectors which are hard and binary, we need
find a way to weigh "even though it doesn't happen it can theoretically be
hacked" against "many users find it confusing and stressful" which is not a
trivial assessment to do.
All that said, I learn to converge that as a community we would be better
> off to weigh deeper the risks/costs between 0confs applications and
> contracting protocols in light of full-rbf.
>
In deed. And as you wrote in a different message, I agree that it's
unfortunate that there isn't more interaction between the mailing list and
services and companies using this stuff day-to-day. Not that it's anyone's
fault in particular, let's try from all sides to find more ways to create
more interaction on these topics. I've pinged a few colleagues that work on
payments in the space and hope they will chime in more in this forum!
All the best,
Sergej
> Le mer. 19 oct. 2022 =C3=A0 10:33, Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> 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
>>
>
--=20
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>
--000000000000a83e3f05eb77e8d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, 20 Oct 2022 at 03:37, Antoine=
Riard <<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.c=
om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">Hi Sergej,<br><br>Thanks for the insightful posting, esp=
ecially highlighting the FX risk which was far from being evident on my sid=
e!<br><br>I don't know in details the security architecture of Bitrefil=
l zeroconf acceptance system, though from what I suppose there is at least =
a set of full-nodes well-connected across the p2p network, on top of which =
some mempools reconciliation is exercised<br>and zeroconf candidate sanitiz=
e against. While I believe this is a far-more robust deployment against dou=
ble-spend attempts, there is still the ability for a sophisticated attacker=
to "taint" miner mempools, and from then partition judiciously t=
he transaction-relay network to game such distributed mempool monitoring sy=
stem. There is also the possibility of an attacker using some "divide-=
and-conquer" transaction broadcast algorithm to map Bitrefill monitori=
ng point, though as far as I'm aware such algorithm has not been discus=
sed. I agree with all of that, easier said than done.<br></div></blockquote=
><div><br></div><div>There is a long list of countermeasures that can be bu=
ilt to reduce these attacks, but to be frank we've only implemented a s=
mall subset of these and not had any issues, so even a lower level of secur=
ity is more than fine today to have basically zero abuse. If issues arise w=
e could implement more of the countermeasures as appropriate to the abuse t=
hat has happened in the wild.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr">On the efficacy of RBF, I under=
stand the current approach of assuming "manual" RBFing by power u=
sers ill UX thinking. I hope in the future to have automatic fee-bumping im=
plemented by user wallets, where a fee-bumping budget and a confirmation pr=
eference are pre-defined for all payments, and the fee-bumping logic "=
simply" enforcing the user policy, ideally based on historical mempool=
data. True fact: we don't have such logic in consumer wallets today. <=
/div></blockquote><div><br></div><div>In deed. And the vast majority of bit=
coin users don't even have access to any RBF functionality today, so we=
're not even seeing gradual development of these things yet. I think th=
is fact needs to be taken into account when designing breaking changes to b=
itcoin policy. Had these things been in place and widely used the conversat=
ion would have been much easier.</div><div>=C2=A0</div><div>Fundamentally, =
my view is that all the UX problems related to RBF alone are sufficient of =
an issue to hold off on rolling out these upgrades for the foreseeable futu=
re and think of other ways of solving the pinning issue and other issues w =
the current policy. Might be that it's just a fundamental goal conflict=
that different people want different behavior but I remain optimistic for =
creative solutions from both sides. UX issues are soft as opposed to theore=
tical attack vectors which are hard and binary, we need find=C2=A0a way to =
weigh "even though it doesn't happen it can theoretically be hacke=
d" against "many users find it confusing and stressful" whic=
h is not a trivial assessment to do.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">All that said, I learn to=
converge that as a community we would be better off to weigh deeper the ri=
sks/costs between 0confs applications and contracting protocols in light of=
full-rbf.<br></div></blockquote><div><br></div><div>In deed. And as you wr=
ote in a different message, I agree that it's unfortunate that there is=
n't more interaction between the mailing list and services and companie=
s using this stuff day-to-day. Not that it's anyone's fault in part=
icular, let's try from all sides to find more ways to create more inter=
action on these topics. I've pinged a few colleagues that work on payme=
nts in the space and hope they will chime in more in this forum!</div><div>=
<br></div><div>All the best,</div><div>Sergej</div><div>=C2=A0</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 class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 19 oct. 2022 =C3=A0=C2=A010:3=
3, Sergej Kotliar via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">H=
i 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 a=
n even bigger danger called the american call option, which risks endangeri=
ng the entirety of BIP21 "Scan this QR code with your wallet to buy th=
is product" model that I believe we've all come to appreciate. Spe=
cifically, in a scenario with high volatility and many transactions in the =
mempools (which is where RBF would come in handy), a user can make a low-fe=
e transaction and then wait for hours, days or even longer, and see whether=
BTCUSD moves. If BTCUSD moves 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 F=
X risk as the merchant must commit to a certain BTCUSD rate ahead of time f=
or a purchase. Over time some transactions lose money to FX and others earn=
money - that evens out in the end. But if there is an _easily accessible i=
n the wallet_ feature to "cancel transaction" that means it will =
eventually get systematically abused. A risk of X% loss on many payments th=
at's easy to systematically abuse is more scary than a rare risk of los=
ing 100% of one occasional payment. It's already possible to execute th=
is form of abuse with opt-in RBF, which may lead to us at some point refusi=
ng those payments (even with confirmation) or cumbersome UX to work around =
it, such as crediting the bitcoin to a custodial account.</div><div><br></d=
iv><div>To compare zeroconf risk with FX risk: I think we've had one in=
cident in 8 years of operation where a user successfully fooled our server =
to accept a payment that in the end didn't confirm. To successfully foo=
l (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't propagage the replacement=
transaction to the miner, which is what's being discussed here. Americ=
an call option risk would however be available to 100% of all users, needs =
nothing beyond the wallet app, and has no cost to the user - only upside.<b=
r></div><div><br></div><div>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 pa=
yments, instruct Bitcoin users to use Lightning or deposit onchain BTC to a=
custodial account that we have.=C2=A0<br></div><div>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.</div><div><br=
></div><div>Currently Lightning is somewhere around 15% of our total bitcoi=
n payments. This is very much not nothing, and all of us here want Lightnin=
g 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. F=
or me personally it would be an easier discussion to have when Lightning 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 hold th=
eir own keys Muun is the biggest wallet per our data, not least due to thei=
r 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 communication=
around it would be hard. My intuition says that the majority of the curren=
t 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 years =
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 an=
ything, 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 back, and later implemented a wal=
let selector to allow modern wallets to pay to bech32 while other wallets c=
an pay to P2SH. This type of thing=C2=A0 is clunky, and requires a certain =
level of scale to be able to do, we certainly wouldn't have had the man=
power for that when we were starting out. This why I'm cautious about i=
ntroducing more such clunkiness vectors as they are centralizing factors.</=
div><div><br></div><div>I'm well aware of the reason for this policy be=
ing suggested and the potential pinning attack vector for LN and other smar=
t contracts, but I think these two risks/costs need to be weighed against e=
achother first and thoroughly discussed because the costs are non-trivial o=
n both sides.<br clear=3D"all"><div><br></div><div>Sidenote: On the efficac=
y of RBF to "unstuck" stuck transactions</div><div>After interact=
ing 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 a=
ccess to that functionality, because their wallet doesn't support it, o=
r they use a custodial (exchange) wallet etc. Of those that have the featur=
e - only the power users understand how RBF works, and explaining how to do=
RBF to a non-power-user is just too complex, for the same reason why it=
9;s complex for wallets to make sensible non-power-user UI around it. Curre=
nt equilibrium is that mostly only power users 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 would likely cause more confusio=
n.=C2=A0</div><div>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 l=
arge wallets. Best is for CPFP to be done on the wallet side, not the merch=
ant side, but there too are the same UX issues as with RBF.=C2=A0</div><div=
>In the end a risk-based approach to decide on which payments are non-trivi=
al to reverse is the easiest, taking account user experience and such. Reme=
mber that in the fiat world card payments have up to 5% chargebacks, wherea=
s we in zero-conf bitcoin land we deal with "fewer than 1 in a million=
" accepted transactions successfully reversed. These days we have very=
few support issues related to bitcoin payments. The few that do come in ar=
e due to accidental RBF users venting frustration about waiting for their t=
x to confirm.</div><div>"In theory, theory 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 Bitrefill.com</div><div><br></di=
v><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"><div dir=3D"ltr"><div di=
r=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-bottom:0pt"><span style=3D=
"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transp=
arent;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-top:0pt;margin-bottom:0pt=
"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);backgro=
und-color:transparent;font-weight:700;font-style:normal;font-variant:normal=
;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">CEO</sp=
an></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-botto=
m: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);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:medium=
none;display:inline-block;overflow:hidden;width:220px;height:80px"><img sr=
c=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXlu=
ijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-=
gPxDui-4l0tZI1QcjtefCDkNG" style=3D"margin-left: 0px; margin-top: 0px;" wid=
th=3D"220" height=3D"80"></span></span></p><p dir=3D"ltr" style=3D"line-hei=
ght:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;f=
ont-family:Arial;color:rgb(102,102,102);background-color:transparent;font-w=
eight:400;font-style:normal;font-variant:normal;text-decoration:none;vertic=
al-align:baseline;white-space:pre-wrap">Twitter: @</span><a href=3D"https:/=
/twitter.com/ziggamon" style=3D"text-decoration:none" 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">z=
iggamon</span></a><span style=3D"font-size:9.5pt;font-family:Arial;color:rg=
b(102,102,102);background-color:transparent;font-weight:400;font-style:norm=
al;font-variant:normal;text-decoration:none;vertical-align:baseline;white-s=
pace:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"line-height:1.38;ma=
rgin-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"=
><a href=3D"http://www.bitrefill.com/" style=3D"text-decoration:none" targe=
t=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102=
,102,102);background-color:transparent;font-weight:400;font-style:normal;fo=
nt-variant:normal;text-decoration:underline;vertical-align:baseline;white-s=
pace: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.twitt=
er.com/bitrefill" 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/" target=3D"_blank"><span style=3D"font-size:9.5pt=
;font-family:Arial;color:rgb(102,102,102);background-color:transparent;vert=
ical-align:baseline;white-space:pre-wrap">Blog</span></a><span style=3D"fon=
t-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tran=
sparent;vertical-align:baseline;white-space:pre-wrap"> | </span><a href=3D"=
https://angel.co/bitrefill" target=3D"_blank"><span style=3D"font-size:9.5p=
t;font-family:Arial;color:rgb(102,102,102);background-color:transparent;ver=
tical-align:baseline;white-space:pre-wrap">Angellist </span></a><br></p></d=
iv></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:medium none;display:inline-block;overflow:hidden;width:220=
px;height:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o=
3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCW=
dMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" style=3D"margin-left: 0px=
; margin-top: 0px;" width=3D"220" height=3D"80"></span></span></p><p dir=3D=
"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span sty=
le=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-c=
olor:transparent;font-weight:400;font-style:normal;font-variant:normal;text=
-decoration:none;vertical-align:baseline;white-space:pre-wrap">Twitter: @</=
span><a href=3D"https://twitter.com/ziggamon" style=3D"text-decoration:none=
" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:=
rgb(102,102,102);background-color:transparent;font-weight:400;font-style:no=
rmal;font-variant:normal;text-decoration:underline;vertical-align:baseline;=
white-space:pre-wrap">ziggamon</span></a><span style=3D"font-size:9.5pt;fon=
t-family:Arial;color:rgb(102,102,102);background-color:transparent;font-wei=
ght: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 style=3D"font-wei=
ght: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" target=3D"_blank"><span style=3D"font-size:9.5pt;font-fam=
ily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:4=
00;font-style:normal;font-variant:normal;text-decoration:underline;vertical=
-align:baseline;white-space:pre-wrap">www.bitrefill.com</span></a></p><p di=
r=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a hr=
ef=3D"https://www.twitter.com/bitrefill" target=3D"_blank"><span style=3D"f=
ont-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tr=
ansparent;vertical-align:baseline;white-space:pre-wrap">Twitter</span></a><=
span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);back=
ground-color:transparent;vertical-align:baseline;white-space:pre-wrap"> | <=
/span><a href=3D"https://www.bitrefill.com/blog/" target=3D"_blank"><span s=
tyle=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" target=3D"_blank"><span =
style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgroun=
d-color:transparent;vertical-align:baseline;white-space:pre-wrap">Angellist=
</span></a><br></p></div></div></div></div></div></div></div></div></div><=
/div></div></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>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div 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-bottom:0pt"><span style=3D"font-size:9.5=
pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-wei=
ght:700;font-style:normal;font-variant:normal;text-decoration:none;vertical=
-align:baseline;white-space:pre-wrap">Sergej Kotliar</span></p><p dir=3D"lt=
r" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:tra=
nsparent;font-weight:700;font-style:normal;font-variant:normal;text-decorat=
ion:none;vertical-align:baseline;white-space:pre-wrap">CEO</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"><span style=3D"font-size:11pt;font-fa=
mily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:=
700;font-style:normal;font-variant:normal;text-decoration:none;vertical-ali=
gn:baseline;white-space:pre-wrap"><span style=3D"border:none;display:inline=
-block;overflow:hidden;width:220px;height:80px"><img src=3D"https://lh4.goo=
gleusercontent.com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_z=
OQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1Qcjtef=
CDkNG" width=3D"220" height=3D"80" style=3D"margin-left: 0px; margin-top: 0=
px;"></span></span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;col=
or:rgb(102,102,102);background-color:transparent;font-weight:400;font-style=
:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;wh=
ite-space:pre-wrap">Twitter: @</span><a href=3D"https://twitter.com/ziggamo=
n" style=3D"text-decoration:none" target=3D"_blank"><span style=3D"font-siz=
e:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpare=
nt;font-weight:400;font-style:normal;font-variant:normal;text-decoration:un=
derline;vertical-align:baseline;white-space:pre-wrap">ziggamon</span></a><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;font-weight:400;font-style:normal;font-variant:norm=
al;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;margi=
n-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" st=
yle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http:/=
/www.bitrefill.com/" style=3D"text-decoration:none" target=3D"_blank"><span=
style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgrou=
nd-color:transparent;font-weight:400;font-style:normal;font-variant:normal;=
text-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;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitter.com/bitrefill" =
target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rg=
b(102,102,102);background-color:transparent;vertical-align:baseline;white-s=
pace:pre-wrap">Twitter</span></a><span style=3D"font-size:9.5pt;font-family=
:Arial;color:rgb(102,102,102);background-color:transparent;vertical-align:b=
aseline;white-space:pre-wrap"> | </span><a href=3D"https://www.bitrefill.co=
m/blog/" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial=
;color:rgb(102,102,102);background-color:transparent;vertical-align:baselin=
e;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-a=
lign:baseline;white-space:pre-wrap"> | </span><a href=3D"https://angel.co/b=
itrefill" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Aria=
l;color:rgb(102,102,102);background-color:transparent;vertical-align:baseli=
ne;white-space:pre-wrap">Angellist </span></a><br></p></div></div></div></d=
iv></div></div></div></div></div></div></div></div>
--000000000000a83e3f05eb77e8d4--
|