11:02:31 <plowsof> 9574 is said to reduce wallet-rpc bandwidth usage under certain conditions (open / closing a wallet). ofrnxmr mentioned here https://libera.monerologs.net/monero-community/20241123#c463404 , is there anything special regarding timing / number of calls to observe this? open a wallet - then send a close wallet call directly after before its finished?
11:02:31 <plowsof> or just use wallet rpc "normally" to open / close 1?several? wallets? 
11:47:11 <m-relay> <r​brunner7:monero.social> I understand this as such: Programs closed wallets and assumed that the close call does its job correctly and does not only close, but also save the state of the wallet. In some circumstances, it did *not* save because of a bug. The next open call had to sync all over again because of this erronous not-saving. Now the bug is corrected, close does always save, and an open immediate<clipped message>
11:47:13 <m-relay> <r​brunner7:monero.social> ly after a close has almost nothing to do, like it should be.
11:48:33 <m-relay> <r​brunner7:monero.social> I dimmly remember that years ago I had cases where mysteriously an "RPC driven" wallet did not save, but I could never reproduce to debug. So now it's finally clear why :)
12:57:22 <m-relay> <0​xfffc:monero.social> Correct.
13:31:55 <ofrnxmr> In ALL circumstances it didnt save (rbrunner)
13:32:24 <ofrnxmr> Open > open (without close), dis properly save
13:32:51 <ofrnxmr> If you close > open, it did not. Otherwise, correct, rbrunner
13:33:02 <ofrnxmr> s/dis/did
13:35:23 <ofrnxmr> To reproduce, open_wallet Y. Wait a 1 min, close_wallet > open_wallet Y. repeat. After a day or 2, wallet starts using gbs of data per hr
13:36:05 <rbrunner> Right. I missed the chance to find the bug already years ago. Found a comment in my monerotech source:
13:36:15 <rbrunner> "For quite mysterious reasons the 'CloseWallet' call at least on Windows does not save the wallet, as it should, but just "throws it away"
13:36:24 <ofrnxmr> Use the same wallet on each open
13:37:01 <ofrnxmr> Yes, and windows requires closing if you issue "open_wallet" on the same wallet (windows locks the file)
13:38:07 <rbrunner> It's a bit disheartening that such bugs manage to stay for years ...
13:38:36 <ofrnxmr> its ok. Its monero
13:39:08 <ofrnxmr> The original fix bt 0xfffc removes a line that was introduced with bytecoin
13:40:22 <ofrnxmr> https://github.com/monero-project/monero/pull/9592 stuff like this is also disheartening.
13:40:37 <ofrnxmr> https://github.com/monero-project/monero/pull/9591 and this
13:41:10 <ofrnxmr> Who knew "block" or "block time" could have so many definitions? 🙃
13:41:41 <ofrnxmr> --ban-list and --enable-dns-blocklist. Sir. What is the diff between a banlist and a blocklist?
13:42:33 <rbrunner> Well, such things have at least one positive side-effect: Hopeful new devs who want to start with Monero always find something to do :)
13:43:16 <rbrunner> "diff between a banlist and a blocklist" Isn't that clear? 2 letters less.
13:47:36 <ofrnxmr> :D
13:48:09 <ofrnxmr> what about ban time and block time and block time?
13:48:58 <ofrnxmr> "one block time is 2min, the other is how long to ban a peer"
13:50:32 <m-relay> <0​xfffc:monero.social> Yes, the word block has many meaning in this context.
13:50:55 <rbrunner> Ah, now I see.
13:57:34 <moneromooo> Please do not use the word "context" except in the sense of data attached to a peer network connection. It is confusing.
13:57:57 <moneromooo> It forces me to attach context to a word. Which is... AAAAH I just did!
14:06:28 <xFFFC0000> moneromooo: touché 
20:57:05 <m-relay> <o​xetn:matrix.org> i made a monero dicing bot, if anyone wanna test https://t.me/monerocasinobot
20:57:07 <m-relay> <o​xetn:matrix.org> min bet is 0,001 XMR