-
Notifications
You must be signed in to change notification settings - Fork 4
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
Nice-to-have data for the scanner to identify (or pass back to a consumer) in order of preference #48
Comments
This is already stored on the legacy enote records, are you suggesting to move it?
I'd be fine adding this to the origin context.
What do you think about temporarily caching the txs on scan, and then consumers of enote store events can query the cache for missing data (with a fallback to daemon requests)? The enote store is explicitly an |
Unless I'm missing something, I only see it stored on the received enote. If a user spends an enote, the only metadata they have for that spend is the spend context, which doesn't include the unlock time. Reiterating this would only be useful to know when a spent enote will unlock in a tx in which the user receives 0 enotes.
This is also what I had in mind for option ii -- I think it would be fine and save a lot of headache. That would just leave number 3, which I think can be tackled at the same time as tackling porting background sync over |
Oh I see, for reconstructing transaction histories when you sent a locked no-change tx. Then yes, this would need to be on the spent context.
If txs are cached on scan, then the cache can be post-scanned for key offsets. The main problem is properly tracking reorgs without reimplementing the scan machine. Maybe reorgs can be inferred from enote store block events. |
I was thinking only caching txs that the scanner would need to return to the consumer -- otherwise memory would fill up on long scans. Number 3 would require some additional logic to identify txs which include prior received enotes in the
Was thinking this as well. The consumer would |
If events are consumed in another thread, and txs are cached by sending them via channel to another thread, then you can clean up the cache continuously. I never got that far, but the idea was for the prod scanner to send enote store events in a channel along with a read-lock-handle to the enote store (a |
That sounds like a solid approach to me. Just need to make sure to consume the txs after processing each tx's respective events to know which txs the wallet cares about, without needing to scan the txs. |
I think the majority of these are useful for wallet users.
If all implemented, we would be able to easily maintain compatibility between the Seraphis lib and wallet2 (can import a Seraphis lib-based wallet into a complete and consistent wallet2-based wallet).
1) RCT / non-RCT status of enote
2) Tx fee
3)
key_offsets
of txs which include a received enote in their ring3a) Legacy unscanned txs which include a received enote as a ring member
4) Coinbase boolean
5)
unlock_time
on spend origin context6)
key_offsets
for spent enotes7) a tx's index in a block
is_older_than
for pre-RCT enotes in the same block (Legacy Indexing Overhaul #42 (comment))m_transfers
container from a Seraphis enote store8) the legacy
cryptonote::transcaction
on_money_received
,on_money_spent
,on_skip_transaction
The text was updated successfully, but these errors were encountered: