path: root/13/dce0e531c3763868308fce43c38fb9fa8dc226

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EBBE5C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 15:43:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id C72DE81368
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 15:43:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C72DE81368
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=JYZkH1p8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 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_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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Rj4uSO--oGUc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 15:43:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E3B498134B
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [IPv6:2607:f8b0:4864:20::b31])
 by smtp1.osuosl.org (Postfix) with ESMTPS id E3B498134B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 15:43:41 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id y72so3404177yby.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 08:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=txm3n7P78BVEUf5kGFhIFtTBJey8rte75VLBC1TheIU=;
 b=JYZkH1p8xv/hiwgoyhtft5u2MJWHAG3n2E5IoYvS7lU2pb739RP8n0oRwka+GlJaWC
 2LPHEzzyoDpkjKBsWhhe9L5hfKXwGka+MWoMXn2u7P4WEnfWM9lqzfO2XC3+KSu5I0NP
 jQbZLu1Xmwr3AL0AJEqE0019IkcVFLplzXfrdvl6E44H9Y1n1Nq0rPCmMP4ODPfUpOJ4
 fMu8wElag/k984ckhPnd4qYZp6IFGPl27vcgXyUq2jbhASP8nbtUF59Req/FX4jNcSqG
 h/zKblu2WAR39EnPprLclaQ8oOHZiBTTvmkDQAIgqUnDSjhm0rIG2eGX1QYyo3RRGNiN
 8gEw==
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=txm3n7P78BVEUf5kGFhIFtTBJey8rte75VLBC1TheIU=;
 b=1MYkPh+BNxsDJwOLdfSoccrrS5MvxDDLXC8T65R10IA7k/XQqqpTkEmUe/Ulx9hbPA
 dCHRzofdFqJupHaO6bO/6g1/rJCbdHgPEIIXIZXhtZz+uuEIVX9aAkS4kPlui9B7qrQl
 52PQtQMVYgy6dlOASEWPsc32IDPgL36SnnqTOgU0uV5J17DA3q45clliP0y/swHRXtJE
 H6R6pts2eH5DnV27cuOxFSNh5rZR57XLquBdZDjrXcXlyl9KF/jdf6taj+UqD7QvSM8i
 xGmWmDEL6Rq75Uc4FlIvm9mMjkV3Y1eUxeCc1kNn1irSuS9a5DJL4CUzbzdMmNPbhO6A
 n68A==
X-Gm-Message-State: ACrzQf16pa3U1TdsLXKJDzxfpEgWJUZw4ANKSuLK5VlMOEbcRJLuA6Hv
 ibVqlDrLQkMCrRyqWkMpAW3uLVd2Il9CNlbtEcs=
X-Google-Smtp-Source: AMsMyM7J8ROMwKmaxihLbO0i/fKquDD4r2IZNhvGYGLok2DPJcl7nsfBKY6yaLXuClW6+9Qzf2aojL/xGEVP5tICO2Y=
X-Received: by 2002:a25:c704:0:b0:6c1:9494:f584 with SMTP id
 w4-20020a25c704000000b006c19494f584mr7375788ybe.98.1666194220706; Wed, 19 Oct
 2022 08:43:40 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Wed, 19 Oct 2022 08:43:28 -0700
