00:00:55 <spirobel[m]> 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.
00:02:56 <spirobel[m]> 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.
00:06:14 <selsta> The periodic saving was only added because people had issues with crashes and having to rescan.
00:09:13 <nioc> 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
00:09:47 <spirobel[m]> 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.
00:11:57 <spirobel[m]> nioc: hm...so it seems like in case of the CLI wallet this state is triggered when the user issues the exit command.
00:12:21 <selsta> nioc: on Windows?
00:12:30 <nioc> selsta: yes
00:13:00 <selsta> ok, the problem is X-ing CLI programs by closing the window is the equivalent of killing them.
00:13:15 <selsta> so you either have to use ctrl+c or type exit
00:14:00 <selsta> GUI programs can properly close when pressing X.
00:14:30 <spirobel[m]> could it be more natural if the saving was triggered by the sync process instead of user interaction?
00:15:06 <selsta> spirobel[m]: is there no event or so that runs on exit? I'm not familiar with web development.
00:15:51 <selsta> if you have a large wallet cache (hundreds of MB) saving on every block might become an issue
00:17:17 <spirobel[m]> 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? 
00:17:41 <spirobel[m]> selsta: how can it become so large? I forgot what kind of data can be in the cache
00:17:53 <spirobel[m]> I will look it up
00:18:05 <selsta> if you have thousands of transactions
00:22:41 <spirobel[m]> 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.
00:25:03 <spirobel[m]> the question that arises then: (async) onOutputReceived(output)
00:25:03 <spirobel[m]> Invoked 3 times per received output: once when unconfirmed, once when confirmed, and once when unlocked.  (async) onOutputSpent(output)
00:25:03 <spirobel[m]> 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?
00:31:47 <selsta> all these events are related to a block being scanned, right?
00:32:31 <selsta> ok, not necessarily
00:32:55 <spirobel[m]> selsta: yes. The phrasing in the docs is like this: (async) onNewBlock(height)
00:32:55 <spirobel[m]> Invoked when a new block is added to the chain.  https://moneroecosystem.org/monero-javascript/MoneroWalletListener.html but it actually is more like: when a new block is being scanned.
00:34:36 <spirobel[m]> 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.
00:37:29 <selsta> if you scan e.g. 50 blocks / second you can't also save 50 times in a second.
00:38:17 <selsta> onOutput might work, you will have to try it
00:43:52 <spirobel[m]> <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
00:43:52 <spirobel[m]> 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.
00:46:14 <selsta> All of this sounds way more complex than just saving after every transaction and every x minutes :D
01:01:34 <spirobel[m]> <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
01:01:34 <spirobel[m]> 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. 
01:02:34 <selsta> you also have to consider that it handles reorgs correctly
01:03:15 <selsta> changing setSyncHeight, assuming that's the refresh height, seems a bit like a hack, it should a height that is before the first transaction
01:21:31 <spirobel[m]> <selsta> "changing setSyncHeight, assuming..." <- what do you mean by first transaction?
01:22:06 <spirobel[m]> <selsta> "you also have to consider that..." <- what questions do I need to answer to make sure I handle reorgs correctly?
01:24:41 <selsta> do you mean with setSyncHeight the same that you would set with the refresh-from-block-height option in CLI?
01:25:29 * spirobel[m] uploaded an image: (33KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/HZcHKyiHZZRnkyRNyhpryKwC/image.png >
01:26:05 <spirobel[m]> probably. It is the only API that lets me set a sync height for startListening()
01:26:40 <selsta> right, that should be set to a block height that is before the first transaction in this wallet
01:27:57 <spirobel[m]> 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?
01:28:40 <selsta> if someone does e.g. rescan_bc (a full wallet rescan) then it needs to know where to start
01:28:56 <selsta> now if you say your wallet doesn't support rescan then it might work
01:29:20 <selsta> but it's definitely a hack of a function this isn't supposed to be used that way
01:29:34 * spirobel[m] uploaded an image: (106KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/mehVJrnvBbuyCICUfaiqOjBA/image.png >
01:31:03 <spirobel[m]> 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)
01:31:23 <spirobel[m]> s/setStartHeight/startHeight/
01:31:58 <selsta> 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
01:32:25 * spirobel[m] uploaded an image: (29KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/EzQupcmFhZMggoAKuxtGzCyG/image.png >
01:33:13 <spirobel[m]> 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.
01:33:39 <spirobel[m]> selsta: that is a good point. 
01:34:01 <spirobel[m]> I will think about that. 
01:35:44 <spirobel[m]> 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
01:38:31 <spirobel[m]> yeah but you are probably right: it seems like a hack. The question is: is this hack worth it? Does the hack even work?
01:43:22 <spirobel[m]> 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.
01:44:35 <spirobel[m]> What could possibly go wrong? Please chime in! 🥺😀
01:59:25 <spirobel[m]> <selsta> "do you mean with setSyncHeight..." <- okay it seems to be: https://github.com/monero-ecosystem/monero-cpp/blob/37b97f8e52177be260ba7a5c666503482d6820df/src/wallet/monero_wallet_full.cpp#L1364 the same as refresh from blockheight.
02:01:47 <selsta> right, yes that's always supposed to be lower than the first transaction inside a wallez
02:01:49 <selsta> wallet
02:15:12 <spirobel[m]> <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. ?
02:18:30 <spirobel[m]> 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?
02:18:41 <selsta> the wallet internally saves the last height it scanned to, and it continues from there, but i don't know if that is accessible
02:19:39 <spirobel[m]> 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. 
02:20:52 <selsta> https://developer.mozilla.org/en-US/docs/web/api/window/beforeunload_event
02:22:07 <selsta> can you use that to save?
02:23:13 <spirobel[m]> 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.
02:23:25 <spirobel[m]> the next best thing is a periodical save
02:24:19 <selsta> tobtoht: how did you implement saving in feather?
02:52:54 <spirobel[m]> https://github.com/monero-ecosystem/monero-javascript/blob/ff92010b0d2df89025166f54ec1d00ce88357b60/src/main/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: https://monero.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d036e0eb8d80401c1cc6474522ded3430fd52494)
02:54:55 <spirobel[m]> 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.
03:00:24 <spirobel[m]> 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?
04:02:57 <selsta> spirobel[m]: wallet also has to rescan after a reorg
04:03:57 <selsta> anyway, i would either implement periodical saving, or implement saving after scanning directly in wallet2
04:04:20 <selsta> but hacking this together from the outside is a bad idea
04:04:44 <spirobel[m]> selsta: is it the same as this: https://github.com/monero-project/monero/issues/2177#issuecomment-315716542 ?
04:04:59 <selsta> no
04:05:16 <spirobel[m]> selsta: most likely you are right. 😅
04:06:10 <spirobel[m]> selsta: do you know by chance where I can find it in the codebase?
04:06:43 <selsta> src/wallet/wallet2.cpp
04:13:42 <spirobel[m]> <selsta> "src/wallet/wallet2.cpp" <- linenumber? 🥺😀
04:14:05 <selsta> you'll have to search yourself :D
04:14:15 <selsta> i don't know myself
08:47:56 <willshu[m]> Hello, the response from `get_transactions` is this:
08:48:17 * willshu[m] uploaded an image: (327KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/dBTalgkpoaNqAPufcZbfkyYI/Screen%20Shot%202022-04-05%20at%204.47.29%20PM.png >
08:49:08 <willshu[m]> If I add `"decode_as_json":true` the response is:
08:50:11 * willshu[m] uploaded an image: (523KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/GsGYDTiTnaAXllwjPKrrhIbi/Screen%20Shot%202022-04-05%20at%204.49.39%20PM.png >
08:52:12 <willshu[m]> In the latter case, if you parse the "as_json", you get:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2e1ae8661d17666b68a4974258fc57a0546c7955)
08:53:47 <willshu[m]> 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?
08:56:20 <willshu[m]> We need to scan the chain and decide if someone has transferred us XMR.
09:00:11 <moneromooo> Without using wallet2 ?
09:00:53 <moneromooo> 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.
09:43:00 <moneromooo> UkoeHB: looks like some merge error in the multisig code: https://paste.debian.net/hidden/75c14ff5/
09:43:19 <moneromooo> Posted in #monero, the poster left already.
11:08:52 <moneromooo> It does build for me, so probably user error, nvm.
11:10:53 <drflashd[m]> <moneromooo> "The exporter exports the minimum..." <- howto do incremental exports to update offline node from last week?
11:11:05 <drflashd[m]> no need to reexport 100gb eh?
11:11:12 <drflashd[m]> s/?/.../
11:18:04 <moneromooo> IIRC the exporter does incremental automatically if the output file already exists. Memory's hazy though.
13:12:44 <hyc> for monero-blockchain-export you can use --start-block and --stop-block to select which range to export
14:01:32 <mikoto-chan> can monero-wallet-rpc be used to control multiple wallets?
14:01:57 <moneromooo> Yes. See open_wallet, close_wallet.
14:02:16 <moneromooo> That'll be slow though.
14:02:44 <moneromooo> If you have the RAM and need to switch often, you may opt for multiple processes to avoid to save/load.
14:03:28 <moneromooo> And don't forget to save before closing, otherwise you get to re-scan already scanned blocks on next load.
14:04:20 <mikoto-chan> moneromooo: I wanted to do some programming with Monero but it seems there's no clear entry point.
14:06:03 <moneromooo> See HACKING.md
14:06:34 <moneromooo> Wait, it's docs/CONTRIBUTING.md actually, I checked.
14:07:19 <moneromooo> Not sure what you mean by "entry point". First guess is "main", which is probably not what you mean...
14:07:36 <moneromooo> For RPC, the list of RPC is in src/wallet/wallet*defs.h
14:07:38 <mikoto-chan> 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.
14:07:51 <UkoeHB> mikoto-chan: you can check https://moneroecosystem.org/
14:08:01 <mikoto-chan> UkoeHB: thanks.
14:08:31 <mikoto-chan> yes, this site is indeed what I was looking for :)
15:05:23 <luigi1111w> .merges
15:05:23 -xmr-pr- 7936 7937 8053 8166 8177 8179 8180 8195 8196 8197 8205 8207 8211 8212 8213 8215 8222 8223
17:41:16 <bit_thanos[m]> 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. 
17:41:16 <bit_thanos[m]> Any thoughts on that?
17:55:17 <luigi1111> Doesn't sound very dumb phone
17:57:44 <bit_thanos[m]> luigi1111: My question is can it be done on a dumbphone?
18:01:15 <luigi1111> That would imply the phone isn't dumb
18:08:19 <bit_thanos[m]> <luigi1111> "That would imply the phone isn't..." <- Well, that's true lol
18:08:32 <chesterfield[m]> you could have a photo/screenshot of one of your subaddress QR codes for receiving funds on the go
18:10:45 <bit_thanos[m]> chesterfield[m]: sure, but I was thinking an old fashioned phone with no app/google store just 3g
18:11:04 <bit_thanos[m]> maybe some sort of offline signing 
18:11:37 <bit_thanos[m]> I might be asking the wrong questions thoj :D
18:15:18 <hyc> featurephones with java engines could still run apps of some form
18:15:37 <selsta> 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
18:15:39 <hyc> but their CPU & RAM resources are tiny
18:16:20 <hyc> actually they'd have enough resources to run native code, but being forced to use java, pretty much out of the question
18:17:00 <bit_thanos[m]> I see, it literally just crossed my mind
18:18:17 <chesterfield[m]> 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 🤷
18:18:41 <selsta> ok, now that BP+ is approved I guess we can add it to the merge queue
18:19:49 <bit_thanos[m]> chesterfield[m]: yes, that's what I am doing now. Thanks for elaborating on the question tho
18:20:40 <selsta> moneromooo: do you want to squash? https://github.com/monero-project/monero/pull/7170
18:38:35 <moneromooo> OK
18:52:40 <moneromooo> Done. I've put back the waiter.wait call and added another, I commented why.
18:56:57 <selsta> jberman[m]: UkoeHB: can someone reapprove? ^
19:26:49 <UkoeHB> selsta: done
19:28:14 <selsta> UkoeHB: one more thing, it's probably best to close the multisig patches for release-v0.17 right?
19:28:31 <selsta> i think you still have one open
19:29:03 <selsta> .merge+ 7170
19:29:03 <xmr-pr> Added
19:31:30 <UkoeHB> which one?
19:33:26 <selsta> ok it got merged already
19:33:29 <selsta> https://github.com/monero-project/monero/pull/8190
19:42:19 <selsta> we still need someone to review https://github.com/monero-project/monero/pull/8046, it would be a waste to not include this in v0.18
19:42:36 <selsta> it cuts tx generation time in half
19:43:20 <sech1> I remember looking at this PR before
19:43:32 <sech1> so I can review it this week
19:43:50 <selsta> ty
22:33:07 <mikoto-chan> is there a no-signup API I can use to retrieve Monero's current price?
22:33:13 <mikoto-chan> otherwise I'm only left with web scraping ...
22:35:24 <chesterfield[m]> mikoto-chan: https://community.rino.io/prices/xmrusd/
22:35:52 <nikg83[m]> https://min-api.cryptocompare.com/data/price?fsym=xmr&tsyms=USD
22:36:14 <mikoto-chan> chesterfield[m]: tried coingeko? it looks like they don't require signup either
22:36:32 <mikoto-chan> nvm your solution is easier :D
23:01:28 <mikoto-chan> chesterfield[m]: is there a list of supported cryptos for that API?
23:48:48 <merope> <mikoto-chan> "is there a no-signup API I can..." <- Kraken