On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),
You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At least, that's what I understood you saying last
time; ie that if the tx signals rbf, then you just don't do zeroconf no
matter what other trustworthy signals you might see:
https://twitter.com/ziggamon/status/1435863691816275970
(rbf txs seem to have increased from 22% then to 29% now)
Yeah. Our share of RBF is a bit lower than that as many RBF transactions are something other than consumer purchases, and most consumer purchases can't do RBF
> 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,
If someone's going to systematically exploit your store via this
mechanism, it seems like they'd just find a single wallet with a good
UX for opt-in RBF and lowballing fees, and go to town -- not something
where opt-in rbf vs fullrbf policies make any difference at all?
Sort of. But yes once this starts being abused systemically we will have to do something else w RBF payments, such as crediting the amount in BTC to a custodial account. But this option isn't available to your normal payment processor type business.
Also worth keeping in mind that sometimes "opportunity makes the thief". Currently only power-user wallet have that feature and their market share is relatively small, mainly electrum stands out. But if this is available to all users everywhere then it will start being abused and we'll have to then direct all payments to custodial account, or some other convoluted solution.
It's not like existing wallets that don't let you set RBF will suddenly
get a good UX for replacing transactions just because they'd be relayed
if they did, is it?
> To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled.
I thought the "normal" avenue for fooling non-RBF zeroconf was to create
two conflicting txs in advance, one paying the merchant, one paying
yourself, connect to many peers, relay the one paying the merchant to
the merchant, and the other to everyone else.
I'm just basing this off Peter Todd's stuff from years ago:
https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
Yeah, I know the list still rehashes a single incident from 10 years ago to declare the entire practice as unsafe, and ignores real-world data that of the last million transactions we had zero cases of this successfully abusing us.
> Currently Lightning is somewhere around 15% of our total bitcoin payments.
So, based on last year's numbers, presumably that makes your bitcoin
payments break down as something like:
5% txs are on-chain and seem shady and are excluded from zeroconf
15% txs are lightning
20% txs are on-chain but signal rbf and are excluded from zeroconf
60% txs are on-chain and seem fine for zeroconf
Numbers are right. Shady is too strong a word, it's mostly transactions with very low fee, or high purchase amount, or many dependent unconfirmed transactions, stuff like that. In some cases we do a human assessment of the support ticket and often just pass them through.
> 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.
If the numbers above were accurate, this would just mean you'd go from 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
Point is that RBF transactions are unsafe even when waiting for a confirmation, which Peter Todd trivially proved in the reply next to this. The reliable solution is to reject all RBF payments and direct those users to custodial accounts. There are other variants to solve this with varying degree of convolutedness. RBF is a strictly worse UX as proven by anyone accepting bitcoin payments at scale.
> For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions.
Can you extrapolate from the numbers you've seen to estimate when that
might be, given current trends?
Not sure, it might be exponential growth, and the next 60% of Lightning growth happen faster than the first 15%. Hard to tell. But we're likely talking years here..
> The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing.
To be fair, I think making lightning (and coinjoins) work better is
exactly what inspired this -- not as a "make on-chain worse so we look
better in comparison", but as a "making lightning work well is a bunch
of hard problems, here's the next thing we need in order to beat the
next problem".
In deed. The fact that the largest non-custodial Lightning wallet started this thread should be an indicator that despite these intentions the solution harms more than it fixes.
Transactions being evicted from mempool is solved by requiring a minimum fee rate, which we do and now seems to have become a standard practice. Theoretically we can imagine them being evicted anyway but now we're several theoreticals deep again when discussing something that will cause massive problems right away. In emergency situations CPFP and similar can of course be done manually in special circumstances.
Cheers
Sergej
