path: root/fb/2c31387add276b926b9c4d0d449d05930fb81f

Return-Path: <sergej@bitrefill.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F2822C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:30:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CDCE440CB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:30:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CDCE440CB0
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=bitrefill.com header.i=@bitrefill.com
 header.a=rsa-sha256 header.s=b header.b=gRME3ZsW
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pzIj9gJhojk8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:30:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A02A240C99
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com
 [IPv6:2a00:1450:4864:20::231])
 by smtp2.osuosl.org (Postfix) with ESMTPS id A02A240C99
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 14:30:11 +0000 (UTC)
Received: by mail-lj1-x231.google.com with SMTP id r22so22395215ljn.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 07:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitrefill.com; s=b;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=uu8js/UlDbzL37sQ9DWn+FG04H/Oijt59cXT9oRTnow=;
 b=gRME3ZsWR3VnLPs42Sl8IRjdXq0jRZBspT6H9RnLaUo3uEpMgZcHFeConC8Q+QnXsm
 RlwKDrs43jgiwN6p4SFqY6uQ7JYXYatopPTCOdW9CQ3zxCJB0Jr2cOI7eRK+mWB5zJnH
 jHAx2wCYhhyv/bs9843W3TN1AVzFQEF1Vz0piY2Ws0EtBycAIyd24GmpWV5MoBCtRWsK
 qzHGz5jT5jqa2fIm1v0SawCv+wVUjptI2xv3x7mtoDTpOHh7XCOMk3XkPS0E0J1CWzTY
 oGNGDMa5ov+LfLdwK//wYww1A+Hk6RnuBRPfRLRg4sDaumzSOzyF3KCTp/6uEgI82JB6
 8HrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=uu8js/UlDbzL37sQ9DWn+FG04H/Oijt59cXT9oRTnow=;
 b=7xy0Bkcr0LbKHfaGjFxJUkWIKEhG7hKSEqVqe5s32O0foqmaFCWNW/esL3EuUHrt1n
 Ch7w2KnBb4I9o0iQ3j4KYPGcW+Jg4FPDLNa0A5yFUQeXF1vwcLWv0LlF0/0G//irnzSy
 rmshaeO2w1viUHSqVSh4F+QtEImXY1cbCoPBdYA7Ah0YBLDb1mS0IZqlin77aQ8+10Ts
 PBgfAfTec2n3Yji3p/whXpHeq/SESjyAvLVxOQNPR7MRce7Reguw9P0V6FqZe4J4GJDW
 98xtWALmxe9/ya7Ez2YGid0KBhfsW3ZFtjOkXcfSAN2O9BMZXFOks6+JFv7rzqoTp+2c
 9TGA==
X-Gm-Message-State: ACrzQf0DhbwMUV30LdbZfJcaQ/ykstbJFazqLHey++ayrsJy2O0nOBaq
 Rg8WMV48zcXdnF6ax4/pU8hp7SdA+c0haO+i4YFxctm1vIo=
X-Google-Smtp-Source: AMsMyM7brSh+dtGdsUDPITjhVO5tOL9Rp5f50ck/i6SuzqnKmROggw3zAF9j0gWrh6vlyjgxue6dyPA/aDlGk8ziRz4=
X-Received: by 2002:a2e:b8ca:0:b0:26f:c7a1:577a with SMTP id
 s10-20020a2eb8ca000000b0026fc7a1577amr3270131ljp.77.1666189808687; Wed, 19
 Oct 2022 07:30:08 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
In-Reply-To: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
From: Sergej Kotliar <sergej@bitrefill.com>
Date: Wed, 19 Oct 2022 16:29:57 +0200
Message-ID: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000acf3fd05eb640b8c"
X-Mailman-Approved-At: Wed, 19 Oct 2022 14:33:33 +0000
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 14:30:14 -0000

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

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 the
american call option, which risks endangering the entirety of BIP21 "Scan
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 would
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 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 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 out
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 with
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 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't propagage the replacement transaction to
the miner, which is what's being discussed here. American 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.

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 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 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 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 communication
around it would be hard. My intuition says that 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 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 anything,
just "it didn't work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F" and user move=
d 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 and
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) simply
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 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 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 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 merchant 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 and
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 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 are due to accidental RBF users venting frustration about waiting
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


