selsta: That is good to hear. Maybe I can use this as a template to go by. I am using the monero javascript wasm library.

maybe there is no better way than doing it periodically because it is probably not a good idea to do such an expensive operation in the event listeners. So it would need to be queued of to a worker saga anyhow. And that is basically the same as doing periodic saves.

The periodic saving was only added because people had issues with crashes and having to rescan.

when I closed the CLI by X-ing out instead of using the exit command when I opened the wallet again it scanned from when I first opened it and showed an incoming transfer that it had already shown when I originally opened it

selsta: the issue is I never know when the application closes, so in a way there is no way around it. Or maybe there is another way: Every time the wallet is synced completely a save is done. The thing I want to have is a state machine that does not depend on any form of periodicity. In my mind there should be some kind of state that triggers a save. Maybe percentage synced would also be an option.

nioc: hm...so it seems like in case of the CLI wallet this state is triggered when the user issues the exit command.

nioc: on Windows?

selsta: yes

ok, the problem is X-ing CLI programs by closing the window is the equivalent of killing them.

so you either have to use ctrl+c or type exit

GUI programs can properly close when pressing X.

could it be more natural if the saving was triggered by the sync process instead of user interaction?

spirobel[m]: is there no event or so that runs on exit? I'm not familiar with web development.

if you have a large wallet cache (hundreds of MB) saving on every block might become an issue

selsta: yes there is no way to perform an action before the browser closes. But aside from that, from a conceptional perspective: shouldnt this process of saving be triggered by the syncing process instead of the user?

selsta: how can it become so large? I forgot what kind of data can be in the cache

I will look it up

if you have thousands of transactions

selsta: okay so this goes back to the question in the beginning. If that is the case we could use the monerowalletlistener and only save the cache/key data (the wallet data) onOutputSpent and OutputReceived. ( more specifically when there is a new transaction that concerns us) other than that we could just save the new height externally and on wallet reopen call setSyncHeight with this saved height.

the question that arises then: (async) onOutputReceived(output)

Invoked 3 times per received output: once when unconfirmed, once when confirmed, and once when unlocked. (async) onOutputSpent(output)

Invoked twice per spent output: once when confirmed and once when unlocked Do we need to save on all these different states or just on one of them? does it make a difference to the cache if the transaction is unconfirmed, confirmed or unlocked?

all these events are related to a block being scanned, right?

ok, not necessarily

selsta: yes. The phrasing in the docs is like this: (async) onNewBlock(height)

Invoked when a new block is added to the chain. moneroecosystem.org/monero-javascript/MoneroWalletListener.html but it actually is more like: when a new block is being scanned.

I assume that the onOutput/spent/received listeners get triggered under the same (more specific) circumstances as OnNewBlock. But I'd have to investigate to verify.

if you scan e.g. 50 blocks / second you can't also save 50 times in a second.

onOutput might work, you will have to try it

<selsta> "onOutput might work, you will..." <- ok thanks for the input so far. I think I will try something like this: onNewBlock -> just save the new height and modifiy the openWallet routine so that after the wallet was opened the standard is to call setSyncHeight with this externally saved height. onNewOutput: actually save the wallet data. The only danger might be that the wallet saving is not successful (for example because the

browser was close) and the height was already updated to something past where the transaction happened. In this case the transaction would not be in the cache and the height is too high to rescan it automatically. So there would need to be a check to make sure the wallet was saved/ the transaction is rescaned if the height was upgraded and the save was not successful. This adds a bit of complexity. I need to think this through.

All of this sounds way more complex than just saving after every transaction and every x minutes :D

<selsta> "All of this sounds way more..." <- It might not be all the bad. The onNewBlock handler is reduced to saving a number(the block height). The onOutputReceived and onOutputSpent handlers are reduced to saving a number (the height of the transaction), saving the walletdata, noting down if the saving of the wallet data succeeded. The openWallet Routine is changed to: open the wallet from the saved data, check if there were

unsuccessfully saved transactions ( if this is the case, pick the height of the one with the lowest height), setSyncHeight to the height saved by the onNewBlock Handler or the unsuccessfully saved transactions (if that was the case), start syncing.

you also have to consider that it handles reorgs correctly

changing setSyncHeight, assuming that's the refresh height, seems a bit like a hack, it should a height that is before the first transaction

<selsta> "changing setSyncHeight, assuming..." <- what do you mean by first transaction?

<selsta> "you also have to consider that..." <- what questions do I need to answer to make sure I handle reorgs correctly?

do you mean with setSyncHeight the same that you would set with the refresh-from-block-height option in CLI?

probably. It is the only API that lets me set a sync height for startListening()

right, that should be set to a block height that is before the first transaction in this wallet

selsta: hm okay so this throws a wrench into all these thoughts. 😄 Do you know why that is? what would happen if I ignored that?

if someone does e.g. rescan_bc (a full wallet rescan) then it needs to know where to start

now if you say your wallet doesn't support rescan then it might work

but it's definitely a hack of a function this isn't supposed to be used that way

I assumed it was essentially the same as doing a sync like this and basically setting the setStartHeight as a global variable. If I recall correctly this sync function is called internally in a webworker when startListening is activated (with the Height that was set via setStartHeight)

s/setStartHeight/startHeight/

i'm not familiar with the library you are using so it's best if you just try until it works because I might give you wrong advice :D

I have this import wallet screen. And it feeds the info into the createWallet() function. There is a restoreheight in there so that is basically like a rescan.

selsta: that is a good point.

I will think about that.

from the wallet file it wouldnt know that. But the wallet file is in the browser storage so the user does not have access to it. Maybe I will think more about that when I implement an export wallet function

yeah but you are probably right: it seems like a hack. The question is: is this hack worth it? Does the hack even work?

yeah it is probably a bad idea. Most likely there is some internal thing that depends on the startheight being lower than transactions that are in the cache. If somebody can chime in and dispel this FUD I would be very glad.

What could possibly go wrong? Please chime in! 🥺😀

<selsta> "do you mean with setSyncHeight..." <- okay it seems to be: github.com/monero-ecosystem/monero-…wallet/monero_wallet_full.cpp#L1364 the same as refresh from blockheight.

right, yes that's always supposed to be lower than the first transaction inside a wallez

wallet

<selsta> "right, yes that's always..." <- I wish there was a way to update the height the wallet was synced to without rewriting the whole cache. So the implication of this is that we can not just pick and choose which parts of the blockchain to scan, we need to scan from our first transaction? And there is no way around this. ?

what if this assumption is broken? rescan wouldnt work as expected. Anything else that would break? the old transactions should still be in the cache, right?

the wallet internally saves the last height it scanned to, and it continues from there, but i don't know if that is accessible

selsta: true. there is a getHeight() API to retrieve it. But there is no way to set it with the monero-javascript library. Maybe wallet2.h has a direct interface to set it.

can you use that to save?

selsta: You can not really depend on that. especially not to do something expensive like saving the wallet data. I also dont think it is the right way to do this. The saving of the wallet data should be completely decoupled from user interaction. It is something that should be triggered by the syncing process.

the next best thing is a periodical save

tobtoht: how did you implement saving in feather?

github.com/monero-ecosystem/monero-…/js/wallet/MoneroWalletFull.js#L680 okay under the hood it looks if getHeight or getSyncHeight is higher and picks the max to sync to. The real question this boils down to is reorgs: monero.... (full message at libera.ems.host/_matrix/media/r0/do…0eb8d80401c1cc6474522ded3430fd52494)

or maybe this is wrong because we need the hashes to detect a reorg when we reopen the wallet after a while. Probably the wallet checks the last hashes of the last blocks it synced to to make sure there was no reorg.

hm...I was reading the monerd docs not the walletrpc docs. Maybe the information in the stackoverflow answer mislead me. reorg detection happens on the monerod level, not on the wallet level, right?

spirobel[m]: wallet also has to rescan after a reorg

anyway, i would either implement periodical saving, or implement saving after scanning directly in wallet2

but hacking this together from the outside is a bad idea

selsta: is it the same as this: monero-project/monero #2177#issuecomment-315716542 ?

no

selsta: most likely you are right. 😅

selsta: do you know by chance where I can find it in the codebase?

src/wallet/wallet2.cpp

<selsta> "src/wallet/wallet2.cpp" <- linenumber? 🥺😀

you'll have to search yourself :D

i don't know myself

