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 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
