path: root/c5/0b65ddbb6dec679f0c060d11a48504e40788d5

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DFD21C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 01:04:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id C85BB40291
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 01:04:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C85BB40291
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=D3/wDrUm
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MC7GWn3siIyL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 01:04:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1A105400D9
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com
 [IPv6:2607:f8b0:4864:20::d34])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 1A105400D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 01:04:36 +0000 (UTC)
Received: by mail-io1-xd34.google.com with SMTP id o65so1097662iof.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 18:04:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=+fJ0DmnuZaHp8F99g9brdFtKdjSrur+mOWq3xkFx+fo=;
 b=D3/wDrUmyD0uuLm5iHG+JKirtazwHu8neKWfTjTAN6kSQxwva5CYXofnX4ZdKq+4h7
 AlaamKvtBQvYEsD6asnrzda+Fy1qF5z4TtR/whwOs3ukPOwDSuJNe/HpGL+eksiDb3v4
 RYtnBSi7bJDipeBmGkGJg6bDOZ6UuKtuCQolEZpuj50v1tltiTc/ucWW1hw6Wnzd5zVK
 /jNX5zr7hhTsUJiKFArx4iXfvidJVTMlQUS52En7UiGivVFFDdEGR2Z2IvL/ZsZC200s
 9JBzW29V/mzSerWvTNTPAnSKqFuY/aTONTE7EFOgMdJb4hVE5RXfrNrS0NxQTLCARhkh
 pXJw==
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=+fJ0DmnuZaHp8F99g9brdFtKdjSrur+mOWq3xkFx+fo=;
 b=h0PZNlKshq8QGWKvgOOrelabDfzeu0SlwjJVmZ7hzca9Gfywsz76N9pBsYxL+SYhDQ
 KRh21aD9Go6aA99as1vsHbtiEkTAuT0bqrig959HpsC0zT5yu3nYqVBSVuPga8stU3sL
 m4P2PyWppCCWf0S5wwPUPbsiLpE+dR98/GvMjjXwk22WajHt9YOC/2HZwe2AbKo7Mb7V
 uv864+yWFm/SeuStK7Rn8ES6q+IDYdUzYmaV+5iAaibT2D/0B93wfKUnoAbydth/gtd1
 KALAuDPf51VA5VvIBwEH3CSVtgnzSLaWSogyinpQnYAXfw/etCOc9EJVB2/J+3JgZLax
 8bXQ==
X-Gm-Message-State: ACrzQf2eyjaet6fucZRWscJlAesP/o7k13Ng+ytfThwfqfxQdRZEO5Hu
 1PK8/0OTt3iBWlbbj+MjDDD/elw7unlkTsCzi/1kTsGp+zw=
X-Google-Smtp-Source: AMsMyM7blv93NbHjJBkdK8MAZ7pgAldZKQIKTJlt9RDN9pPrd4Gg/fGJ1pfTiWys1E+DfIjAg5LEsvHym8J/DcLJ0Zk=
X-Received: by 2002:a5d:8d81:0:b0:6bc:c1c7:de9c with SMTP id
 b1-20020a5d8d81000000b006bcc1c7de9cmr11690606ioj.211.1666314275971; Thu, 20
 Oct 2022 18:04:35 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
 <CALZpt+ELLFMJstnTxUjKR6Q2OD-xuLTkt4q3BCHUHyz7NV123w@mail.gmail.com>
 <CABZBVTBMoYJqBP8_4kOybdYoxYePfPJYSP=HO7NEjTfD-QeM7Q@mail.gmail.com>
In-Reply-To: <CABZBVTBMoYJqBP8_4kOybdYoxYePfPJYSP=HO7NEjTfD-QeM7Q@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 20 Oct 2022 21:04:24 -0400
Message-ID: <CALZpt+GX9gW8MVkzRM=udT4haEgXOwsvVP4trRtCS4CpHms3QQ@mail.gmail.com>
To: Sergej Kotliar <sergej@bitrefill.com>
Content-Type: multipart/alternative; boundary="00000000000080eb0105eb81066f"
X-Mailman-Approved-At: Fri, 21 Oct 2022 08:53:05 +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: Fri, 21 Oct 2022 01:04:43 -0000

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

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

