02:07:14 <hyc> wfaressuissia: https://github.com/monero-project/monero/pull/7910
02:07:35 <hyc> gingeropolous: this should be easy for you too
02:14:29 <wfaressuissia> `... -v /var/run/docker.sock:/var/run/docker.sock ...` recursive docker for better security, right ?
02:15:52 <hyc> you really believe there is a threat, from ubuntu repo?
02:16:08 <hyc> this is for convenience, not security isolation
04:01:29 <Rucknium[m]> I believe someone mentioned that there is at least one wallet implementation that does not suffer from the integer truncation bug on mixin selection. Does anyone know the name of the wallet? And any guesses on the share of txs on the blockchain generated by this wallet?
04:02:09 <Rucknium[m]> But to be clear, other than that integer truncation inconsistency, there are no known wallets that use a different mixin selection algorithm, right?
04:11:14 <selsta> vtnerd said his lws implementation does not have the bug https://github.com/vtnerd/monero-lws
04:11:20 <selsta> also possibly mymonero.com
04:13:25 <Rucknium[m]> Thanks. Any idea what percentage of transactions on the blockchain these might produce? I mean, it could be estimated statistically using data from the blockchain, but that will be a lot of work. How important are the wallets to the Monero ecosystem?
05:23:43 <Space[m]> hello. why monero-gui 0.17.2.3 has not monero submodule in tarboll?
05:30:53 <jberman[m]> Confirming MyMonero does not have the integer truncation bug either, talked to them about it!
08:29:41 <ErCiccione> I think would be good to have a place where important network improvement proposal are kept. Right now they are spread across the monero, MRL and meta repo. We should have a dedicated place so that people can browse and keep track of the proposals. Right now it's impossible unless you saved the links somewhere. Having them all in one place and maybe labelled would already be good
08:30:47 <ErCiccione> In general, the monero repos will benefit from some more structure IMO. It's all very dispersive and unorganzied at the moment. Hard to track for people who don't constantly follow development (but pretty sure it's quite hard also for those who follow)
10:30:10 <hyc> we have libeudev in gitian builds, why is it needed? The project is being abandoned (as of last week) https://github.com/gentoo/eudev
10:44:17 <mj-xmr[m]> My next area of focus is going to be the `functional_tests_rpc`, where the mining fails to stop. It happens too often lately.
10:45:16 <moneromoooo> Might be a new thing. I have monero source from circa april, run functoinal tests a fair bit, and I don't have this happening.
10:52:57 <mj-xmr[m]> I see it on GitHub Actions in ~ 10% of cases.
10:54:23 <moneromoooo> I do remember seeing it long ago though. I think it was a randomx being stuck for a while with data set init...
10:55:06 <moneromoooo> Running pstack on the daemon when the timeout occurs should help checking this.
10:55:19 <mj-xmr[m]> Thanks for the tip.
12:02:54 <selsta> Space[m]: github does not add submodules to the source archives, you have to wait for the release
14:22:10 <wfaressuissia> "https://github.com/monero-project/monero/blob/master/contrib/depends/packages/icu4c.mk#L18" should be replaced with `$(MAKE)` to use parent make flags
16:45:22 <dEBRUYNE> Can anyone of the core-team have a look? https://www.reddit.com/r/Monero/comments/pf75ep/another_reason_to_host_your_own_node/
16:45:35 <dEBRUYNE> cc luigi1111 binaryFate ArticMine pigeons 
16:46:40 <sech1> getmonero.org opens for me
16:49:59 <selsta> that's the cdn cached version
16:50:07 <selsta> web.getmonero.org is down
16:55:10 <devbordecraft[m]> Yes down for me
18:07:40 <vtnerd> moneromooo : at the time I felt that ZMQ/RPC should've been disabled by default too, but didn't want to muck with existing behavior
18:08:15 <vtnerd> zmq/pub has some small performance hit even when no one is connected, so I decided to disable by default
18:09:00 <vtnerd> when disabled (its basically) a null-ptr check to skip
18:09:19 <vtnerd> possibly overkill on the optimizations, enabling by default is less painful than going the other way though
18:13:06 <Moonlight> Is there anybody out there?
18:17:16 <moneromoooo> Thanks. 
18:18:04 <moneromoooo> While you're here, do you know of a nice ostream/istream replacement that's fast (ie, mainly not using locale) ? I'm kinda seeing this in a profile :/
18:18:25 <moneromoooo> It's for binary data so I do not care about silly locale things.
18:23:04 <moneromoooo> (having to modidy is not a problem if not too much is needed - this owuld be to use with binary_archive).
18:24:49 <sech1> I put together some extremely lightweight ostream-like code for p2pool logging, but it's only for outputting data and it's limited to 1 Kb. But you can get some ideas from there - it's not hard to write what you need from scratch
18:25:06 <sech1> log.h/log.cpp in p2pool repo
18:25:41 <moneromoooo> I started mine, but then I realized I was gonna have to emulate failbit etc etc, lots of pita...
18:25:43 <sech1> no locales, no memory allocation mostly inlined in the code
18:30:32 <sech1> or you could just make your class derived from ostream and override operator<< for everything you need
18:31:12 <sech1> and call low-level https://en.cppreference.com/w/cpp/io/basic_ostream/write from it
18:44:41 <moneromoooo> That might skip the slow shite. I'll try that, thanks.
18:49:18 <sudo_ki[m]> 'Hi all, I'm having trouble with setting up p2pool. I have built the latest version of monero-gui. I have firewall rules for the ports I've specified but when I run the software I get: p2pool get_miner_data RPC response is invalid. On the node I get: invalid zqm/sub message. Can anyone lend me a hand?'
18:49:18 <sudo_ki[m]> I tried posting this ins monero-pow, but I seems like it's a bit dead
18:49:33 <sudo_ki[m]> s/I/It/
18:51:40 <sech1> sudo_ki[m] https://matrix.to/#/!ngYKjhkIpImFEAECOy:libera.chat?via=libera.chat&via=matrix.org&via=halogen.city
18:51:48 <sech1> monero-pow room on libera.chat
18:52:42 <sudo_ki[m]> sech1: Thanks
19:59:01 <selsta> Bringing up my old idea again: I think we could noticeably speed up daemon sync by using supercop asm ecc library, like we do for wallet scanning.
19:59:22 <selsta> We would only use it for historical sync so issues in the library wouldn't cause any consensus issues.
20:02:44 <moneromoooo> Great. stringstream iterators. Kill me now.
20:44:10 <utxobr[m]> <selsta> "Bringing up my old idea again: I..." <- without losing any compilation targets either? as you said, wallet already uses it, so i guess it’s fine
20:44:30 <selsta> it would be optional, afaik windows doesn't support it currently
22:55:30 <selsta> memory leaks reported by asan, they seem quite minor: https://paste.debian.net/hidden/9980fdb3/