03:18:18 i have asked a question on stackoverflow about the implementing double precision floating point math using 3 other rounding modes implemented in terms of nearest ties to even. if this were to be solved it could open up the ability to run randomx in languages like javascript, webassembly, python and so on that don't have the ability to properly 03:18:18 change the rounding mode. https://stackoverflow.com/questions/78776730/double-floating-point-operations-using-four-ieee-rounding-modes-implemented-in-t 03:18:37 maybe some of the monero people here might be able to take a look since it concerns your hash function 04:35:05 I believe to remember that using those floating point modes is "not a bug, but a feature", a design feature, in a way. You want to make life for ASIC designers as hard as possible, and that's one part of the puzzle there. If implementations of RandomX in environments like JavaScript + WebAssembly fall by the wayside as "collateral damage", so be it. Check e.g. this discussion from 04:35:06 2019: https://github.com/tevador/RandomX/issues/81 04:36:35 And anyway, in most circumstances mining Monero even with full native speed is hardly economical, imagine to make your RandomX implementation slower still ... 06:31:20 i'm afraid you have to implement this in software for executing RandomX on WASM and similar; for Python, Node.JS, Java, Go etc. you can use C++ bindings. 06:32:02 maybe https://accurate-algorithms.readthedocs.io/en/latest/ch02ieee754.html#rounding can help you to implement floating point number rounding modes 06:38:05 SoftFloat has an IEEE 754 implementation in pure C: http://www.jhauser.us/arithmetic/SoftFloat.html 06:39:45 the file f64_roundToInt.c file implements all the rounding modes required by RandomX 06:40:34 hi need help 07:15:24 I answered him on stackoverflow https://stackoverflow.com/questions/78776730/double-floating-point-operations-using-four-ieee-rounding-modes-implemented-in-t 10:20:17 FYI - https://www.themoneromoon.com/p/the-monero-moon-issue-71 12:24:57 last round of merges before tag, is anything still open that should be included in v0.18.3.4? 12:40:57 PR 9135? 14:22:04 .merges 14:22:04 -xmr-pr- 9287 9345 9357 9380 14:36:23 Is it correct that when I compile from the master tree and then run `monero-wallet-rpc --version` I get: v0.18.1.0-release ? 14:43:13 no if you build from master you should get a commit hash in the version, e.g. v0.18.1.0-caa62bc9e 15:03:44 okay, well that is what I get for linux-x86_64, on RPi I got v0.18.1.0-unkown (well could be because I transfered my folder via scp and maybe didn't copy .git). But so master is v0.18.1.0 or v0.18.3.3 but the version wrong? 15:17:24 Master is v0.18.1.0 but it just has old version number. It actually has all the recent PRs. 15:27:11 sech1: just, to clarify, because the response confused me a bit. So master is the code v0.18.3.3+ but with the wrong version number.? 15:27:47 Yes 15:28:40 sech1, thank you very much! is there one single point to change this easy to let's say `0.18.3.3-modified`? 15:30:53 I added to enpoints to import/export the key images as binary blow, how monero-wallet-cli writes/reads the files. And how i have seen you are on the edge of v0.18.3.4, I don't want to bother with a PR either (would be anyway my first PR ever and didn't check what is all necessary for it) 15:31:01 It is in some header file, but I don't remember. Check how it's done in release-v0.18 branch, look for "prepare v0.18.3.3" or similar commits 15:31:13 s/to endpoints/two endpoints/ 15:32:00 sech1: thank you again! :) 17:34:43 b​oog900: do you think 9135 is tested/reviewed enough to merge? 17:35:24 vthor: it says unknown because it can't find your local git commit for some reason 17:35:34 if you didn't copy the .git folder that would explain it 17:53:26 Is there a rust library that wraps wallet2.h? 17:53:58 selsta: makes sense, but on the build on my notebook, dynamically and static linked build say both "Monero 'Fluorine Fermi' (v0.18.1.0-release)", just for you information, not bothered about it, next build I wil search to put current version with '-modified' in that header file. 17:56:02 Is there a rust library that wraps wallet2.h? 19:00:21 does it have to wrap wallet2 or just able to function as a monero wallet 19:08:39 he left irc already 20:25:16 Hi there! I have a question about Monero node. Is it possible to get IP addresses of those nodes that find blocks? I was researching logs and code in repo, but I haven't found where node return this information. I want to collect IP addresses of pool operators to add it in priority list. Can you give me some guidance on this, please? 20:47:03 You can't get this information directly, you can only observe the network and collect data over time 20:57:55 Yes, I understand that it's only possible over time, but I'm struggling to find log messages which return this info 21:01:18 you can increase log level and look for NOTIFY_NEW_BLOCK p2p messages 21:04:37 oleg_krx: The `net.p2p.msg:INFO` log level should give you `NOTIFY_NEW_FLUFFY_BLOCK` log messages. 21:05:33 For best results, you need to connect to every node on the network. There are about 10,000. Good luck. 21:10:59 I guess I'm missing something, but I cant see either 21:10:59 NOTIFY_NEW_BLOCK: https://github.com/monero-project/monero/blob/caa62bc9ea1c5f2ffe3ffa440ad230e1de509bfd/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L477 21:11:00 or NOTIFY_NEW_FLUFFY_BLOCK: https://github.com/monero-project/monero/blob/caa62bc9ea1c5f2ffe3ffa440ad230e1de509bfd/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L555 21:11:00 to return peer IP address 21:17:20 oleg_krx: When I enable that log level, I get log messages like `[: ] Received NOTIFY_NEW_FLUFFY_BLOCK (height , txes)` 21:18:08 Ok, thank you very much! I'll try it