Hello, the response from `get_transactions` is this:

If I add `"decode_as_json":true` the response is:

In the latter case, if you parse the "as_json", you get:... (full message at libera.ems.host/_matrix/media/r0/do…8661d17666b68a4974258fc57a0546c7955)

How do I calculate the amount and decide if the vout belongs to me? I understand the view-only wallet does this. Where in the code does it do this? Can I use a JS library to do the same?

We need to scan the chain and decide if someone has transferred us XMR.

Without using wallet2 ?

In that case, you could maybe look at mymonero, which has JS code for this, though a lot of the lower level stuff calls C code converted to... stuff. wasm I think.

UkoeHB: looks like some merge error in the multisig code: paste.debian.net/hidden/75c14ff5

Posted in #monero, the poster left already.

It does build for me, so probably user error, nvm.

<moneromooo> "The exporter exports the minimum..." <- howto do incremental exports to update offline node from last week?

no need to reexport 100gb eh?

s/?/.../

IIRC the exporter does incremental automatically if the output file already exists. Memory's hazy though.

for monero-blockchain-export you can use --start-block and --stop-block to select which range to export

can monero-wallet-rpc be used to control multiple wallets?

Yes. See open_wallet, close_wallet.

That'll be slow though.

If you have the RAM and need to switch often, you may opt for multiple processes to avoid to save/load.

And don't forget to save before closing, otherwise you get to re-scan already scanned blocks on next load.

moneromooo: I wanted to do some programming with Monero but it seems there's no clear entry point.

See HACKING.md

Wait, it's docs/CONTRIBUTING.md actually, I checked.

Not sure what you mean by "entry point". First guess is "main", which is probably not what you mean...

For RPC, the list of RPC is in src/wallet/wallet*defs.h

moneromooo: isn't that for contributing to the network? I'm looking for an API to use in my program, and it seems like monero-wallet-rpc is the only thing available for that.

mikoto-chan: you can check moneroecosystem.org

UkoeHB: thanks.

yes, this site is indeed what I was looking for :)

.merges

Is there a possibility to have a Monero wallet to use on dumbphones? With increasing surveillance I am more comfortable to leave my android at home, even if it has CalyxOS.

Any thoughts on that?

Doesn't sound very dumb phone

luigi1111: My question is can it be done on a dumbphone?

That would imply the phone isn't dumb

<luigi1111> "That would imply the phone isn't..." <- Well, that's true lol

you could have a photo/screenshot of one of your subaddress QR codes for receiving funds on the go

chesterfield[m]: sure, but I was thinking an old fashioned phone with no app/google store just 3g

maybe some sort of offline signing

I might be asking the wrong questions thoj :D

featurephones with java engines could still run apps of some form

unless you name a specific phone it will be difficult to answer.. possible yes, but it might take work to port monero to such a phone, assuming they have enough resources to even run a monero wallet

but their CPU & RAM resources are tiny

actually they'd have enough resources to run native code, but being forced to use java, pretty much out of the question

I see, it literally just crossed my mind

You should just have an out and about wallet on your calyx phone that only has a limited amount of funds on it that you're okay with losing 🤷

ok, now that BP+ is approved I guess we can add it to the merge queue

chesterfield[m]: yes, that's what I am doing now. Thanks for elaborating on the question tho

moneromooo: do you want to squash? monero-project/monero #7170

OK

Done. I've put back the waiter.wait call and added another, I commented why.

jberman[m]: UkoeHB: can someone reapprove? ^

selsta: done

UkoeHB: one more thing, it's probably best to close the multisig patches for release-v0.17 right?

i think you still have one open

.merge+ 7170

Added

which one?

ok it got merged already

we still need someone to review monero-project/monero #8046, it would be a waste to not include this in v0.18

it cuts tx generation time in half

I remember looking at this PR before

so I can review it this week

ty

is there a no-signup API I can use to retrieve Monero's current price?

otherwise I'm only left with web scraping ...

mikoto-chan: community.rino.io/prices/xmrusd

chesterfield[m]: tried coingeko? it looks like they don't require signup either

nvm your solution is easier :D

chesterfield[m]: is there a list of supported cryptos for that API?

<mikoto-chan> "is there a no-signup API I can..." <- Kraken