Sergej Kotliar [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-10-19 to 2022-10-24
💬 Posted a total of 11 messages
📚 Participated in the following categories: bitcoin-dev, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:15:00

- reply

📅 Original date posted:2022-10-24
📝 Original message:There are many countermeasures that can be done, we've only implemented a
subset of them as more haven't been needed.
Mainly we wait some time to make sure any conflicting transaction has time
to propagate on the network. We have well connected nodes with basic
redundancy.
When they are available we sometimes use external block explorers for
certain nice-to-have enhancements, but it's absolutely not required for
zeroconf as they are frequently down.
I can of course only speak to our custom-built setup, presumably everyone
who accepts payments with bitcoin uses something similar. Regardless, let's
maybe not go as far as to say that anyone who accepts payments with bitcoin
is attacking bitcoin ;)
On Fri, 21 Oct 2022 at 21:33, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Oct 21, 2022 at 11:34:17AM +0200, Sergej Kotliar wrote:
> > This is factually incorrect and not required for us to do what we do.
>
> So how do you detect people sending conflicting transactions?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221024/0d2b48c5/attachment-0001.html>

2023-06-07 23:15:00

- reply

📅 Original date posted:2022-10-21
📝 Original message:On Thu, 20 Oct 2022 at 21:58, Anthony Towns <aj at erisian.com.au> wrote:
> So, what I'm hearing is:
>
> * lightning works great, but is still pretty small
> * zeroconf works great for txs that opt-out of RBF
> * opt-in RBF is a pain for two reasons:
> - people don't like that it's not treated as zeroconf
> - the risk of fiat/BTC exchange rate changes between
> now and when the tx actually confirms is worrying
> even if it hasn't caused real problems yet
>
> This is about right yes
> Maybe it would be productive to explore this opt-in RBF part a bit
> more? ie, see if "we" can come up with better answers to some question
> along the lines of:
>
> "how can we make on-chain payments for goods priced in fiat work well
> for payees that opt-in to RBF?"
>
> That seems like the sort of thing that's better solved by a collaboration
> between wallet devs and merchant devs (and protocol devs?), rather than
> just one or the other?
>
> Is that something that we could talk about here? Or maybe it's better
> done via an optech workgroup or something?
>
Agreed, more work is needed in the regard and we're happy to participate in
any efforts to make things better. It's not like we _want_ to be against
the core dev roadmap :)
> If "we'll credit your account in BTC, then work out the USD coversion
> and deduct that for your purchase, then you can do whatever you like
> with any remaining BTC from your on-chain payment" is the idea, maybe we
> should just roll with that design, but make it more decentralised: have
> the initial payment setup a lightning channel between the customer and
> the merchant with the BTC (so it's not custodial), but do some magic to
> allow USD amounts to be transferred over it (Taro? something oracle based
> so that both parties are confident a fair exchange rate will be used?).
>
> Maybe that particular idea is naive, but having an actual problem to
> solve seems more constructive than just saying "we want rbf" "but we
> want zeroconf" all the time?
>
Don't think it would solve any of the issues even if the above could
technically work, which it can't, simply because wallets that can only do
dump onchain payments are unlikely to be able to implement a scheme like
this.
> > > > 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,
>
> Heh, fair enough.
>
> So the above suggests 25% of payments already get a sub-par experience,
> compared to what you'd like them to have (which sucks, but if you're
> trying to reinvent both money and payments, maybe isn't surprising). And
> going full rbf would bump that from 25% to 85%, which would be pretty
> terrible.
>
> > RBF is a strictly worse UX as proven by anyone
> > accepting bitcoin payments at scale.
>
> So let's make it better? Building bitcoin businesses on the lie that
> unconfirmed txs are safe and won't be replaced is going to bite us
> eventually; focussing on trying to push that back indefinitely is just
> going to make everyone less prepared when it eventually happens.
>
Sure. The question is if we "make it better" first or if we standardize on
that which works worse first.
> > > > 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..
>
> Okay? Two years is very different from 50 years, and at the moment there's
> not really any data, so people are just going to go with their gut...
>
> If it were growing in line with lightning capacity in BTC, per
> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
> getting from 15% to 80% would then be about 8 years.
>
This math doesn't work. Capacity is a bad metric for activity, something we
unfortunately imported from the ETH world's TVL. Liquid has the same number
of btc on it as Lightning, but we probably all know there are several
orders of magnitude of difference in terms of usage.
There is another type of linear math that can but done but it's
significantly more gloomy: Over the past 3 years the share of bitcoin
payments among services has dropped from ~90%+ to below 50%. These figures
are similar across Bitrefill, Living Room of Satoshi, CoinCards, Bitpay
which is all the sources I know that have published stats on this. If we
assume this trend continues at that pace we might be at a point where
payments on Bitcoin are irrelevant, especially onchain, and there isn't
much left to argue over. I don't think that's going to happen tho, this
math probably also doesn't work for the same reasons, and we will work hard
for it to not happen. Fundamentally the issue of legacy support for bitcoin
things remains, and the ossification that happened on bitcoin things around
the 2015 level of UX. Solving that issue has proven to be a very tricky
subject, that we spend lots of energy on, but yet without overwhelming
success.
Best,
Sergej
--
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221021/9b76400a/attachment-0001.html>

2023-06-07 23:14:59

- reply

📅 Original date posted:2022-10-21
📝 Original message:This is factually incorrect and not required for us to do what we do.
On Fri, 21 Oct 2022 at 00:13, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Oct 21, 2022 at 05:58:41AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > > > 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.
> >
> > So, what I'm hearing is:
> >
> > * lightning works great, but is still pretty small
> > * zeroconf works great for txs that opt-out of RBF
>
> It's important to note that the businesses that say "zeroconf works great"
> for
> them, appear to be achieving that by sybil attacking the network to measure
> propagation. That's not sustainable nor decentralized, as only a small
> number
> of companies can do that without causing a lot of harm to Bitcoin by using
> up
> inbound slots. We've gone through this before with "zeroconf guarantee"
> services, and the end result is not good.
>
> It's in our interests to make sure those companies stop doing that, and no
> new
> companies start.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221021/8043e767/attachment-0001.html>

2023-06-07 23:14:58

- reply

📅 Original date posted:2022-10-24
📝 Original message:On Fri, 21 Oct 2022 at 21:43, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Oct 21, 2022 at 02:02:24PM +0200, Sergej Kotliar via bitcoin-dev
> wrote:
> > On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87 at gmail.com> wrote:
> >
> > > A large number of coins/users sit on custodial rails and this would
> > > essentially encumber protocol developers to those KYC/AML
> institutions. If
> > > Binance decides to never support Lightning in favor of BNC-wrapped BTC,
> > > should this be an issue at all for reasoning about a path forward?
> > >
> >
> > This is a big question here, with the caveat that it's not just binance
> but
> > in fact the majority of wallets and services that people use with bitcoin
> > today.
> > But the question remains as you phrased: At which point do we break
> > backwards compatibility? Another analogy would be to have sunset the old
> > P2PKH addresses during rollout of Segwit - it would certainly have led to
> > Segwit getting rolled out faster. The rbf change actually breaks more
> > things than that, takes more effort to address than just implementing a
> new
> > address format. Previously in the Bitcoin Core process we've chosen to
> keep
>
> RBF certainly does not break more things than depreciating an entire
> address
> standard. P2PKH addresses are still used by old wallets, and it's often not
> worth the risk to upgrade to new software for old coins kept offline by
> ordinary users. I personally have used P2PKH addresses in the past few
> months.
>
> Zeroconf on the other hand has never worked reliably, so you can't even
> claim
> it's a "supported feature". And the fact is, it breaks all the time because
> every time miners change their acceptance rules - eg with new releases - we
> break it every single time we do a new release with different you can
> easily
> exploit zeroconf.
>
Haven't heard of any release breaking zeroconf. I would absolutely say it's
working reliably.
> Frankly, the fact that we didn't widely implement full-rbf sooner is quite
> unfortunate, as Bitrefill, Muun, etc. should have never been using it in
> the
> first place.
>
You make it sound like we're the odd ones out when it's in fact ~every
service that lets you buy stuff with bitcoin. It's just that we're the only
ones raising voices on the mailing list so far. On the contrary side, can
you name one service that lets you buy stuff with bitcoin that doesn't rely
on zeroconf? Maybe with the caveat that it should have some level of scale
and an audience not consisting of only power users.
> > If a majority of bitcoin wallets and services continue using legacy
> > patterns and features, preventing progress, at which point do we want to
> > break compatibility with them?
>
> It's clearly false to claim that the "majority of bitcoin wallets and
> services"
> are using zeroconf. A tiny minority are attempting to use it, with the vast
> majority of previous users having given up on it.
>
I didn't claim that. But it's definitely true that the vast majority of
wallets and services do not allow users to do RBF. This is easy to validate
as the list of wallets with RBF support is short), the list of exchanges
with RBF support is zero.
https://transactionfee.info/charts/transactions-signaling-explicit-rbf/
29% of txs signal RBF, meaning 71% do not. And let's be honest, it's not
like the majority of those were given a choice and chose not to, for the
majority their wallet just doesn't support RBF.
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221024/3af758f1/attachment-0001.html>

