09:31:55 <fictionless[m]> Hello! Can anyone explain what is Monero-wallet-cli doing on launch after I enter the wallet's password and until command input is available? It is so incredibly slow on raspberry pi 3. In the `top` I see its consuming 100% CPU during that time and it takes around 1.5 minutes to finish :(
09:53:56 <moneromooo> Probably scanning new blocks.
09:55:10 <moneromooo> sudo perf top should tell you. If mostly in ge_*, it's that.
09:55:44 <moneromooo> Actually, maybe slightly different names in the wallet as it's using a different faster lib now.
10:51:13 * fictionless[m] uploaded an image: (90KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/XYFfgZEEdSNxVoQPKcVMFVct/image.png >
10:51:22 <fictionless[m]> <moneromooo> "sudo perf top should tell you..." <- that's how it looks like
10:52:19 <fictionless[m]> I think it can't be scanning new blocks cause it happens even if it's not connected to the daemon
10:56:05 <moneromooo> It looks like ge_* and it's not connected to the daemon ? You're sure ?
10:56:30 <moneromooo> Paste the perf screen after letting it settle for a dozen seconds or so.
10:56:36 <moneromooo> (to a paste site, not here)
11:47:06 <fictionless[m]> I've figured that the longest step is generating SSL certificate:
11:47:06 <fictionless[m]> ```2022-01-25 11:46:14.476	        76f09040	INFO	net.ssl	contrib/epee/src/net_ssl.cpp:131	Generating SSL certificate```
11:48:21 <fictionless[m]> if I run without any flags it does the generation 2 times, each taking around 25-30 seconds. If I specify previously generated certificate or set --daemon-ssl disabled, for some reason there's still one Generating SSL certificate left
11:49:02 <fictionless[m]> now I need to understand why is it always generating at least one certificate and how to turn it off 🤔
12:03:56 <moneromooo> Ah, rings a bell. I think I have some patch for that...
12:05:03 <moneromooo> https://git.townforge.net/townforge/townforge/commit/14097fdc9fa552743711242b34fdd1cf66e56b9e
12:05:19 <moneromooo> Guess it might also be useful for monero.
12:08:04 <fictionless[m]> seems so! ok, do you think I can just copy that piece over or codebases diverged significantly? I'm just not Cpp developer so might be tricky for me :)
12:30:01 <fictionless[m]> and another question, that certificate is used only for bitmessage(multisig stuff) or is essential for wallet to function? And why can't previously generated one be used?
12:32:23 <moneromooo> That one should apply without issues I think.
12:32:43 <moneromooo> IIRC the cert will get generated if bitmessage needs it.
12:33:09 <moneromooo> You can use a previous one if you want, just need to write it and reload it.
12:33:24 <moneromooo> I wanted to do this, I don't recall why I did not now.
12:35:27 <moneromooo> Maybe your problem is running out of OS entropy. 25 seconds is very long for generating a cert.
12:44:20 <fictionless[m]> I don't know tbh, need to read more on that. if I use openssl cli directly, it's done much faster on average than via monero-gen-ssl-cert. I just want to run the wallet on pi zero 2 and resources are pretty constrained there. Though once wallet is started it works great. So certificates is the main bottleneck there so far
15:42:59 <binarybaron[m]> How does the discovery mechanism for remote nodes work in the GUI?
15:44:45 <localmonero05> Probably a good question for #monero-gui. ;-P
16:47:39 <fictionless[m]> moneromooo: I've applied those changes from the townforge and even on my Mac it became instant without any certificate generation step(before each one would take around 1-2 seconds) thanks! But can you please explain what functionality that patch affect exactly? I mean when can I expect message_transporter to be activated during the wallet usage?
16:49:01 <fictionless[m]> Now the worst part is that I need to run the compilation on the PI 😭
16:57:42 <rbrunner> "No Wallet Left Behind" - Make Sure Our Wallets Survive the Fork to Monero 2.0: https://github.com/monero-project/monero/issues/8157
17:00:38 <lookaside[m]> Does anyone know whether the min_height argument in this rpc function is inclusive https://monerodocs.org/interacting/monero-wallet-rpc-reference/#get_transfers? I thought it was but it doesn't seem to be:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f32b27d32c273247704502b49f32ce771d1f9a65)
17:01:39 <lookaside[m]>  * Does anyone know whether the min_height argument in this rpc function is inclusive https://monerodocs.org/interacting/monero-wallet-rpc-reference/#get_transfers? I thought it was but it doesn't seem to be:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/69dd268f24fa7dfaf0898c3fbd67c0a02fc95491)
17:02:48 <hyc> we're still at Monero 0.x. calling anything Monero 2.0 is pretty confusing, at least.
17:18:49 <Rucknium[m]1> ETH just dropped its "2.0" branding since it stoked confusion.
17:23:24 <rbrunner> You can probably relax, "Monero 2.0", that's just a harmless metaphor. And a bait to get people to read. I don't plan to really call it like that :)
17:24:16 <monerobull[m]1> It kinda goes like "what happens to my 1.0 moneros when 2.0 goes live, where can I swap them"
17:25:10 <rbrunner> Soon I will be ROFL on the floor that I write about impending doom for nearly all Monero wallets and people latch on my "Monero 2.0" metaphor ...
17:27:41 <rbrunner> How would you call it to evoke appropiate emotions if we have to rewrite, oh, only about half of the whole Monero core software?
17:35:00 <scoobybejesus> Monero 1.0  :)
17:38:06 <moneromooo> It only generates the cert if bitmessage needs it (instead of upfront).
17:49:05 <fictionless[m]> my question is more of what is the use case of bitmessage, when would anyone use it? :)
17:55:42 <rbrunner> It's used together with the MMS (multisig messaging system) for transporting data packets between wallets. You can probably forget it :)
18:46:16 <hyc> hmm. I submitted a txn and it's only showing up in txpool of my local monerod
18:46:33 <hyc> doesn't appear to have shown up on any other daemons. 5 minutes ago
18:46:50 <hyc> and print_pool_stats says 0 not relayed, no backlog
18:49:21 <moneromooo> Sent via monero-wallet-cli/monero-wallet-rpc ?
18:49:54 <hyc> -cli yes
18:50:23 <moneromooo> With the transfer command ?
18:50:35 <hyc> yes. transfer <addr> <amt>
18:50:45 <hyc> plain jane\
18:51:25 <moneromooo> Do you have --do-not-relay on the monerod command line ?
18:51:35 <hyc> no
18:52:04 <hyc> last txn I sent was thru the same daemon, but a couple months ago. went thru immediately, back then
18:52:14 <moneromooo> Very odd. wallet2 sets do_not_relay to false, and if it were a temporary network outage, the pool would stil show true for relayed...
18:52:29 <moneromooo> So if it shows false, it must have been asked not to.
18:53:26 <moneromooo> Do you have logs with "on_send_raw_tx" in monerod for that tx ?
18:53:36 <moneromooo> It logs those at 0.
18:54:01 <hyc> lemme check
18:54:38 <hyc> on_send_raw not in my .log file
18:55:21 <hyc> gonna flush the tx and try again
18:57:18 <moneromooo> Any exception log at the right time ?
18:58:12 <hyc> not that I can see. everything looks normal
18:58:47 <hyc> unable to send to i2p, no avialble outbound conn
18:59:03 <hyc> that shouldn't have stopped it from using plain IP should it?
18:59:28 <moneromooo> I'm not sure, due to dandelion. vtnerd would know for sure.
19:05:32 <hyc> if it can't get sent right away, due to no outbound tor/i2p, when will it retry?
19:06:30 <hyc> hm. I just tried manual relay_tx <txid> now and it says successful
19:14:35 <moneromooo> IIRC every 4 hours.
19:40:19 <selsta> hyc: if you have i2p and there is no i2p connection it won't send over the plain ip
19:40:36 <selsta> i2p with --tx-proxy
19:42:31 <hyc> ah thanks selsta that explains it
19:42:44 <hyc> there were no outbound tor or i2p conns at the time
19:43:49 <selsta> we have way more tor nodes than i2p nodes
19:44:36 <hyc> i run relays for both, but they seemed to both be offline at the time
19:44:45 <hyc> issues in /etc/init startup scripts ...
19:46:56 <selsta> a flag to fallback to clearnet if no connections exist would be nice
19:47:20 <selsta> I only run Tor and I2P to support the network, not really to hide my IP
19:47:53 <hyc> same
19:50:53 <abberant[m]> would there have been any benefits to kovri over i2dp? was it intended to be native to monerod?
19:53:45 <selsta> kovri is dead
19:53:55 <hyc> it was just a fork of i2pd
20:15:53 <woodser[m]> @localmonero05
20:15:53 <woodser[m]> > Can you or woodser make the new PR ahead of next week's meeting?
20:15:53 <woodser[m]> I opened a pr so the balance includes unconfirmed transfers to self: https://github.com/monero-project/monero/pull/8158/files (needs reviewed)
20:16:15 <localmonero05> Yay. Appreciate it woodser[m].
20:16:20 <woodser[m]> the balance should be correct with unconfirmed transfers and change with that pr and #6986
20:16:31 <woodser[m]>  * @localmonero05
20:16:31 <woodser[m]> > Can you or woodser make the new PR ahead of next week's meeting?
20:16:31 <woodser[m]> I opened a pr so the balance includes unconfirmed transfers to self: https://github.com/monero-project/monero/pull/8158/files (needs reviewed)
20:53:42 <merope> Doesn't that defeat the whole point of having an "unconfirmed balance" though?
21:03:47 <moneromooo> I think the point is that you still get the money minus the fee whether the tx gets mined or not. So while it complexifies the whole thing, it makes sense in user terms.
21:05:07 <moneromooo> Actually, I'm just thinking it would mess with sending money, since you see X available, but less is actually available...
21:06:06 <moneromooo> A third balance type might solve this. Uncomplexified too.
21:09:41 <jberman[m]> I'm a fan of including unconfirmed amounts in the sum of total balance, and having a 3rd "unconfirmed" balance too, like "locked"
21:11:44 <jberman[m]> sorry, like "unlocked"*
21:13:46 <jberman[m]> anyone looking at their balance wants to know the total right away, it's more intuitive for a user to have to subtract from total if they want to know what their confirmed balance is in the chain, than for the user to mentally add imo
21:17:38 <jberman[m]> I think the PR is sufficient as is though and is an improvement over current. Users should know how much is available to spend from the "unlocked" balance, and can check tx history for a tx's status. I think that's in line with UX expectations of traditional banking too, where transactions that are still processing/in pending states affect balances displayed to users
21:18:03 <jberman[m]> at least in my banking apps that's what I've seen
22:04:49 <geonic> isn't that just a UX thing for the different wallets to figure out?
22:15:08 <jberman[m]> geonic: the core repo includes a reference wallet implementation, so this is for the UX of the reference wallet impl/anyone reusing that code. different wallets can do whatever still
22:19:17 <jberman[m]> Like e.g. the CLI wallet uses this code
22:29:13 <geonic> tx. yeah if the CLI/GUI do this, others will likely follow