--=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>


--=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>

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">Hi all,<div><b=
r></div><div>Chiming in on this thread as I feel like the real dangers of R=
BF as default policy aren&#39;t sufficiently elaborated here. It&#39;s not =
only about the zero-conf (I&#39;ll get to that) but there is an even bigger=
 danger called the american call option, which risks endangering the entire=
ty of BIP21 &quot;Scan this QR code with your wallet to buy this product&qu=
ot; model that I believe we&#39;ve all come to appreciate. Specifically, in=
 a scenario with high volatility and many transactions in the mempools (whi=
ch is where RBF would 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 moves up, user can cancel his transaction and make a new - chea=
per one. The biggest risk in accepting bitcoin payments is in fact not zero=
conf risk (it&#39;s actually quite easily managed), it&#39;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 out in the end. But if there is an _easily accessible in the wallet_=
 feature to &quot;cancel transaction&quot; that means it will eventually ge=
t systematically abused. A risk of X% loss on many payments that&#39;s easy=
 to systematically abuse is more scary than a rare risk of losing 100% of o=
ne occasional payment. It&#39;s already possible to execute this form of ab=
use with opt-in RBF, which may lead to us at some point refusing those paym=
ents (even with confirmation) or cumbersome UX to work around it, such as c=
rediting the bitcoin to a custodial account.</div><div><br></div><div>To co=
mpare zeroconf risk with FX risk: I think we&#39;ve had one incident in 8 y=
ears of operation where a user successfully fooled our server to accept a p=
ayment that in the end didn&#39;t confirm. To successfully fool (non-RBF) z=
eroconf one needs to have access to mining infrastructure and probability o=
f 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&#39;s being discussed here. American call optio=
n risk would however be available to 100% of all users, needs nothing beyon=
d the wallet app, and has no cost to the user - only upside.<br></div><div>=
<br></div><div>Bitrefill currently processes 1500-2000 onchain payments eve=
ry day. For us, a world where bitcoin becomes de facto RBF by default, mean=
s that we would likely turn off the BIP21 model for onchain payments, instr=
uct Bitcoin users to use Lightning or deposit onchain BTC to a custodial ac=
count that we have.=C2=A0<br></div><div>This option is however not availabl=
e for your typical BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would =
be great to hear from other merchants or payment providers how they see thi=
s new behavior and how they would counteract it.</div><div><br></div><div>C=
urrently Lightning is somewhere around 15% of our total bitcoin payments. T=
his is very much not nothing, and all of us here want Lightning to grow, bu=
t I think it warrants a serious discussion on whether we want Lightning ado=
ption to go to 100% by means of disabling on-chain commerce. For me persona=
lly it would be an easier discussion to have when Lightning is at 80%+ of a=
ll bitcoin transactions. Currently far too many bitcoin users simply don&#3=
9;t have access to Lightning, and of those that do and hold 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&#39;s hard to assess how many users w=
ould switch to Lightning in such a scenario, the communication around it wo=
uld be hard. My intuition says that the majority of the current 85% of bitc=
oin users that pay onchain would just not use bitcoin anymore, probably shi=
ft to an alt. The benefits of Lightning are many and obvious, we don&#39;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 res=
ult was that simply users of the wallets that weren&#39;t able to pay to be=
ch32 didn&#39;t complete the purchase, no support ticket or anything, just =
&quot;it didn&#39;t work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F&quot; and =
user moved on. We rolled it back, and later implemented a wallet selector t=
o allow modern wallets to pay to bech32 while other wallets can 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&#39;t have had the manpower for that=
 when we were starting out. This why I&#39;m cautious about introducing mor=
e such clunkiness vectors as they are centralizing factors.</div><div><br><=
/div><div>I&#39;m well aware of the reason for this policy being suggested =
and the potential pinning attack vector for LN and other smart contracts, b=
ut I think these two risks/costs need to be weighed against eachother first=
 and thoroughly discussed because the costs are non-trivial on both sides.<=
br clear=3D"all"><div><br></div><div>Sidenote: On the efficacy of RBF to &q=
uot;unstuck&quot; stuck transactions</div><div>After interacting with users=
 during high-fee periods I&#39;ve come to not appreciate RBF as a solution =
to that issue. Most users (80% or so) simply don&#39;t have access to that =
functionality, because their wallet doesn&#39;t support it, or they use a c=
ustodial (exchange) wallet etc. Of those that have the feature - only the p=
ower 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&#39;s complex fo=
r wallets to make sensible non-power-user UI around it. Current equilibrium=
 is that mostly only power users have access to RBF and they know how to ha=
ndle it, so things are somewhat working. But rolling this out to the broad =
market is something else and would likely cause more confusion.=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 gener=
ous 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 issues as with RBF.=C2=A0</div><div>In the end a =
risk-based approach to decide on which payments are non-trivial to reverse =
is the easiest, taking account user experience and such. Remember that in t=
he fiat world card payments have up to 5% chargebacks, whereas we in zero-c=
onf bitcoin land we deal with &quot;fewer than 1 in a million&quot; accepte=
d transactions successfully reversed. These days we have very few support i=
ssues related to bitcoin payments. The few that do come in are due to accid=
ental RBF users venting frustration about waiting for their tx to confirm.<=
/div><div>&quot;In theory, theory and practice are the same. In practice, t=
hey are not&quot;</div><div><br></div><div>All the best,=C2=A0</div><div>Se=
rgej Kotliar</div><div>CEO Bitrefill.com</div><div><br></div><div><br></div=
>-- <br><div dir=3D"ltr" data-smartmail=3D"gmail_signature"><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 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:#000000;backgro=
und-color:transparent;font-weight:700;font-style:normal;font-variant:normal=
;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;white-sp=
ace: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:#000000;background-color:transparent;font-weight:700;fon=
t-style:normal;font-variant:normal;text-decoration:none;vertical-align:base=
line;white-space:pre-wrap;white-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"f=
ont-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;mar=
gin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Ar=
ial;color:#666666;background-color:transparent;font-weight:700;font-style:n=
ormal;font-variant:normal;text-decoration:none;vertical-align:baseline;whit=
e-space:pre-wrap;white-space:pre-wrap"><span style=3D"border:none;display:i=
nline-block;overflow:hidden;width:220px;height:80px"><img src=3D"https://lh=
4.googleusercontent.com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_=
zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1Q=
cjtefCDkNG" width=3D"220" height=3D"80" style=3D"margin-left:0px;margin-top=
:0px"></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;co=
lor:#666666;background-color:transparent;font-weight:400;font-style:normal;=
font-variant:normal;text-decoration:none;vertical-align:baseline;white-spac=
e:pre-wrap;white-space:pre-wrap">Twitter: @</span><a href=3D"https://twitte=
r.com/ziggamon" style=3D"text-decoration:none" target=3D"_blank"><span styl=
e=3D"font-size:9.5pt;font-family:Arial;color:#666666;background-color:trans=
parent;font-weight:400;font-style:normal;font-variant:normal;text-decoratio=
n:underline;vertical-align:baseline;white-space:pre-wrap;white-space:pre-wr=
ap">ziggamon</span></a><span style=3D"font-size:9.5pt;font-family:Arial;col=
or:#666666;background-color:transparent;font-weight:400;font-style:normal;f=
ont-variant:normal;text-decoration:none;vertical-align:baseline;white-space=
:pre-wrap;white-space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"li=
ne-height:1.38;margin-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:no=
rmal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;m=
argin-bottom:0pt"><a href=3D"http://www.bitrefill.com/" style=3D"text-decor=
ation:none" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Ar=
ial;color:#666666;background-color:transparent;font-weight:400;font-style:n=
ormal;font-variant:normal;text-decoration:underline;vertical-align:baseline=
;white-space:pre-wrap;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" target=3D"_blank"><span styl=
e=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-co=
lor:transparent;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=
);background-color:transparent;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);back=
ground-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,1=
02,102);background-color:transparent;vertical-align:baseline;white-space:pr=
e-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);bac=
kground-color:transparent;vertical-align:baseline;white-space:pre-wrap">Ang=
ellist </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" class=3D"gma=
il_signature" data-smartmail=3D"gmail_signature"><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 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><p di=
r=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:#000000;background-color:=
transparent;font-weight:700;font-style:normal;font-variant:normal;text-deco=
ration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap">S=
ergej 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;co=
lor:#000000;background-color:transparent;font-weight:700;font-style:normal;=
font-variant:normal;text-decoration:none;vertical-align:baseline;white-spac=
e:pre;white-space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-heig=
ht: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-b=
ottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:#666666;ba=
ckground-color:transparent;font-weight:700;font-style:normal;font-variant:n=
ormal;text-decoration:none;vertical-align:baseline;white-space:pre;white-sp=
ace:pre-wrap"><span style=3D"border:none;display:inline-block;overflow:hidd=
en;width:220px;height:80px"><img src=3D"https://lh4.googleusercontent.com/w=
U5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuB=
Ygo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" width=3D"220"=
 height=3D"80" style=3D"margin-left:0px;margin-top:0px"></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;color:#666666;background-co=
