Actually this needs to be rebased, I see the fix has been split into its own diff in D18670.

Yes, I think it's acceptable and somewhat inevitable.

We could implement a standard Cashtab sorting for the first page, say by timeFirstSeen only even the block time sort is different, but that could cause its own challenges (varies from different chronik servers, not always available, etc).

But I think it's okay for tx history to not always be the same as long as they resolve to a canonical order, which the history endpoint should handle.

Indeed, it may not always be the same from refresh to refresh even now, given how the history endpoint returns confirmed vs unconfirmed txs.

Going forward and esp after precon, maintaining tx order by when first finalized is an interesting and relevant app dev problem. There is no canonical time_finalized available afaik, at least not an exact one that can later be referenced in the future.

hm good point. will keep this as an option. the reason tho I think the whole logic is worthwhile:

1. it moves the appearance and ordering of new incoming (or outgoing) txs to the user's websocket msg ordering, which is likely to be consistent with the user's "timeFirstSeen" experience (vs chronik call may not be this way, esp txs are in various blocks)

2. The ultimate goal is to move cashtab away from updating the whole utxo set every time we see a tx (current behavior). We used to update the whole first page of tx history and the whole utxo set every time we saw a new tx. Now we are still updating the utxo set. Admittedly this is only 2 calls, now 1 call, and is quite quick. But both calls are superfluous and could be handled by the already-made chronik.tx call on websocket msgs. The utxo call in particular can be heavy if the wallet has many utxos, so overkill when we know any given tx is only changing a handful of utxos.

With ecash-wallet, the utxo set will now auto-update on sent txs. Just need to add updating on received txs (which may also simply be managed within ecash-wallet, have not decided yet).

The expected benefit is ludicrously fast repeated txs without any utxo set / already-spent errors, as well as Cashtab loading instantly with a correct cached utxo set (unless the wallet was used in another app while the user was offline).