From reading one of your other mail, apparently 60% of Bitrefill payments
are non-rbfable on-chain transactions and as such fine for zeroconf. What
I'm wondering is, in case of a wide majority of the full-nodes supporting
full-rbf, if any incoming transaction traffic could be risk-managed
well-enough thanks to some additional countermeasures to be
zeroconf-acceptable ?

We can be technically creative here. One could think of some overlay
monitoring between zeroconf merchants, where mempooldiffs are exchanged to
observe if any acceptance candidate is double-spent inside some other
participant's mempool. Of course, the reconciliation rate would need to be
pretty high to still ensure an "instant payment" UX, though the bandwidth
overhead should be okay as we assume full-node enterprise hosts. I don't
think such functionality would be used by any full-node, it might leverage
p2p extensions but it would be some differentiated services on top of the
usual messages. This is just an idea, and the concrete 0conf acceptance
flow problem needs to be better specified.

> 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 b=
e
> hacked" against "many users find it confusing and stressful" which is not
a
> trivial assessment to do.

Seriously, solving the pinning issues for contracting protocols already
busy few of the most brilliant bitcoin developers almost full-time. If we
had straightforward and backward compatible with all classes of current
Bitcoin applications, we would go for it. Of course, it doesn't mean we
should close the problem of space exploration, and if someone can come up
with solutions offering equivalent trade-offs, I'm all to listen. This is
still an open question if we would have to allow a subset of transactions
to be full-rbf, to fully achieve the semantics of v3 transactions, or at
least if we would like to protect currently open Lightning channels. Hard
problems here.

While I'm hearing the uncertainty of an easy assessment weighting between
favoring UX issues or solving hard theoretical attacks, those latter
concerns I've been serious enough among the Lightning development community
to take it as one of the top engineering issues among all those last years.
From my experience, pentesting in a "black-box" fashion of some subset of
LN vulnerabilities, they turn out as really practical after a few days of
hacking if you know where to hit. Moreover, it should be underscored that
the attacker incentive model between targeting a 0conf merchant like
Bitrefill and a sizable Lightning infrastructure is a bit different. On one
side, you will pocket free gift cards that are likely traceable to
real-world identities, or cancellable by calling out the issuers. On the
other side, you get a stack of free satoshis, easily fungible among all
other coins. As such, we might foresee far more exploitations against LN,
once the network has caught up in terms of volume and stakes to compare
with the most advanced Defi smart contract platforms in the wider
cryptocurrencies ecosystem, attracting today sophisticated attackers. Or at
least, I'm worried by such an outcome playing out for LN if we're too slow
on rolling out mitigations...

All that said, from my perspective upgrading mempool policy doesn't seem
incompatible with a parallel effort to improve the UX problems of RBF, by
automatic fee-bumping logic in a transparent way for the end-users. Like
you said, we should be all optimistic on creative solutions, and
communicate better between merchants and devs on the problem space.

Looking forward to having more interactions on these topics in the future!

Best,
Antoine

Le jeu. 20 oct. 2022 =C3=A0 10:12, Sergej Kotliar <sergej@bitrefill.com> a
=C3=A9crit :

>
>
> 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 su=
ch
>> distributed mempool monitoring system. There is also the possibility of =
an
>> attacker using some "divide-and-conquer" transaction broadcast algorithm=
 to