lor:transparent;font-weight:400;font-style:normal;font-variant:normal;text-=
decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wra=
p">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-fami=
ly:Arial;color:#666666;background-color:transparent;font-weight:400;font-st=
yle:normal;font-variant:normal;text-decoration:underline;vertical-align:bas=
eline;white-space:pre;white-space:pre-wrap">ziggamon</span></a><span style=
=3D"font-size:9.5pt;font-family:Arial;color:#666666;background-color:transp=
arent;font-weight:400;font-style:normal;font-variant:normal;text-decoration=
:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap">=C2=A0<=
/span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo=
ttom: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://ww=
w.bitrefill.com/" style=3D"text-decoration:none" target=3D"_blank"><span st=
yle=3D"font-size:9.5pt;font-family:Arial;color:#666666;background-color:tra=
nsparent;font-weight:400;font-style:normal;font-variant:normal;text-decorat=
ion:underline;vertical-align:baseline;white-space:pre;white-space:pre-wrap"=
>www.bitrefill.com</span></a></p><p dir=3D"ltr" style=3D"line-height:1.38;m=
argin-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitter.com/bitrefi=
ll" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;colo=
r:rgb(102,102,102);background-color:transparent;vertical-align:baseline;whi=
te-space:pre-wrap">Twitter</span></a><span style=3D"font-size:9.5pt;font-fa=
mily:Arial;color:rgb(102,102,102);background-color:transparent;vertical-ali=
gn:baseline;white-space:pre-wrap"> | </span><a href=3D"https://www.bitrefil=
l.com/blog/" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:A=
rial;color:rgb(102,102,102);background-color:transparent;vertical-align:bas=
eline;white-space:pre-wrap">Blog</span></a><span style=3D"font-size:9.5pt;f=
ont-family:Arial;color:rgb(102,102,102);background-color:transparent;vertic=
al-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);background-color:transparent;vertical-align:ba=
seline;white-space:pre-wrap">Angellist </span></a><br></p></div></div></div=
></div></div></div></div></div></div></div></div></div>

--000000000000acf3fd05eb640b8c--