Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

From: Antoine Riard <antoine.riard@gmail•com>
To: Sergej Kotliar <sergej@bitrefill•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Thu, 20 Oct 2022 21:04:24 -0400	[thread overview]
Message-ID: <CALZpt+GX9gW8MVkzRM=udT4haEgXOwsvVP4trRtCS4CpHms3QQ@mail.gmail.com> (raw)
In-Reply-To: <CABZBVTBMoYJqBP8_4kOybdYoxYePfPJYSP=HO7NEjTfD-QeM7Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 16843 bytes --]

> 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 be
> 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 à 10:12, Sergej Kotliar <sergej@bitrefill•com> a
écrit :

>
>
> 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 such
>> 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 algorithm
>> has not been discussed. I agree with all of that, easier said than done.
>>
>
> There is a long list of countermeasures that can be built to reduce these
> attacks, but to be frank we've only implemented a small subset of these and
> not had any issues, so even a lower level of security is more than fine
> today to have basically zero abuse. If issues arise we could implement more
> of the countermeasures as appropriate to the abuse that has happened in the
> wild.
>
>
>> On the efficacy of RBF, I understand the current approach of assuming
>> "manual" RBFing by power users ill UX thinking. I hope in the future to
>> have automatic fee-bumping implemented by user wallets, where a fee-bumping
>> budget and a confirmation preference are pre-defined for all payments, and
>> the fee-bumping logic "simply" enforcing the user policy, ideally based on
>> historical mempool data. True fact: we don't have such logic in consumer
>> wallets today.
>>
>
> In deed. And the vast majority of bitcoin users don't even have access to
> any RBF functionality today, so we're not even seeing gradual development
> of these things yet. I think this fact needs to be taken into account when
> designing breaking changes to bitcoin policy. Had these things been in
> place and widely used the conversation would have been much easier.
>
> Fundamentally, my view is that all the UX problems related to RBF alone
> are sufficient of an issue to hold off on rolling out these upgrades for
> the foreseeable future and think of other ways of solving the pinning issue
> and other issues w the current policy. Might be that it's just a
> fundamental goal conflict that different people want different behavior but
> I remain optimistic for creative solutions from both sides. UX issues are
> soft as opposed to theoretical attack vectors which are hard and binary, we
> need find a way to weigh "even though it doesn't happen it can
> theoretically be hacked" against "many users find it confusing and
> stressful" which is not a trivial assessment to do.
>
> All that said, I learn to converge that as a community we would be better
>> off to weigh deeper the risks/costs between 0confs applications and
>> contracting protocols in light of full-rbf.
>>
>
> In deed. And as you wrote in a different message, I agree that it's
> unfortunate that there isn't more interaction between the mailing list and
> services and companies using this stuff day-to-day. Not that it's anyone's
> fault in particular, let's try from all sides to find more ways to create
> more interaction on these topics. I've pinged a few colleagues that work on
> payments in the space and hope they will chime in more in this forum!
>
> All the best,
> Sergej
>
>
>> Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> a écrit :
>>
>>> 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 🤷‍♂️" 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) 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
>>>
>>>
>>> --
>>>
>>> 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>
>

[-- Attachment #2: Type: text/html, Size: 29957 bytes --]