>> map Bitrefill monitoring point, though as far as I'm aware such algorith=
m
>> 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 a=
nd
> 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 mo=
re
> of the countermeasures as appropriate to the abuse that has happened in t=
he
> 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-bump=
ing
>> budget and a confirmation preference are pre-defined for all payments, a=
nd
>> 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.
>>
>
> 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 whe=
n
> 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 iss=
ue
> and other issues w the current policy. Might be that it's just a
> fundamental goal conflict that different people want different behavior b=
ut
> 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 an=
d
> 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 =
the
>>> american call option, which risks endangering the entirety of BIP21 "Sc=
an
>>> 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 wo=
uld
>>> 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 mov=
es
>>> 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 o=
ut
>>> in the end. But if there is an _easily accessible in the wallet_ featur=
e to
>>> "cancel transaction" that means it will eventually get systematically
>>> abused. A risk of X% loss on many payments that's easy to systematicall=
y
>>> 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-i=
n
>>> RBF, which may lead to us at some point refusing those payments (even w=
ith
>>> 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 i=
n
>>> 8 years of operation where a user successfully fooled our server to acc=
ept
>>> a payment that in the end didn't confirm. To successfully fool (non-RBF=
)
>>> zeroconf one needs to have access to mining infrastructure and probabil=
ity
>>> 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 r=
isk
>>> would however be available to 100% of all users, needs nothing beyond t=
he
>>> 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 w=
e
>>> 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 hea=
r
>>> from other merchants or payment providers how they see this new behavio=
r
>>> 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 Lightn=
ing
>>> to grow, but I think it warrants a serious discussion on whether we wan=
t
>>> Lightning adoption to go to 100% by means of disabling on-chain commerc=
e.
>>> For me personally it would be an easier discussion to have when Lightni=
ng
>>> 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 h=
old
>>> their own keys Muun is the biggest wallet per our data, not least due t=
o
>>> 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 communicat=
ion
>>> around it would be hard. My intuition says that the majority of the cur=
rent
>>> 85% of bitcoin users that pay onchain would just not use bitcoin anymor=
e,
>>> probably shift to an alt. The benefits of Lightning are many and obviou=
s,
>>> we don't need to limit onchain to make Lightning more appealing. As an
>>> anecdote, we did experiment with defaulting to bech32 addresses some ye=
ars
>>> 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 anythi=
ng,
>>> 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 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) simp=
ly
>>> don't have access to that functionality, because their wallet doesn't
>>> support it, or they use a custodial (exchange) wallet etc. Of those tha=
t
>>> 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 t=
he
>>> same reason why it's complex for wallets to make sensible non-power-use=
r UI
>>> around it. Current equilibrium is that mostly only power users have acc=
ess
>>> 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 mercha=
nt
>>> 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 a=
nd
>>> 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 t=
han
>>> 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 waiti=
ng
>>> 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
>>>
>>
>
> --
>
> 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=
>
>

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

<div dir=3D"ltr">&gt; There is a long list of countermeasures that can be b=
uilt to reduce these<br>&gt; attacks, but to be frank we&#39;ve only implem=
ented a small subset of these and<br>&gt; not had any issues, so even a low=
er level of security is more than fine<br>&gt; today to have basically zero=
 abuse. If issues arise we could implement more<br>&gt; of the countermeasu=
res as appropriate to the abuse that has happened in the<br>&gt; wild.<br><=
br>From reading one of your other mail, apparently 60% of Bitrefill payment=
s are non-rbfable on-chain transactions and as such fine for zeroconf. What=
 I&#39;m wondering is, in case of a wide majority of the full-nodes support=
ing full-rbf, if any incoming transaction traffic could be risk-managed wel=
l-enough thanks to some additional countermeasures to be zeroconf-acceptabl=
e ?<br><br>We can be technically creative here. One could think of some ove=
rlay monitoring between zeroconf merchants, where mempooldiffs are exchange=
d to observe if any acceptance candidate is double-spent inside some other =
participant&#39;s mempool. Of course, the reconciliation rate would need to=
 be pretty high to still ensure an &quot;instant payment&quot; UX, though t=
