I don't see how that reduces the possibility of double spends of 0-conf transactions without disabling the RBF though. The link doesn't discuss it. It mentions the double_spend_seen field in the wallet, but it doesn't solve the issue. A user can pay for something, then go away and then cancel the transaction with RBF. The double_spend_seen field would appear too late.

I believe it is possible to signal no-RBF to remove the cancellation policy but im not 100% sure, it is still open to self wallet drain double spends though as I don't think that one is avoidable

Ah yes, for example merchants could accept only non-RBF transactions, but it still makes UX worse for both merchants and buyers. Also for the wallets UI.

It forsure depends on the circumstance of the merchant for whether or not they should accept 0conf, im sure some would have the appetite for it and others would not

Dev Update May 21 2023 | bitdomains, SigmaUSD.io, Paideia and more! via https://ift.tt/ULorEHD

Yes, but my point is that for most merchants that don't transact large amounts 0-conf transactions are a viable solution if they are reliable almost all of the time and there are insurance-like incentives against double spends. They also would bring a much more convenient UX as the transactions would be nearly instant.

I just can't imagine having to wait 2 or more minutes at the supermarket check-out to have multiple block confirmations for my payment to be accepted. The transactions should be instant and reliable if we want to achieve real world adoption.

Did a whale move that candle?

0conf is not a scaling solution though it is an optional trust based finality solution, atomic multipath payments I think is a more suitable model for instant transactions because it comes with more settlement guarantees and just as fast if not faster

(re : Yes, but my point is that for ...) You wouldn’t use erg at the supermarket checkout directly.

(re : * Did a whale move that candle? https://...*) Looks like a good bit of volume on kucoin

It's not a scaling solution, true. What are atomic multipath payments? Does one have to open a channel to use them? And if so, what would be the process to pay merchant?

Why not? What would I use instead?

(re : Why not? What would I use inst...) Some sort of layer 2/rollup. A broad example is lightning network for bitcoin.

well yea lightning for example uses this concept, in the channel based model ideally you would already have access to a node with channels established that have a payment path to your merchants node. it is relatively easy to make sure you have this set up, but I personally think it would be ideal to get rid of the channel model some how if possible. but for now its the most widely used implementation

(re : * Did a whale move that candle? https://...*) 4 cents difference, you can do it with $200

Read up on hydra as well to get an idea how you can speed up those “cup of coffee” tx’s

That’s IOHK’s solution for cardano

yea hydra is similar

I think this area of research is much untapped

So I'd have to open a channel to that node first and plan beforehand how much money I want to spend? What if the node doesn't have a channel with a small street food merchant I want to transact with? It seems like a terrible UX tbh.

Hydra

Hydra? It’s up to the processing entities to implement. Most likely a street vendor would be part of a larger network that would support that.

I'm also not a fan of Lightning network as it brings even more centralization and defeats the whole purpose why Bitcoin was invented.

not necessarily you just need a channel open to a node that has some path that the merchant also has which is really easy to set up, there are tons of highly central lightning nodes you can find like that. if you are part of the vendors network of merchants you might open direct channels to mitigate fees and be able to predict volume flow

Just like they would join a processor who rolls up visa, MC, and AMEX…that processor would have a solution in place that would offer that too.

yea except processors are not bound by discrete log

or verifiable ledgers

Well, the entire tx from the head is rolled up into the chain when closed for hydra at least, no?

yea as far as I read on that it was, maybe I misunderstood what you were saying