@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.

remove echo statements, remove comments describing build steps of deps, add ordering matters comments on first depends key

A sum of nits but this looks good otherwise

• Do not npm ci && npm run build if node_modules and dist dirs exist for any given lib

looks like a timeout failure, which we seem to seen somewhat often when we ask the bot to do a bunch of builds at once. imo unrelated to this diff.

In D17402#396020, @emack wrote:

Also the first toggle's functionality being different to the bottom 2 should be more obvious, like using Tabs for Buy/Manage and toggles for sorting. Or simply a dropdown for sorting so you don't end up with 5 toggles for 5 sorting options.

first diff was to handle BCHA decimals going from 8 to 2: D9280

Also the first toggle's functionality being different to the bottom 2 should be more obvious, like using Tabs for Buy/Manage and toggles for sorting. Or simply a dropdown for sorting so you don't end up with 5 toggles for 5 sorting options.

add detailed spec, use consume to parse empp push

@bot b58-ts-tests

In D17398#395986, @teamcity wrote:

Build Bitcoin ABC Diffs / Diff Testing (b58-ts-tests) failed.

Tail of the build log:

Build 'Bitcoin ABC Diffs / Diff Testing' #N/A, branch 'refs/tags/phabricator/diff/51800'
Triggered 2024-12-28 22:26:38 by 'Phabricator Staging (phabricator-staging)'
Started 2024-12-28 22:26:46 on agent 'N/A'
Finished 2024-12-28 22:26:46 with status FAILURE 'Snapshot dependency failed to start: Automated Deployments / Bitcoin ABC Infra / Bitcoin-ABC Infra Checkout'
VCS revisions: 'BitcoinABC_BitcoinAbcStaging' (Git, instance id 22): '5a42bd49eab8e8cfcc42f3a751c1dc0c4052edd4' (branch: 'refs/tags/phabricator/diff/51800', checkout rules: '+:. => ./bitcoin-abc')
TeamCity URL https://build.bitcoinabc.org/buildConfiguration/BitcoinABC_BitcoinAbcStaging/876336 
TeamCity server version is 2024.12 (build 174331), server timezone: GMT (UTC)

[22:26:38]W: bt15 (7s)
[22:26:38]i: TeamCity server version is 2024.12 (build 174331)
[22:26:38] : Finalize build settings
[22:26:38] : Collecting changes in 2 VCS roots
[22:26:38] :	 [Collecting changes in 2 VCS roots] VCS Root details
[22:26:38] :		 [VCS Root details] "Bitcoin ABC Staging" {instance id=22, parent internal id=3, parent id=BitcoinABC_BitcoinAbcStaging, description: "ssh://vcs@reviews.bitcoinabc.org:2221/source/bitcoin-abc-staging.git#refs/heads/master"}
[22:26:38] :		 [VCS Root details] "abc-infrastructure" {instance id=24, parent internal id=7, parent id=AutomatedDeployments_BitcoinAbcDeveloperTools_AbcInfrastructure, description: "ssh://vcs@reviews.bitcoinabc.org:2221/source/infrastructure.git#refs/heads/master"}
[22:26:38]i: Loading current repository state for VCS root 'Bitcoin ABC Staging' (7s)
[22:26:38]i:	 [Loading current repository state for VCS root 'Bitcoin ABC Staging'] Loading current repository state for VCS root 'abc-infrastructure' (7s)
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'Bitcoin ABC Staging': git -c credential.helper= -c credential.helper=/opt/teamcity/temp/credHelper1165154239972118338.sh ls-remote origin
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': git -c credential.helper= -c credential.helper=/opt/teamcity/temp/credHelper1616784882368232137.sh ls-remote origin
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': kex_exchange_identification: Connection closed by remote host
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': Connection closed by 51.161.87.173 port 2221
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': fatal: Could not read from remote repository.
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': 
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': Please make sure you have the correct access rights
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'abc-infrastructure': and the repository exists.
[22:26:38]i:		 [Loading current repository state for VCS root 'abc-infrastructure'] VCS root 'Bitcoin ABC Staging': Warning: Permanently added '[reviews.bitcoinabc.org]:2221' (ED25519) to the list of known hosts.
[22:26:39]i: Waiting for completion of current operations for the VCS root 'Bitcoin ABC Staging'
[22:26:46]i: Detecting changes in VCS root 'Bitcoin ABC Staging' (used in 'Diff Testing', 'Staging Checkout Dummy')
[22:26:46]i: Will collect changes for 'Bitcoin ABC Staging' starting from revision ee625b89b9cabf2aa0a6fa91879da9ba018c8509
[22:26:46] : Compute revision for 'Bitcoin ABC Staging'
[22:26:46] :	 [Compute revision for 'Bitcoin ABC Staging'] Upper limit revision: 5a42bd49eab8e8cfcc42f3a751c1dc0c4052edd4
[22:26:46]i:	 [Compute revision for 'Bitcoin ABC Staging'] MaxModId = 77033
[22:26:46] :	 [Compute revision for 'Bitcoin ABC Staging'] Computed revision: 5a42bd49eab8e8cfcc42f3a751c1dc0c4052edd4
[22:26:46]W: Build was removed from the queue with comment: This build has not been started because some of the builds it depends on failed to start

while this approach does now support dependencies of dependencies, I do not think we want to update the "depends" just yet in the JS app test plans. imo easier to review if we do that one test plan at a time. We might also want to modify the script(s) a bit so that they do not npm ci and npm run build if this has already been done; for example some JS apps depend on ecashaddrjs, mock-chronik-client, and ecash-lib .... well, ecash-lib depends on ecashaddrjs, so we don't want to build it twice.

@bot ecash-herald-tests token-server-tests mock-chronik-client-tests b58-ts-tests chronik-client-tests ecash-lib-tests ecash-agora-tests ecashaddrjs-tests ecash-script-tests ecash-coinselect-tests ecash-agora-integration-tests ecash-lib-integration-tests chronik-client-integration-tests

lint