he bandwidth overhead should be okay as we assume full-node enterprise host=
s. I don&#39;t think such functionality would be used by any full-node, it =
might leverage p2p extensions but it would be some differentiated services =
on top of the usual messages. This is just an idea, and the concrete 0conf =
acceptance flow problem needs to be better specified.<br><br>&gt; Fundament=
ally, my view is that all the UX problems related to RBF alone are<br>&gt; =
sufficient of an issue to hold off on rolling out these upgrades for the<br=
>&gt; foreseeable future and think of other ways of solving the pinning iss=
ue and<br>&gt; other issues w the current policy. Might be that it&#39;s ju=
st a fundamental<br>&gt; goal conflict that different people want different=
 behavior but I remain<br>&gt; optimistic for creative solutions from both =
sides. UX issues are soft as<br>&gt; opposed to theoretical attack vectors =
which are hard and binary, we need<br>&gt; find a way to weigh &quot;even t=
hough it doesn&#39;t happen it can theoretically be<br>&gt; hacked&quot; ag=
ainst &quot;many users find it confusing and stressful&quot; which is not a=
<br>&gt; trivial assessment to do.<br><br>Seriously, solving the pinning is=
sues for contracting protocols already busy few of the most brilliant bitco=
in developers almost full-time. If we had straightforward and backward comp=
atible with all classes of current Bitcoin applications, we would go for it=
. Of course, it doesn&#39;t mean we should close the problem of space explo=
ration, and if someone can come up with solutions offering equivalent trade=
-offs, I&#39;m all to listen. This is still an open question if we would ha=
ve to allow a subset of transactions to be full-rbf, to fully achieve the s=
emantics of v3 transactions, or at least if we would like to protect curren=
tly open Lightning channels. Hard problems here.<br><br>While I&#39;m heari=
ng the uncertainty of an easy assessment weighting between favoring UX issu=
es or solving hard theoretical attacks, those latter concerns I&#39;ve been=
 serious enough among the Lightning development community to take it as one=
 of the top engineering issues among all those last years. From my experien=
ce, pentesting in a &quot;black-box&quot; fashion of some subset of LN vuln=
erabilities, they turn out as really practical after a few days of hacking =
if you know where to hit. Moreover, it should be underscored that the attac=
ker incentive model between targeting a 0conf merchant like Bitrefill and a=
 sizable Lightning infrastructure is a bit different. On one side, you will=
 pocket free gift cards that are likely traceable to real-world identities,=
 or cancellable by calling out the issuers. On the other side, you get a st=
ack of free satoshis, easily fungible among all other coins. As such, we mi=
ght foresee far more exploitations against LN, once the network has caught =
up in terms of volume and stakes to compare with the most advanced Defi sma=
rt contract platforms in the wider cryptocurrencies ecosystem, attracting t=
oday sophisticated attackers. Or at least, I&#39;m worried by such an outco=
me playing out for LN if we&#39;re too slow on rolling out mitigations...<b=
r><br>All that said, from my perspective upgrading mempool policy doesn&#39=
;t seem incompatible with a parallel effort to improve the UX problems of R=
BF, by automatic fee-bumping logic in a transparent way for the end-users. =
Like you said, we should be all optimistic on creative solutions, and commu=
nicate better between merchants and devs on the problem space.<br><br>Looki=
ng forward to having more interactions on these topics in the future!<br><b=
r>Best,<br>Antoine<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">Le=C2=A0jeu. 20 oct. 2022 =C3=A0=C2=A010:12, Sergej K=
otliar &lt;<a href=3D"mailto:sergej@bitrefill.com">sergej@bitrefill.com</a>=
&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 20 Oct 2022 at 03:=
37, Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"=
_blank">antoine.riard@gmail.com</a>&gt; wrote:<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">Hi Sergej,<br><br>Thanks =
for the insightful posting, especially highlighting the FX risk which was f=
ar from being evident on my side!<br><br>I don&#39;t know in details the se=
curity architecture of Bitrefill zeroconf acceptance system, though from wh=
at I suppose there is at least a set of full-nodes well-connected across th=
e p2p network, on top of which some mempools reconciliation is exercised<br=
>and zeroconf candidate sanitize against. While I believe this is a far-mor=
e robust deployment against double-spend attempts, there is still the abili=
ty for a sophisticated attacker to &quot;taint&quot; miner mempools, and fr=
om then partition judiciously the transaction-relay network to game such di=
stributed mempool monitoring system. There is also the possibility of an at=
tacker using some &quot;divide-and-conquer&quot; transaction broadcast algo=
rithm to map Bitrefill monitoring point, though as far as I&#39;m aware suc=
h algorithm has not been discussed. I agree with all of that, easier said t=
han done.<br></div></blockquote><div><br></div><div>There is a long list of=
 countermeasures that can be built to reduce these attacks, but to be frank=
 we&#39;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 basicall=