2023-06-07 23:14:56

- reply

📅 Original date posted:2022-10-21
📝 Original message:On Fri, 21 Oct 2022 at 16:01, Greg Sanders <gsanders87 at gmail.com> wrote:
> Full-rbf is an odd duck, because while it is not a consensus issue, it
> does affect a large % of transactions made by wallets already, contrary to
> most policy changes.
>
Yeah, there are several policy features that are not consensus related but
end up de facto setting rules for how bitcoin behaves. Minrelayfee being
another, and probably other examples out there that I don't know of.
> It's also a UX issue, not a safety issue for retail wallet users(except
> Muun, who have given a clear timeline). Clearly considerations would be
> very different otherwise, but retail wallets by and large do not consider
> 0-conf as a valid deposit, or at least put up some warning symbols to that
> effect.
>
> Can only speak for myself, but I am looking for a concrete timeframe from
> 0-conf stakeholders. I have no preference for any particular time frame, as
> long as it can be agreed upon in the near-ish future. This keeps the
> transition technically speaking very simple, and removes uncertainty from
> decision making going forward.
>
It's hard to give a timeframe because it's not clear what the path forward
for these stakeholders is. Most of what I've heard in this channel is
things like "just use Lightning" but that's contradicted by user data. So
the action becomes "stop accepting payments onchain" which isn't really a
timeframe type issue, it will hurt whenever it happens. Maybe a thorough
discussion for a way forward would be useful here. Jeremy Rubin suggested
an interesting idea for using CPFP to force a transaction to complete.
We'll evaluate it and see if it works in the wild for zero-conf of RBF
today and report findings, need to evaluate from several angles first
incentives-wise. There might also be other solutions.
I'd also ask if there might also be other solutions for solving the pinning
issue as well if we dig deep into it? Perhaps there are those with
tradeoffs, but those tradeoffs being less significant than the tradeoffs of
rbf policy?
Best,
Sergej
>
> On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej at bitrefill.com>
> wrote:
>
>> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87 at gmail.com> wrote:
>>
>>> A large number of coins/users sit on custodial rails and this would
>>> essentially encumber protocol developers to those KYC/AML institutions. If
>>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>>> should this be an issue at all for reasoning about a path forward?
>>>
>>
>> This is a big question here, with the caveat that it's not just binance
>> but in fact the majority of wallets and services that people use with
>> bitcoin today.
>> But the question remains as you phrased: At which point do we break
>> backwards compatibility? Another analogy would be to have sunset the old
>> P2PKH addresses during rollout of Segwit - it would certainly have led to
>> Segwit getting rolled out faster. The rbf change actually breaks more
>> things than that, takes more effort to address than just implementing a new
>> address format. Previously in the Bitcoin Core process we've chosen to keep
>> backwards compatibility and only roll out opt-in changes with broad
>> consensus over them, with the default behavior being to not roll out
>> changes that are controversial. At which point it's time to back away from
>> that - I honestly don't know. There is probably such a point, and we should
>> maybe have some kind of discussion around that topic on a higher level,
>> just as you phrased it, and I'll paraphrase:
>> If a majority of bitcoin wallets and services continue using legacy
>> patterns and features, preventing progress, at which point do we want to
>> break compatibility with them?
>>
>> Best,
>> Sergej
>>
>>
>> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via
>>>> bitcoin-dev wrote:
>>>> > > 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.
>>>>
>>>> So, what I'm hearing is:
>>>>
>>>> * lightning works great, but is still pretty small
>>>> * zeroconf works great for txs that opt-out of RBF
>>>> * opt-in RBF is a pain for two reasons:
>>>> - people don't like that it's not treated as zeroconf
>>>> - the risk of fiat/BTC exchange rate changes between
>>>> now and when the tx actually confirms is worrying
>>>> even if it hasn't caused real problems yet
>>>>
>>>> (Please correct me if that's too far wrong)
>>>>
>>>> Maybe it would be productive to explore this opt-in RBF part a bit
>>>> more? ie, see if "we" can come up with better answers to some question
>>>> along the lines of:
>>>>
>>>> "how can we make on-chain payments for goods priced in fiat work well
>>>> for payees that opt-in to RBF?"
>>>>
>>>> That seems like the sort of thing that's better solved by a
>>>> collaboration
>>>> between wallet devs and merchant devs (and protocol devs?), rather than
>>>> just one or the other?
>>>>
>>>> Is that something that we could talk about here? Or maybe it's better
>>>> done via an optech workgroup or something?
>>>>
>>>> If "we'll credit your account in BTC, then work out the USD coversion
>>>> and deduct that for your purchase, then you can do whatever you like
>>>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>>>> should just roll with that design, but make it more decentralised: have
>>>> the initial payment setup a lightning channel between the customer and
>>>> the merchant with the BTC (so it's not custodial), but do some magic to
>>>> allow USD amounts to be transferred over it (Taro? something oracle
>>>> based
>>>> so that both parties are confident a fair exchange rate will be used?).
>>>>
>>>> Maybe that particular idea is naive, but having an actual problem to
>>>> solve seems more constructive than just saying "we want rbf" "but we
>>>> want zeroconf" all the time?
>>>>
>>>> (Ideally the lightning channels above would be dual funded so they could
>>>> be used for routing more generally; but then dual funded channels are
>>>> one of the things that get broken by lack of full rbf)
>>>>
>>>> > > 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.
>>>>
>>>> I mean, the avenue above isn't easy to exploit -- you have to identify
>>>> the merchant's node so that they get the bad tx, and you have to connect
>>>> to many peers so that your preferred tx propogates to miners first --
>>>> and probably more importantly, it's relatively easy to detect -- if the
>>>> merchant has a few passive nodes that the attacker doesn't know about
>>>> it, and uses those to watch for attempted doublespends while it tries
>>>> to ensure the real tx has propogated widely. So it doesn't surprise me
>>>> at all that it's not often attempted, and even less often successful.
>>>>
>>>> > > > 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,
>>>>
>>>> Heh, fair enough.
>>>>
>>>> So the above suggests 25% of payments already get a sub-par experience,
>>>> compared to what you'd like them to have (which sucks, but if you're
>>>> trying to reinvent both money and payments, maybe isn't surprising). And
>>>> going full rbf would bump that from 25% to 85%, which would be pretty
>>>> terrible.
>>>>
>>>> > RBF is a strictly worse UX as proven by anyone
>>>> > accepting bitcoin payments at scale.
>>>>
>>>> So let's make it better? Building bitcoin businesses on the lie that
>>>> unconfirmed txs are safe and won't be replaced is going to bite us
>>>> eventually; focussing on trying to push that back indefinitely is just
>>>> going to make everyone less prepared when it eventually happens.
>>>>
>>>> > > > 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..
>>>>
>>>> Okay? Two years is very different from 50 years, and at the moment
>>>> there's
>>>> not really any data, so people are just going to go with their gut...
>>>>
>>>> If it were growing in line with lightning capacity in BTC, per
>>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>>>> getting from 15% to 80% would then be about 8 years.
>>>>
>>>> Presumably that's a laughably terrible model, of course. But if we had
>>>> some actual numbers where we can watch the progress, it might be a lot
>>>> easier to be patient about waiting for lightning adoption to hit 80%
>>>> or whatever, and focus on productive things in the meantime?
>>>>
>>>> Cheers,
>>>> aj
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at 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>
>>
>
--
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221021/58c472a7/attachment-0001.html>

2023-06-07 23:14:49

- reply

📅 Original date posted:2022-10-20
📝 Original message:It's a good idea in theory, the issue is that most wallets and services
bitcoin users use today to send bitcoin don't use solutions to that. So we
end up with "you need to use X wallet to buy stuff", which is equivalent to
"you need to use a Lightning wallet to buy stuff"
On Thu, 20 Oct 2022 at 16:14, Ruben Somsen <rsomsen at gmail.com> wrote:
> Hi,
>
> There is a reasonable tradeoff one can make to get eventual settlement
> assurance prior to confirmation: lock up the funds with a counterparty in a
> 2-of-2 multisig with a timelock back to the owner. As long as the timelock
> has not expired and the recipients trust the counterparty not to sign
> double spends, transactions that are spent from this multisig can be
> considered instant. In cases where the counterparty and the recipient are
> the same person, this solution is trustless. Since merchant purchases tend
> to be low-value, the counterparty risk (facilitating double spends) seems
> acceptable. GreenAddress provided such a service in 2015 or so, but the
> idea got abandoned.
>
> Personally, I find this solution much more tenable than relying on
> spurious network assumptions about what will be propagated and mined.
>
> Best regards,
> Ruben
>
>
>
> On Thu, Oct 20, 2022 at 2:44 PM Sergej Kotliar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj at erisian.com.au> wrote:
>>
>>> 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
>>
>>
>> On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj at erisian.com.au> wrote:
>>
>>> 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)
>>>
>>> > 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?
>>>
>>> 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
>>>
>>> > 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
>>>
>>> > 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.
>>>
>>> > 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? Or perhaps when fine-for-zeroconf txs
>>> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
>>> work the same in a fullrbf world.
>>>
>>> > 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".
>>>
>>> > 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.
>>>
>>> I think if you're ruling out both merchants and users being able to add
>>> fees to a tx to get it to confirm, then you're going to lose either way.
>>> Txs will either expire because they've been stuck for more than a week,
>>> and be vulnerable to replacement at that point anyway, or they'll be
>>> dropped from mempools because they've filled up and they were the lowest
>>> fee tx, and be vulnerable to replacement for that reason. In the expiry
>>> case, the merchant can rebroadcast the original transaction to keep it
>>> alive, perhaps with a good chance of beating an attacker to the punch,
>>> but in the full mempool case, you could only do that if you were also
>>> CPFPing it, which you already ruled out.
>>>
>>> Cheers,
>>> aj
>>>
>>
>>
>> --
>>
>> 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/0cf792bd/attachment-0001.html>

2023-06-07 23:14:47

- reply

📅 Original date posted:2022-10-20
📝 Original message:On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj at erisian.com.au> wrote:
> 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
On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj at erisian.com.au> wrote:
> 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)
>
> > 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?
>
> 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
>
> > 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
>
> > 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.
>
> > 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? Or perhaps when fine-for-zeroconf txs
> drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
> work the same in a fullrbf world.
>
> > 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".
>
> > 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.
>
> I think if you're ruling out both merchants and users being able to add
> fees to a tx to get it to confirm, then you're going to lose either way.
> Txs will either expire because they've been stuck for more than a week,
> and be vulnerable to replacement at that point anyway, or they'll be
> dropped from mempools because they've filled up and they were the lowest
> fee tx, and be vulnerable to replacement for that reason. In the expiry
> case, the merchant can rebroadcast the original transaction to keep it
> alive, perhaps with a good chance of beating an attacker to the punch,
> but in the full mempool case, you could only do that if you were also
> CPFPing it, which you already ruled out.
>
> Cheers,
> aj
>
--
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/5072b274/attachment-0001.html>

2023-06-07 23:14:43

- reply

📅 Original date posted:2022-10-20
📝 Original message:On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard at 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 at 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/dd90d5ad/attachment-0001.html>

2023-06-07 23:14:40

- reply

📅 Original date posted:2022-10-19
📝 Original message:It's an interesting idea, presumably it would work w the new package relay.
Scorched earth bidding war is definitely fine to deter this type of abuse.
Need to consider it more thoroughly from all sides tho. CPFP on the server
side generally has a couple of downsides:
* Requires a hot wallet to receive bitcoin
* an entity that is reliably known to do CPFP can be abused by people
looking to consolidate utxos, which can be quite costly. Might be solvable
with a set of conditionals, and bad UX for abusers is less of a concern :)
Will follow up after more deliberation, thanks!
On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin <jeremy.l.rubin at gmail.com> wrote:
> 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 at 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/5f136073/attachment-0001.html>

2023-06-07 23:14:36

- reply

📅 Original date posted:2022-10-19
📝 Original message: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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/cda936ac/attachment.html>