Build Bitcoin ABC Diffs / Diff Testing (preview-cashtab) passed.
Preview is available at http://51.83.220.62:41781 for the next 60 minutes.

@bot preview-cashtab

Much better !

checked for flakiness on test, could not repeat locally, rerun CI

ok good discussion in this thread

dedup AssertLockHeld

@bot guix-linux guix-osx guix-win

@bot b58-ts ecash-lib ecash-agora chronik-client mock-chronik-client ecash-script ecash-coinselect ecashaddrjs

• Finish this diff with some kind of agreed solution. I think rendering fewer bars, at least by default, is the way to go -- since these scam / phishing offers are actually quite common. We could even bump the value from say 20% or 50% to something like 500% to just get rid of these, tho that would prob just encourage these scammers to switch to 500% instead of 1000% scams.

I'm ok with this approach if it brings immediate value to the UX.
If scrolling up shows a link-like button that says "load more expensive offers" and we limit to say 5 or 10 listings by default, this will improve the UI a bit on its own. Also no need to fight with %, just create enough listings to fill the default display area.

These are good points but imo a lot gets beyond the scope of this diff. Indeed we do have many opportunities to improve OrderBook.

In D17426#396302, @bytesofman wrote:

In D17426#396257, @emack wrote:

No issues on a technical level, but philosophically, I feel this is overreaching on Cashtab's part. There are valid use cases where the seller is essentially setting this as a limit order, to be sold at their target price. I know scammers are leveraging this but implementing this diff means all etoken prices would only move in controlled increments, which goes against the DEX mantra. Also none of the mainstream DEXs do this either.

A better solution would be to use what cowswap or uniswap (I can't remember which one) did and simply pop up a warning if the user is buying more than 10x the current average spot price. If the user still gets tricked then that's on them and we've done our due diligence.

it's a good point, in general agora should be 100% laissez faire

the issue I have is with offers that are clearly fishing for someone making a mistake -- for example there are some XECX listings asking for 9 billion XEC for 95k XECX ... the "spot price" looks low / reasonable enough. The presence of these offers makes OrderBook less usable. They are also hugely asymmetric -- i.e. if only one person is tricked here, half the market cap of XECX just went to a scam.

How about this solution:

• We default to rendering only the offers within 20% of spot (20% is arbitary, open to changing this. 50% is probably more reasonable and useful for products like memecoins)
• We have a switch that allows the user to show all the offers
• We show warnings for any buys above spot

I think it's important to screen some of the orders out just to make the component more usable, esp as we often need to load 100s (soon thousands?) of these at once. While the above-spot orders are "hidden" on the front end -- they are still functionally limit orders. If the spot price orders are consumed, then spot changes, and these more expensive orders would eventually be rendered by default. The orders themselves also still exist on the chain. Anyone could still accept them with their own front end or programmatically. Cashtab being open source, anyone could fork it to show whatever.

In D17426#396257, @emack wrote:

No issues on a technical level, but philosophically, I feel this is overreaching on Cashtab's part. There are valid use cases where the seller is essentially setting this as a limit order, to be sold at their target price. I know scammers are leveraging this but implementing this diff means all etoken prices would only move in controlled increments, which goes against the DEX mantra. Also none of the mainstream DEXs do this either.

A better solution would be to use what cowswap or uniswap (I can't remember which one) did and simply pop up a warning if the user is buying more than 10x the current average spot price. If the user still gets tricked then that's on them and we've done our due diligence.

@bot build-ibd

More a question than actually requesting change.
Also I think you test plan should include running the dependencies directly, and not only the callers.

No issues on a technical level, but philosophically, I feel this is overreaching on Cashtab's part. There are valid use cases where the seller is essentially setting this as a limit order, to be sold at their target price. I know scammers are leveraging this but implementing this diff means all etoken prices would only move in controlled increments, which goes against the DEX mantra. Also none of the mainstream DEXs do this either.