Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transaction_height and scanned_height use block height instead of tx count #24

Open
j-berman opened this issue Jan 18, 2022 · 3 comments

Comments

@j-berman
Copy link
Contributor

From the light wallet REST API spec:
transaction_height = Total txes sent in Monero
scanned_height = Current tx scan progress

These are in contrast to:
blockchain_height = Current blockchain height
scanned_block_height = Current scan progress

But can see here the response for all 4 is always in terms of block height, not tx count

Should be a simple fix, marking for later


Side note: I'm not sure if start_height is correct in monero-lws or in MyMonero, but MyMonero seems to be returning a tx count for start_height rather than block height (monero-lws returns block height). Worth a deeper investigation into this discrepancy I think.

@vtnerd
Copy link
Owner

vtnerd commented Feb 4, 2022

MyMonero has a mechanism for tracking transaction numbers, but this is not (or was not at time of monero-lws conception) tracked/returned by monerod. This should require changes to monerod OR monero-lws will have to fetch transactions during first init to count them manually.

start_height should be "correct" in MyMonero since the API originated with that backend. I transitioned everything to block height because I was fairly confident the front-ends would work "well enough" with those values. The biggest issue is that the frontend likely states in the UI "transactions remaining" or something.

I'll take a look at what OpenMonero is doing, I looked at when I wrote monero-lws, but I don't remember whats its doing either. Changing the API to "outputs" remaining is actually the "most" ideal since I think you can get it to work with monerod right now, and is even closer approximation to the amount of work that needs to be done for scanning (when compared to transaction or block count).

@ndorf
Copy link

ndorf commented Feb 6, 2022

The biggest issue is that the frontend likely states in the UI "transactions remaining" or something.

It shows blocks remaining, not txs.

@j-berman
Copy link
Contributor Author

j-berman commented Feb 6, 2022

@ndorf I can't tell why MyMonero needs these values as tx counts.. Can we just get rid of them at the API level and consolidate to only use block height everywhere?

AFAICT "blocks remaining" fits the expected UX across wallets so makes sense to just consolidate around that

(Sorry for assuming this was a mistake @vtnerd, I should've known better lol)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants