14:13:12 <sech1> hyc I got "Failed to create a read transaction for the db: MDB_READERS_FULL: Environment maxreaders limit reached" when starting the block explorer, and this error refused to go away until I restarted monerod too. Is it something familiar? Any idea what caused it and how to fix it?
14:13:46 <sech1> monerod is v0.18.3.3-release
14:48:47 <selsta> gingeropolous: i think you have dealt with this, right? ^
14:49:05 <selsta> there is some mdb tool command to reset readers
14:49:52 <selsta> https://github.com/moneroexamples/onion-monero-blockchain-explorer/issues/178
14:57:45 <sech1> and how to build this mdb_stat.c? Standard build process doesn't seem to build it
15:01:44 <sech1> "make mdb_stat" in external/db_drivers/liblmdb did the trick
16:44:42 <vthor> Has monero also the possibility to timelock addresses for spending on the chain? Is it also somewhere in cli or gui?
16:53:20 <m-relay> <c​t:xmr.mx> You can create transactions where the output is only spendable after a certain block height - but you can't specify a conditional time lock as would be required for atomic swaps. (The existing swaps use the scripting ability of the other coin)
17:05:28 <m-relay> <r​brunner7:monero.social> And those locks will soon be gone, probably with the next intermediate software update
17:08:25 <vthor> ct: this was actually not my purpose in mind, I was more thinking to lock in future funds which unlock over time to never be again in a situation like today. In a way to make sure that I have a daily payout...
17:09:52 <vthor> r​brunner7: heck why? I mean, time lock I had prefered over height lock, but it would be still enough. Also I would have anothe use case for a project I have in my mind.
17:13:17 <m-relay> <r​brunner7:monero.social> vhthor: https://github.com/monero-project/monero/pull/9151
17:13:31 <m-relay> <r​brunner7:monero.social> Don't miss the very long discussions behind the first link either: https://github.com/monero-project/research-lab/issues/78
17:14:25 <m-relay> <r​brunner7:monero.social> Reading through that will probably keep you busy a while :)
17:50:40 <vthor> :D I'm already busy with the polyseed implementation, where I have the feeling int8, int16 and unsigned arithmetic makes my head explode, on the surface same code, but somewhere I mix the bytes up.
18:23:02 <selsta> rbrunner: please review https://github.com/monero-project/monero/pull/9343/
18:42:51 <m-relay> <p​reland:matrix.org> It should also be noted that the transaction freeze functionality is actively being deprecated in Monero, and likely will not exist at all very soon
18:44:38 <vthor> r​brunner7: Well, as usual I think I'm to late with my thoughts :D we (I) will see where it goes, but I planned in the future to lock funds that I have every day at least 1xmr whatever happen. I spent so often crypt I didn't want to touch because of an emergency of "something important" and of course things cam different and I didn't put it back after and some weeks/months/years later I regreted... But I see there are enough cons... And for the project I 
18:44:40 <vthor> have in mind it would be a payment service where you pay in XMR and the service pays in another -not-privacy-coin every two month for 10, 20 or 50 years, and there it would be handy if the funds for that only released over time. And although it would not avoid ripoff it would to some extend keep the service provider most probably more honest.
19:24:55 <m-relay> <r​brunner7:monero.social> selsta: Will take a look at #9343 in the next few days
19:30:11 <m-relay> <r​brunner7:monero.social> vthor: Yes, as I understand it, such use cases and similar ones turned up in the discussions as probably the most convincing ones. In the opinions of most people the disadvantages had stronger weight however. I mean, those locks do have possible uses without doubt, it's just that the trade-offs do not align.
19:36:26 <m-relay> <r​brunner7:monero.social> Funny, that #9343 is a single line commit! But I guess it will me take some time to see what exactly happens if that boolean is set, and to get sure there are no possible negative side effects.
21:17:21 <m-relay> <j​effro256:monero.social> AFAICT, we only deserialize the tx base. The rest is sent over the wire but not used
21:17:38 <m-relay> <j​effro256:monero.social> i'll release a couple functional tests soon