Message-ID: <CAD5xwhjFWgNTT5URX31jrULMb-iTxWih7673tpueD10AGbV=Gg@mail.gmail.com>
To: Sergej Kotliar <sergej@bitrefill.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a6f05505eb651273"
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:43:44 -0000

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

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?

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 t=
he
> zero-conf (I'll get to that) but there is an even bigger danger called th=
e
> 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 woul=
d
> 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 wit=
h
> 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 probabilit=
y
> of success is the % of hash rate controlled. This is simply due to the fa=
ct
> that the network currently won't propagage the replacement transaction to
> the miner, which is what's being discussed here. American call option ris=
k
> 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 thei=
r
> 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 man=
y
> users would switch to Lightning in such a scenario, the communication
> around it would be hard. My intuition says that the majority of the curre=
nt
> 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 year=
s
> back. The result was that simply users of the wallets that weren't able t=
o
> 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 mo=
ved 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 an=
d
> 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 acces=
s
> to RBF and they know how to handle it, so things are somewhat working. Bu=
t
> 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 lot=
s
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Be=
st
> is for CPFP to be done on the wallet side, not the merchant side, but the=
re
> 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 tha=
n
> 1 in a million" accepted transactions successfully reversed. These days w=
e
> 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
>
>
> --
>
> 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
>

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

<div dir=3D"auto">If they do this to you, and the delta is substantial, can=
&#39;t you sweep all such abusers with a cpfp transaction replacing their p=
ackage 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-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">Hi all,<div><br></div><div>Chiming in on this thread as I fe=
el like the real dangers of RBF as default policy aren&#39;t sufficiently e=
laborated 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 entirety of BIP21 &quot;Scan this QR code with your =
wallet to buy this product&quot; model that I believe we&#39;ve all come to=
 appreciate. Specifically, in a scenario with high volatility and many tran=
sactions in the mempools (which is where RBF would come in handy), a user c=
an 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 tran=
saction and make a new - cheaper one. The biggest risk in accepting bitcoin=
 payments is in fact not zeroconf risk (it&#39;s actually quite easily mana=
ged), 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 _eas=
ily accessible in the wallet_ feature to &quot;cancel transaction&quot; tha=
t means it will eventually get 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 one occasional payment. It&#39;s already possib=
le to execute this form of abuse with opt-in RBF, which may lead to us at s=
ome point refusing those payments (even with confirmation) or cumbersome UX=
 to work around it, such as crediting the bitcoin to a custodial account.</=
div><div><br></div><div>To compare zeroconf risk with FX risk: I think we&#=
39;ve had one incident in 8 years of operation where a user successfully fo=
oled our server to accept a payment that in the end didn&#39;t confirm. To =
successfully fool (non-RBF) zeroconf one needs to have access to mining inf=
rastructure and probability of success is the % of hash rate controlled. Th=
is 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 discus=
sed here. American call option risk would however be available to 100% of a=
ll users, needs nothing beyond the wallet app, and has no cost to the user =
- only upside.<br></div><div><br></div><div>Bitrefill currently processes 1=
500-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 mode=
l for onchain payments, instruct Bitcoin users to use Lightning or deposit =
onchain BTC to a custodial account that we have.=C2=A0<br></div><div>This o=
ption is however not available for your typical BTCPayServer/CoinGate/Bitpa=
y/IBEX/OpenNode et al. Would be great to hear from other merchants or payme=
nt providers how they see this new behavior and how they would counteract i=
t.</div><div><br></div><div>Currently Lightning is somewhere around 15% of =
our total bitcoin payments. This is very much not nothing, and all of us he=
re 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-c=
hain commerce. For me personally it would be an easier discussion to have w=
hen Lightning is at 80%+ of all bitcoin transactions. Currently far too man=
y bitcoin users simply don&#39;t have access to Lightning, and of those tha=
t do and hold their own keys Muun is the biggest wallet per our data, not l=
east due to their ease-of-use which is under threat per the OP. It&#39;s ha=
rd to assess how many users would switch to Lightning in such a scenario, t=
he communication around it would be hard. My intuition says that the majori=
ty 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 ma=
ny and obvious, we don&#39;t need to limit onchain to make Lightning more a=
ppealing. As an anecdote, we did experiment with defaulting to bech32 addre=
sses some years back. The result was that simply users of the wallets that =
weren&#39;t able to pay to bech32 didn&#39;t complete the purchase, no supp=
ort 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 im=
plemented a wallet selector to allow modern wallets to pay to bech32 while =
other wallets can pay to P2SH. This type of thing=C2=A0 is clunky, and requ=
ires a certain level of scale to be able to do, we certainly wouldn&#39;t h=
ave had the manpower for that when we were starting out. This why I&#39;m c=
autious about introducing more such clunkiness vectors as they are centrali=
zing 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, but I think these two risks/costs need to be we=
ighed against eachother first and thoroughly discussed because the costs ar=
e non-trivial on both sides.<br clear=3D"all"><div><br></div><div>Sidenote:=
 On the efficacy of RBF to &quot;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 d=
on&#39;t have access to that functionality, because their wallet doesn&#39;=
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 expla=
ining how to do RBF to a non-power-user is just too complex, for the same r=
eason why it&#39;s complex for wallets to make sensible non-power-user UI a=
round it. Current equilibrium is that mostly only power users have access t=
o RBF and they know how to handle it, so things are somewhat working. But r=
olling this out to the broad market is something else and would likely caus=
e 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 generous CPFP policy to unstuck past transactions o=
r 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 paymen=
ts are non-trivial to reverse is the easiest, taking account user experienc=
e and such. Remember that in the fiat world card payments have up to 5% cha=
rgebacks, whereas we in zero-conf bitcoin land we deal with &quot;fewer tha=
n 1 in a million&quot; accepted transactions successfully reversed. These d=
ays we have very few support issues related to bitcoin payments. The few th=
at do come in are due to accidental RBF users venting frustration about wai=
ting for their tx to confirm.</div><div>&quot;In theory, theory and practic=
e are the same. In practice, they are not&quot;</div><div><br></div><div>Al=
l the best,=C2=A0</div><div>Sergej Kotliar</div><div>CEO Bitrefill.com</div=
><div><br></div><div><br></div>-- <br><div dir=3D"ltr" data-smartmail=3D"gm=
ail_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.3=
8;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-fam=
ily:Arial;color:#000000;background-color:transparent;font-weight:700;font-s=
tyle:normal;font-variant:normal;text-decoration:none;vertical-align:baselin=
e;white-space:pre-wrap;white-space:pre-wrap">Sergej Kotliar</span></p><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-wrap;white-space:pre-wr=
ap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;m=
argin-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:#666666;background-color:transpa=
rent;font-weight:700;font-style:normal;font-variant:normal;text-decoration:=
none;vertical-align:baseline;white-space:pre-wrap;white-space:pre-wrap"><sp=
an style=3D"border:none;display:inline-block;overflow:hidden;width:220px;he=
ight:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o3P52c=
UTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBF=
RNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" width=3D"220" height=3D"80" st=
yle=3D"margin-left:0px;margin-top:0px"></span></span></p><p dir=3D"ltr" sty=
le=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"fon=
t-size:9.5pt;font-family:Arial;color:#666666;background-color:transparent;f=
ont-weight:400;font-style:normal;font-variant:normal;text-decoration:none;v=
ertical-align:baseline;white-space:pre-wrap;white-space:pre-wrap">Twitter: =
@</span><a href=3D"https://twitter.com/ziggamon" style=3D"text-decoration:n=
one" target=3D"_blank" rel=3D"noreferrer"><span style=3D"font-size:9.5pt;fo=
nt-family:Arial;color:#666666;background-color:transparent;font-weight:400;=
font-style:normal;font-variant:normal;text-decoration:underline;vertical-al=
ign:baseline;white-space:pre-wrap;white-space:pre-wrap">ziggamon</span></a>=
<span style=3D"font-size:9.5pt;font-family:Arial;color:#666666;background-c=
olor:transparent;font-weight:400;font-style:normal;font-variant:normal;text=
-decoration:none;vertical-align:baseline;white-space:pre-wrap;white-space:p=
re-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-t=
op:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><p di=
r=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a hr=
ef=3D"http://www.bitrefill.com/" style=3D"text-decoration:none" target=3D"_=
blank" rel=3D"noreferrer"><span style=3D"font-size:9.5pt;font-family:Arial;=
color:#666666;background-color:transparent;font-weight:400;font-style:norma=
l;font-variant:normal;text-decoration:underline;vertical-align:baseline;whi=
te-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" rel=3D"norefer=
rer"><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=
">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/" targ=
et=3D"_blank" rel=3D"noreferrer"><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">Blog</span></a><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"> | </span><a href=3D"https://ange=
l.co/bitrefill" target=3D"_blank" rel=3D"noreferrer"><span style=3D"font-si=
ze:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpar=
ent;vertical-align:baseline;white-space:pre-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" data-smartma=
il=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-hei=
ght:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;f=
ont-family:Arial;color:#000000;background-color:transparent;font-weight:700=
;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:=
baseline;white-space:pre-wrap;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:#000000;background=
-color:transparent;font-weight:700;font-style:normal;font-variant:normal;te=
xt-decoration:none;vertical-align:baseline;white-space:pre-wrap;white-space=
:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p: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:#666666;background-color:tr=
ansparent;font-weight:700;font-style:normal;font-variant:normal;text-decora=
tion:none;vertical-align:baseline;white-space:pre-wrap;white-space:pre-wrap=
"><span style=3D"border: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" width=3D"220" height=3D"8=
0" 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-color:transp=
arent;font-weight:400;font-style:normal;font-variant:normal;text-decoration=
:none;vertical-align:baseline;white-space:pre-wrap;white-space:pre-wrap">Tw=
itter: @</span><a href=3D"https://twitter.com/ziggamon" style=3D"text-decor=
ation:none" target=3D"_blank" rel=3D"noreferrer"><span style=3D"font-size:9=
.5pt;font-family:Arial;color:#666666;background-color:transparent;font-weig=
ht:400;font-style:normal;font-variant:normal;text-decoration:underline;vert=
ical-align:baseline;white-space:pre-wrap;white-space:pre-wrap">ziggamon</sp=
an></a><span style=3D"font-size:9.5pt;font-family:Arial;color:#666666;backg=
round-color:transparent;font-weight:400;font-style:normal;font-variant:norm=
al;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;white-=
space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"line-height:1.38;m=
argin-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" targ=
et=3D"_blank" rel=3D"noreferrer"><span style=3D"font-size:9.5pt;font-family=
:Arial;color:#666666;background-color:transparent;font-weight:400;font-styl=
e:normal;font-variant:normal;text-decoration:underline;vertical-align:basel=
ine;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:0=
pt"><a href=3D"https://www.twitter.com/bitrefill" target=3D"_blank" rel=3D"=
noreferrer"><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">Twitter</span></a><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"> | </span><a href=3D"https://www.bitrefill.com/blog=
/" target=3D"_blank" rel=3D"noreferrer"><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">Blog</span></a><span style=3D"font-siz=
e:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpare=
nt;vertical-align:baseline;white-space:pre-wrap"> | </span><a href=3D"https=
://angel.co/bitrefill" target=3D"_blank" rel=3D"noreferrer"><span style=3D"=
font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:t=
ransparent;vertical-align:baseline;white-space:pre-wrap">Angellist </span><=
/a><br></p></div></div></div></div></div></div></div></div></div></div></di=
v></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">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>

--000000000000a6f05505eb651273--