y zero abuse. If issues arise we could implement more of the countermeasure=
s as appropriate to the abuse that has happened in the wild.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>On the efficacy of RBF, I understand the current approach of assuming &quo=
t;manual&quot; RBFing by power users ill UX thinking. I hope in the future =
to have automatic fee-bumping implemented by user wallets, where a fee-bump=
ing budget and a confirmation preference are pre-defined for all payments, =
and the fee-bumping logic &quot;simply&quot; enforcing the user policy, ide=
ally based on historical mempool data. True fact: we don&#39;t have such lo=
gic in consumer wallets today. </div></blockquote><div><br></div><div>In de=
ed. And the vast majority of bitcoin users don&#39;t even have access to an=
y RBF functionality today, so we&#39;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 pla=
ce and widely used the conversation 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 u=
pgrades for the foreseeable future and think of other ways of solving the p=
inning issue and other issues w the current policy. Might be that it&#39;s =
just a fundamental goal conflict that different people want different behav=
ior but I remain optimistic for creative solutions from both sides. UX issu=
es are soft as opposed to theoretical attack vectors which are hard and bin=
ary, we need find=C2=A0a way to weigh &quot;even though it doesn&#39;t happ=
en it can theoretically be hacked&quot; against &quot;many users find it co=
nfusing and stressful&quot; which 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 rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr">All that said, I learn to converge that as a community we would be be=
tter off to weigh deeper the risks/costs between 0confs applications and co=
ntracting protocols in light of full-rbf.<br></div></blockquote><div><br></=
div><div>In deed. And as you wrote in a different message, I agree that it&=
#39;s unfortunate that there isn&#39;t more interaction between the mailing=
 list and services and companies using this stuff day-to-day. Not that it&#=
39;s anyone&#39;s fault in particular, let&#39;s try from all sides to find=
 more ways to create more interaction on these topics. I&#39;ve pinged a fe=
w colleagues that work on payments in the space and hope they will chime in=
 more in this forum!</div><div><br></div><div>All the best,</div><div>Serge=
j</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px 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:33, Sergej Kotliar via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_quote"><div dir=3D"ltr">Hi all,<div><br></div><div>Chiming in on this=
 thread as I feel like the real dangers of RBF as default policy aren&#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 cal=
l 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 volatilit=
y and many transactions in the mempools (which is where RBF would come in h=
andy), 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 ac=
cepting bitcoin payments is in fact not zeroconf risk (it&#39;s actually qu=
ite easily managed), it&#39;s FX risk as the merchant must commit to a cert=
ain BTCUSD rate ahead of time for a purchase. Over time some transactions l=
ose money to FX and others earn money - that evens out in the end. But if t=
here is an _easily accessible in the wallet_ feature to &quot;cancel transa=
ction&quot; that means it will eventually get systematically abused. A risk=
 of X% loss on many payments that&#39;s easy to systematically abuse is mor=
