01:21:52 <MeowingCat> does wallet2 API have something to save current state of synchronized chain?
01:22:54 <MeowingCat> Monero::WalletListener::newBlock() is giving current height
01:23:06 <MeowingCat> but i need to save current state
07:13:13 <TrasherDK[m]> monerod release on mainnet ignoring stop_daemon command.
07:13:16 <TrasherDK[m]> screen -S "${SNAME}-${NETTYPE}" -X stuff "stop_daemon\n"
07:13:30 <TrasherDK[m]> 7fc2ce7fc700        INFO    msgwriter       src/common/scoped_message_writer.h:102  Stop signal sent
07:55:03 <TrasherDK[m]> A kill -TERM $(pidof seceensession) had to be used, to force a shutdown. Attaching the session issuing "stop_daemon", "exit" or CTRL-C had no effect.
07:55:42 <TrasherDK[m]> This is what a scripted shutdown should look like:
07:55:53 <TrasherDK[m]> 7f89e4aea700 INFO    msgwriter       src/common/scoped_message_writer.h:102  Stop signal sent... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0c3f56e5bca1dd117dcb11b2a3a69cbce8b9ad81)
09:44:30 <MeowingCat> hiiiiiiiiii
09:51:39 <MeowingCat> virtual bool store(const std::string &path) = 0;
09:51:44 <MeowingCat> i think thissssssssss
10:12:00 <moneromooo> If you can repro it, a thread dump would be useful (gdb /path/to/monerod ${pid-of-the-waiting-monerod}    then: thread apply all bt).
10:12:23 <moneromooo> I also think the net patch by wfaressuissia on github fixes it.
10:12:35 <moneromooo> (one such bug anyway)
10:15:57 <TrasherDK[m]> It's currently working as expected. It's not something I can provoke. The daemon is launched every 30 minutes, and shut down when synced. I will try if it hangs again.
10:38:24 <MeowingCat> Monero::Wallet::store() doesn't store blocks
10:38:53 <MeowingCat> isn't there anything to save blocks in wallet2???????????
10:39:37 <moneromooo> It saves block hashes. Is that enough ?
10:40:03 <MeowingCat> it is enough to synchronize right??
10:40:09 <moneromooo> Yes.
10:40:11 <MeowingCat> but how does it save hashes??
10:40:28 <moneromooo> By... writing to disk...
10:40:36 <MeowingCat> ohhhh
10:41:04 <MeowingCat> i mean what should i do to make it save?
10:41:32 <moneromooo> Call store, which you found. It's done automatically when you exit the wallet normally.
10:41:49 <MeowingCat> just tried
10:41:54 <moneromooo> ^C is deemed normal for the purposes of this.
10:41:57 <MeowingCat> but it doesn't save blocks
10:42:07 <MeowingCat> when i restart the app
10:42:15 <MeowingCat> ohhhhh
10:42:16 <MeowingCat> waitt
10:42:26 <MeowingCat> wallet->setRefreshFromBlockHeight()
10:42:29 <MeowingCat> maybe about this?
10:43:48 <MeowingCat> im doing store() buttt it doesn't save or still getting blocks from node
10:49:05 <moneromooo> As I said, it never saves blocks. Only block hashes. If you want it to save blocks for some reason, you'll have to add that code. And your wallet won't be compatible with monero-wallet-cli.
10:49:53 <MeowingCat> i mean saving "current state"
10:49:58 <MeowingCat> im doing wallet->store("monero-wallet");
10:50:05 <MeowingCat> it saves monero-wallet.keys
10:50:26 <moneromooo> Hmm. Maybe I'm confusing things. Lemme check the code...
10:51:11 <MeowingCat> i mean should this save current state and supposed to not retrieve blocks from node when i restart the app???
10:51:43 <moneromooo> OK, if can write the keys file if you store as another name, but if not, it'll save the cache file only.
10:52:12 <moneromooo> store will save the current state to the wallet cache file, and is not supposed to retrieve blocks fom the node.
10:52:29 <moneromooo> When you restart the wallet program, it will typically try to sync to the node.
10:52:42 <moneromooo> That depends on the program. And if you've disabled auto refresh.
10:52:52 <moneromooo> But usually, it'll try to.
10:53:03 <MeowingCat> it is doing refresh
10:53:13 <MeowingCat> "refreshed" callback is being called
10:54:04 <MeowingCat> you mean doing wallet->store() is enough to save current state?
10:54:19 <moneromooo> It should be.
10:54:41 <MeowingCat> really confusing
10:55:30 <moneromooo> What do you think might be a less confusing API to save it ?
10:56:17 <MeowingCat> im doing wallet->store() but when i restart the app, it is getting blocks from node
10:57:30 <moneromooo> You can disable auto refresh if you want.
10:57:51 <moneromooo> Or do you mean it's downloading *all* blocks from the genesis block again ?
10:58:28 <MeowingCat> no not from genesis block the block that i specify with wallet->setRefreshFromBlockHeight()
10:58:57 <moneromooo> Is your wallet setup to trust the daemon ?
10:59:01 <MeowingCat> you mean if i disable auto refresh it will store current state and start from current state when i restart?
10:59:07 <moneromooo> If your daemon is on 127.0.0.1, it'll be a yes.
10:59:18 <MeowingCat> wm->setDaemonAddress("https://xmr.moneromerch.com:18089/");
10:59:20 <MeowingCat> im doing this
10:59:26 <MeowingCat> wallet->init("https://xmr.moneromerch.com:18089/", 0, "", "", true, false, "");
10:59:27 <MeowingCat> and this
11:01:31 <moneromooo> That call doesn't quite match the prototype I have here, but I'll assume the daemon is untrusted since it's not on localhost.
11:02:05 <moneromooo> In that case, the wallet will quantize its current height and start asking the daemon from blocks a bit earlier than needed, for privacy reasons.
11:02:25 <moneromooo> It's to remove some bits of fingerprinting ability. Though there's probably a lot more left.
11:03:10 <moneromooo> IIRC the quantum is about 1000 blocks. So when you've synced at most ~1k more blocks, it'll start asking from blocks from a later starting point.
11:03:31 <moneromooo> Use your own node on 127.0.0.1 and it won't do tha.
11:09:39 <MeowingCat> interestinggg
11:16:54 <MeowingCat> the app has to use a remote node
11:17:10 <MeowingCat> it will use our node
11:17:25 <MeowingCat> and start synchronizing from wallet creation time
11:17:40 <MeowingCat> is there a way to make wallet2 to trust node??
11:18:39 <moneromooo> Then it'll get a bit more traffic at start. No biggie, the wallet won't actually rescan those txes IIRC.
11:18:39 <moneromooo> Which in itself can be an info leak, since the faster it goes htrough txes, the faster it can ask for more, so the node can try to make a guess, but hey.
11:19:07 <moneromooo> Yes. See wallet2.h.
11:19:18 <moneromooo> It's also a param in init.
11:20:07 <moneromooo> Here, it'll mean that the user of the wallet trusts you. Not that you trust yourself.
11:31:51 <MeowingCat> virtual bool init(const std::string &daemon_address, uint64_t upper_transaction_size_limit = 0, const std::string &daemon_username = "", const std::string &daemon_password = "", bool use_ssl = false, bool lightWallet = false, const std::string &proxy_address = "") = 0;
11:31:58 <MeowingCat> you mean this init()?
11:34:01 <moneromooo> Yes. Thought it was a parameter here, I misremembered.
11:34:26 <moneromooo> Hrm. My copy has it. Must be a recent change then.
11:35:47 <moneromooo> Still in master. What class is that init function you're quoting in ?
11:36:36 <moneromooo> Ah, found it. wallet2_api. Makes sense.
11:36:46 <moneromooo> I was looking at wallet2.
11:40:24 <MeowingCat_> meowwwwww
11:40:33 <MeowingCat> damnnn
11:50:22 <MeowingCat> i merged my C++ static library and all wallet2 libraries with ar now build time is better
11:50:27 <MeowingCat> i wrote a Makefile
11:50:45 <MeowingCat> i love GNU Makeeeee
11:53:04 <MeowingCat> what could we do if MSYS2 was not exist
11:53:25 <MeowingCat> anyone doesn't care about building Windows
11:53:30 <MeowingCat> building on Windows*
11:53:53 <MeowingCat> using Bash commands and Linux things
11:54:34 <MeowingCat> Godot takes care about building on different platforms
11:54:46 <moneromooo> You could... use Linux. In fact, one might even go as far as you could use Linux even if MSYS2 exists.
12:04:27 <monerobull[m]> how big is the blockchain file right now?
12:14:33 <fluffypony> at least 1
12:15:05 <fluffypony> at [17:32:15] ➜ ls -lh ~/.bitmonero/lmdb/
12:15:05 <fluffypony> total 276351632
12:15:05 <fluffypony> -rw-r--r--  1 ric  waffles   132G Jun 11 03:59 data.mdb
12:16:01 <monerobull[m]> thanks, im currently trying to get the blockchain data out of my docker node and into my pinode
12:19:10 <moneromooo> Less than 50 GB if pruned.
12:22:11 <fluffypony> can you prune -> move -> unprune?
12:23:58 <moneromooo> You cannot unprune.
12:24:10 <fluffypony> we could call it growing
12:24:12 <fluffypony> :-P
12:25:28 <moneromooo> fluffing
12:25:31 <fluffypony> lol
12:26:18 <fluffypony> I guess the real issue with a Pinode is HDD thrash when syncing / importing from .raw, so probably the best thing to do is just to move it whole
12:28:25 <garth> Good point.
12:29:47 <garth> It’s worth asking, at some point, if a Rasp pi has ever become fundamentally inadequate to be supported. Here’s an interesting thread: https://github.com/monero-ecosystem/PiNode-XMR/issues/65
12:30:18 <garth> Well it’s more of a single post than a thread
12:36:03 <ofrnxmr[m]> While on the topic if pruned nodes... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7f409928ec72068ce610770d506adcc916d3564f)
12:36:42 <ofrnxmr[m]> Uh. Make that 1/2/3
12:51:35 <MeowingCat> moneromooo, i was a Linux catttttt
12:51:46 <MeowingCat> in past but now im a Windows cattt
12:52:17 <MeowingCat> im using WSL instead of Linux
12:57:17 <MeowingCat> im making TXs
12:57:39 <MeowingCat> i should do Monero::PendingTransaction::commit() right???
13:01:22 <MeowingCat> tx->txid() returns a std::vector but it is empty
13:13:12 <MeowingCat> as i understand TXIDs are being cleared after tx->commit()
13:14:52 <MeowingCat> but tx->txid() is still empty before tx->commit()
13:14:55 <MeowingCat> but whyyyy
13:18:32 <MeowingCat> ohh tx->status() is 1
13:19:55 <MeowingCat> my TradeOgre address starts with 8
13:20:06 <MeowingCat> shouldn't that start with 4?
13:22:16 <moneromooo> Subaddresses all start with 8 (on mainnet). They must be using them.
13:24:18 <MeowingCat> where is subaddress index placed in the private seed?
13:24:45 <MeowingCat> or it is not placed in private seed
13:25:05 <MeowingCat> i should loook at my key derivation implementation
13:26:32 <MeowingCat> string pub_key = (int)Network + Convert.ToHexString(PublicSpendKey) + Convert.ToHexString(PublicViewKey);
13:29:50 <moneromooo> The seed generates all subaddresses. That's a metric fuckton of them. You don't want indices for all of these in your seed.
13:30:49 <MeowingCat> but where should i specify subaddress indexes?
13:31:11 <moneromooo> In account_index when calling transfer, typically.
13:31:38 <moneromooo> Wherever the API has a parameter for one, really.
13:32:00 <MeowingCat> i mean i want to allow generating subaddresses tooo in my C# library
13:32:30 <moneromooo> That API would take a subadress index. Pass it one.
13:32:41 <moneromooo> Maybe I'm missing your point :)
13:33:41 <MeowingCat> ummmmm
13:34:08 <MeowingCat> i mean im deriving Monero keys includes public address tooo
13:34:16 <MeowingCat> but i want to derive subaddresses tooo
13:41:19 <MeowingCat> where is Monero's word list?
13:44:18 <MeowingCat> found
14:44:01 <wernervasquez[m]> MeowingCat: https://github.com/WernerVasquez/gomonero/blob/master/address/subaddress.go
14:45:00 <wernervasquez[m]> MeowingCat: https://github.com/WernerVasquez/gomonero/blob/master/wallet/wallet.go
14:45:37 <MeowingCat> wernervasquez[m], tyyy
14:47:06 <wernervasquez[m]> MeowingCat: I tried to keep my code lightweight and readable. The wallet.go file has some of the logic like scanning. Please let me know if anything is not clear enough so I can update it to be more clear.
15:43:30 <ooo123ooo1234567> <sech1> "so probably some new or updated..." <- is it important ? there is a fix for it
17:06:09 <selsta> sech1: will look into it
17:06:52 <selsta> at least bisect the change that introduced this, might need help for the actual fix
17:10:18 * moneromooo unignores sech1, what's the bug ?
17:11:06 <selsta> our min glibc is at 2.26 https://paste.debian.net/hidden/7ca5dac4/
17:11:19 <selsta> some change in master branch increased it
17:11:54 <sech1> yes, latest master branch makes Ubuntu 16.04 sad
17:12:21 <sech1> Official v0.17.3.2 works fine though
17:13:10 <moneromooo> nm -a "build/Linux/cc/release/bin/townforge" | grep @@GLIBC_ | tr @ \  | sort -k3,3V | tail
17:13:29 <moneromooo> That gives you the symbols that uses the most recent glibc.
17:14:00 <moneromooo> I see getrandom being new...
17:15:03 <selsta> getentropy, explicit_bzero, __explicit_bzero_chk, reallocarray
17:15:13 <selsta> that's the one i'm seeing for 2.25 and 2.26
17:16:16 <moneromooo> What's your target ? .23 ?
17:17:41 <selsta> we previously had 2.17
18:39:00 <Monegro> Is it normal to get a ton of repeated "connection refused" on the log when trying to connect to node.moneroworld.com
18:39:02 <Monegro> ?
18:39:26 <Monegro> It's occassionally downloading some blocks
18:39:46 <selsta> try a different node
18:41:17 <Monegro> Any one in particular recommended for connecting over Tor?
18:44:35 <w[m]> Ask in #monero:monero.social 
18:44:35 <w[m]> Ill answer you there
18:45:11 <moneromooo> There are patches on github that improve connection stability over tor. Use those.
18:45:24 <moneromooo> Look for PRs From jberman[m].
18:47:18 <Monegro> thanks
18:55:11 <selsta> moneromooo: these patches are for p2p tor, i think they were asking for rpc over tor
18:55:38 <selsta> rpc over tor should be similar to normal rpc traffic
19:04:16 <moneromooo> Ah, thanks.
19:10:07 <selsta> but the patches are merged to master now so no one has to worry about it
19:10:11 <selsta> .merge+ 7774
19:10:11 <xmr-pr> Added
20:36:49 <selsta> sech1: https://github.com/monero-project/monero/pull/7773 introduced the increased glibc dependency
20:37:36 <selsta> not sure yet how to continue
20:39:56 <sech1> Try older unbound versions?
20:40:28 <selsta> i can try, but we updated it in the first place because unbound had an audit and was full of security issues
20:41:11 <sech1> Drop support for Ubuntu 16? It's been more than a year since Ubuntu 16 end of life
20:42:09 <selsta> will check tomorrow if going back with the unbound version helps, otherwise sometimes something like https://github.com/monero-project/monero/pull/6397 is also possible
20:42:41 <moneromooo> You could check unbound config to see if there's a backward compat option. Not super likely though.
20:44:04 <selsta> https://github.com/NLnetLabs/unbound/blob/13e445d50b6e2a9441d9364d4213a57781d9e6f1/compat/reallocarray.c
20:44:11 <selsta> they have some compatibility code
20:44:29 <selsta> but have to look tomorrow
22:33:50 <ooo123ooo1234567> <selsta> ".merge+ 7774" <- it isn't clear from approval whether correctness of lmdb changes was verified or not.
22:41:31 <ooo123ooo1234567> https://github.com/monero-project/monero/pull/8381, the same here both approvals before important change and after aren't clear enough to understand whether correctness of patch overall was verified, though this change is certainly more isolated than lmdb related one