e scary than a rare risk of losing 100% of one occasional payment. It&#39;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) o=
r cumbersome UX to work around it, such as crediting the bitcoin to a custo=
dial account.</div><div><br></div><div>To compare zeroconf risk with FX ris=
k: I think we&#39;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&#39=
;t confirm. To successfully fool (non-RBF) zeroconf one needs to have acces=
s to mining infrastructure and probability of success is the % of hash rate=
 controlled. This is simply due to the fact that the network currently won&=
#39;t propagage the replacement transaction to the miner, which is what&#39=
;s being discussed here. American call option risk would however be availab=
le to 100% of all users, needs nothing beyond the wallet app, and has no co=
st to the user - only upside.<br></div><div><br></div><div>Bitrefill curren=
tly processes 1500-2000 onchain payments every day. For us, a world where b=
itcoin becomes de facto RBF by default, means that we would likely turn off=
 the BIP21 model for onchain payments, instruct Bitcoin users to use Lightn=
ing 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 mer=
chants or payment providers how they see this new behavior and how they wou=
ld counteract it.</div><div><br></div><div>Currently Lightning is somewhere=
 around 15% of our total bitcoin payments. This is very much not nothing, a=
nd 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 discu=
ssion to have when Lightning is at 80%+ of all bitcoin transactions. Curren=
tly far too many bitcoin users simply don&#39;t have access to Lightning, a=
nd 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 would switch to Lightning in suc=
h 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 woul=
d just not use bitcoin anymore, probably shift to an alt. The benefits of L=
ightning are many and obvious, we don&#39;t need to limit onchain to make L=
ightning more appealing. As an anecdote, we did experiment with defaulting =
to bech32 addresses some years back. The result was that simply users of th=
e wallets that weren&#39;t able to pay to bech32 didn&#39;t complete the pu=
rchase, 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 bac=
k, and later implemented a wallet selector to allow modern wallets to pay t=
o bech32 while other wallets can pay to P2SH. This type of thing=C2=A0 is c=
lunky, and requires a certain level of scale to be able to do, we certainly=
 wouldn&#39;t have had the manpower for that when we were starting out. Thi=
s why I&#39;m cautious about introducing more such clunkiness vectors as th=
ey 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 attac=
k vector for LN and other smart contracts, but I think these two risks/cost=
s need to be weighed against eachother first and thoroughly discussed becau=
se the costs are non-trivial on both sides.<br clear=3D"all"><div><br></div=
><div>Sidenote: On the efficacy of RBF to &quot;unstuck&quot; stuck transac=
tions</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 wa=
llet 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 w=
orks, and explaining how to do RBF to a non-power-user is just too complex,=
 for the same reason why it&#39;s complex for wallets to make sensible non-=
power-user UI around it. Current equilibrium is that mostly only power user=
s have access to RBF and they know how to handle it, so things are somewhat=
 working. But rolling this out to the broad market is something else and wo=
uld likely cause more confusion.=C2=A0</div><div>CPFP is somewhat more viab=
le but also not perfect as it would require lots of edge case code to handl=
e abuse vectors: What if users abuse a generous CPFP policy to unstuck past=
 transactions or consolidate large wallets. Best is for CPFP to be done on =
the wallet side, not the merchant side, but there too are the same UX issue=
s as with RBF.=C2=A0</div><div>In the end a risk-based approach to decide o=
n which payments are non-trivial to reverse is the easiest, taking account =
user experience and such. Remember that in the fiat world card payments hav=
e up to 5% chargebacks, whereas we in zero-conf bitcoin land we deal with &=
quot;fewer than 1 in a million&quot; accepted transactions successfully rev=
ersed. These days we have very few support issues related to bitcoin paymen=
ts. The few that do come in are due to accidental RBF users venting frustra=
tion about waiting for their tx to confirm.</div><div>&quot;In theory, theo=
ry and practice are the same. In practice, they are not&quot;</div><div><br=
></div><div>All the best,=C2=A0</div><div>Sergej Kotliar</div><div>CEO Bitr=
efill.com</div><div><br></div><div><br></div>-- <br><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><di=
v dir=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,=
0,0);background-color:transparent;font-weight:700;font-style:normal;font-va=
riant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-w=
rap">Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Ar=
ial;color:rgb(0,0,0);background-color:transparent;font-weight:700;font-styl=
e:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;w=
hite-space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38=
;margin-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b>=
</p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,102,102);=
background-color:transparent;font-weight:700;font-style:normal;font-variant=
:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=
<span style=3D"border:medium none;display:inline-block;overflow:hidden;widt=
h:220px;height:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8b=
oCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txX=
MKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" style=3D"margin-left=
: 0px; margin-top: 0px;" width=3D"220" height=3D"80"></span></span></p><p d=
ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><spa=
n style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgro=
und-color: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;c=
olor:rgb(102,102,102);background-color:transparent;font-weight:400;font-sty=
le:normal;font-variant:normal;text-decoration:underline;vertical-align:base=
line;white-space:pre-wrap">ziggamon</span></a><span style=3D"font-size:9.5p=
t;font-family:Arial;color:rgb(102,102,102);background-color:transparent;fon=
t-weight:400;font-style:normal;font-variant:normal;text-decoration:none;ver=
tical-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"fon=
t-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-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;fon=
t-family:Arial;color:rgb(102,102,102);background-color:transparent;font-wei=
ght:400;font-style:normal;font-variant:normal;text-decoration:underline;ver=
tical-align:baseline;white-space:pre-wrap">www.bitrefill.com</span></a></p>=
<p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">=
<a href=3D"https://www.twitter.com/bitrefill" target=3D"_blank"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-col=
or:transparent;vertical-align:baseline;white-space:pre-wrap">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"><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-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,10=
2,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);back=
ground-color:transparent;vertical-align:baseline;white-space:pre-wrap">Ange=
llist </span></a><br></p></div></div></div></div></div></div></div></div></=
div></div></div></div></div>
</div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"><div dir=3D"=
ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot=
tom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);=
background-color:transparent;font-weight:700;font-style:normal;font-variant=
:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=
Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;c=
olor:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:nor=
mal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-=
space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><=
p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><=
span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;font-weight:700;font-style:normal;font-variant:norm=
al;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><span=
 style=3D"border: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"=
><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color=
:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:normal;=
font-variant:normal;text-decoration:none;vertical-align:baseline;white-spac=
e: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-fa=
mily:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;fo=
nt-style:normal;font-variant:normal;text-decoration:none;vertical-align:bas=
eline;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:rgb(102,10=
2,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:hidd=
en;width:220px;height:80px"><img src=3D"https://lh4.googleusercontent.com/w=
U5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuB=
Ygo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" style=3D"marg=
in-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:0p=
t"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);=
background-color: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-dec=
oration: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;f=
ont-style:normal;font-variant:normal;text-decoration:underline;vertical-ali=
gn:baseline;white-space:pre-wrap">ziggamon</span></a><span style=3D"font-si=
ze:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpar=
ent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:n=
one;vertical-align:baseline;white-space:pre-wrap">=C2=A0</span></p><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b sty=
le=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1=
.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http://www.bitrefill.com/"=
 style=3D"text-decoration:none" 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:normal;font-variant:normal;text-decoration:unde=
rline;vertical-align:baseline;white-space:pre-wrap">www.bitrefill.com</span=
></a></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot=
tom:0pt"><a href=3D"https://www.twitter.com/bitrefill" target=3D"_blank"><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;vertical-align:baseline;white-space:pre-wrap">Twitt=
er</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,1=
02);background-color:transparent;vertical-align:baseline;white-space:pre-wr=
ap">Blog</span></a><span style=3D"font-size:9.5pt;font-family:Arial;color:r=
gb(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);background-color:transparent;vertical-align:baseline;white-space:pre-w=
rap">Angellist </span></a><br></p></div></div></div></div></div></div></div=
></div></div></div></div></div>
</blockquote></div>

--00000000000080eb0105eb81066f--