01:16:21 both of those are my emails 01:17:31 he's saying that fingerprints don't match up 01:18:08 yeah IDK what's up with that yet 06:06:14 I need a 2nd opinion on a short, but decisive matter. I'm trying to update the whole project to Python3 from v.2. I personally need it only for "functional_tests_rpc" but I thought it would be a good opportunity to do it project wise. Should I limit the change to the functional tests then? 06:06:15 https://github.com/monero-project/monero/pull/7396 06:06:35 All tests pass with Python3 07:16:29 (set globally, that is) 10:09:15 hello. 10:09:16 could someone point me to any C or JS code for generating electrum 256 bit seed from mnemonics (25 words) ? 10:09:19 thnaks 10:09:27 *thanks 10:48:44 ... 10:48:57 make it work for *both* if it doesn't currently. 10:49:05 usamat: src/mnemonics 10:49:38 I'm pretty sure I recently fixed it though. Let me see... 10:51:41 https://paste.debian.net/hidden/5a784f06/ 11:20:18 moneromooo thanks. yes im working on it. 11:27:03 I was unclear, the one line was for you, the others for mj-xmr. 11:30:07 moneromooo, both versions work, for what I can see, ie. no tests have failed for Python3 11:30:33 With the patches I posted ? 11:33:07 Ah, that's what you meant. No. 11:33:16 I will try in the evening. 11:33:40 OK, well, if you didn't break 2 and you also did it, just PR. Your wording implied 2 was broken. 11:35:37 Oh, my patches are for the console part of python code... So they'll still be needed actually. I'll also PR them. 11:35:52 Assuming you did not also change that already. 11:35:59 No 11:36:05 Didn't 11:37:02 Python2 creates notable differences in my timing calculations, but I will try to get around it with a C++ app, like iamamyth suggested. This will go in the direction Python2 and Python3 yielding the same results. But still many of his "code cleanness" comments require that I use Python3. It's generally starting to be hard to move around in Python2 realm. 11:37:22 ... which will reach EOL soon anyway. 12:21:57 would it be possible to dev a nodejs randomx miner? 12:25:56 moneromooo, The timing differences have been solved via the external C++ timing app in the below PR (warning. Lenghty) 12:25:56 https://github.com/monero-project/monero/pull/7387 12:26:13 So we dont HAVE to update to Python3, but it will bite us soon. 12:35:15 You're saying timeouts only happen with python 2 ? 12:35:36 In any case, I'm not sure it's worth wasting time just to make github servers happy. 12:35:50 (I would not unless someone annoys me about it tbh) 12:38:38 I need to bring in some context to you. There's a mining test (mining.py). With that PR, I want to make the constant timeouts more dynamic, in case the virtual machine is overused. Then the fixed timeouts make less sense. For this purpose I make a short calculation to learn what the CPU can currently handle. The results of these calculations were different for Python2 and 3, when they were done under Python itself. Now I do these 12:38:38 calculations in C++, so the Python version doesn't matter for this case anymore. 12:39:39 (the results of calculation modify (by multiplication) the otherwise fixed constants) 12:43:53 mj-xmr: https://github.com/monero-project/monero/pull/7391/checks?check_run_id=1939145281 12:44:02 seems like even with super high timeout it fails sometimes 12:44:11 so I kinda doubt this timeout is the problem in the first place 12:53:53 selsta, I could imagine this. Later on I discovered, that there are 2 timeouts (hello clean code). One is for the RX init, that I increased, but then after the 1st block is mined, an another one (10s) is set. In my PR, I handle both cases separately. 12:55:04 I would just set an env var for CI and make the code check for it. 12:55:05 For the 10s timeout case, I even simulate separately how the CPU would behave on 1 core, while the RX init readout is done for all the cores (just like the RX init behaves) 12:56:10 The problem is, that if the virtual machine is used more by other projects / monero PRs, the CPU performance will decrease, and the constants (env var or code) stop making sense. 12:56:41 Another use case: ctest -j2... 12:57:14 So running tests in parallel will also affect the CPU performance and increase the mining time. 12:58:30 From the recent logs of my PR: 12:58:32 "Timeout for init, adjusted for the currently available CPU power, is 25.4 s" 12:59:02 This is 10 times less than the fixed timeout, and will safeguard against mining regressions better. 13:02:00 selsta, So to reiterate: I increased the RX init timeout from 60 to 240, but the subsequent mining timeout remained at 10s unfortunately, which was too little. 13:03:40 https://github.com/monero-project/monero/blob/master/tests/functional_tests/mining.py#L110 13:03:50 Here it is. 13:05:21 At line 100 you can see the new 240s timeout. 13:10:03 Also, it turned out, that the error message, that you show, was exactly the same for both 2 situations: RX init and mining. I created a distinction between them. 13:10:18 So it was hard really to learn where the problem was. 13:35:13 I hope my wall of text made things somewhat clearer. 15:45:14 Hello, does anyone have example of block hashing blob? i'm trying to recconstruct get_block_hashing_blob algorithm but so far have no luck. I found 2 related stackexchange questions but they didn't help me much. 15:46:15 https://www.getmonero.org/resources/developer-guides/daemon-rpc.html#get_block_template 15:46:17 see an example there 15:50:03 Call getblocktemplate on a daemon, it's in there (as hexdump). 15:50:41 okay, will try 17:17:04 Have no access to daemon so tried to work with blob in example (block 1561970), tried to split it into information i can work with and got following results: 0707: version, 86a498d705: timestamp, f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a: previous block, 00000000: nonce, 17:17:04 fc751ea4a94c2f840751eaa36138eee66dda15ef554e7d6594395827994e31da: merkle root, 10: transaction count. And i have couple of issues with iit. Firstly, i can't understand how timestamp is serialized here, no matter how i try to decode 86a498d705 i can't get adequate timestamp. Secondly, i looked up this block by height at xmrchain and got list of 17:17:05 transaction, but when i tried to calculate root by myself based on this list, my method returned completely different result: 8261ce12d6d34b14bd09d8780ee888002a77fe79a28be897df830d162dd35a93, despite passing teststs in tests-tree.txt from monero source code 17:18:45 Timestamp's a varint, src/common/varint.h 18:01:18 ugh, still can't get right hashing blob for block 1561970. So foar i produce blob 98010707bd8098d705f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a5f950080cd30905cd318b65fb1a6d0aed36cf624d9f0f20251d4e244b3bd13d2aa49ce040a where 18:01:19 9801: header length (varint),___ 0707: version,___ bd8098d705: timestamp (varint),___ f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a: previous block,___ 5f950080: nonce (4 bytes uint),___ cd30905cd318b65fb1a6d0aed36cf624d9f0f20251d4e244b3bd13d2aa49ce04: merkle root (payout + 9 transactions),___ 0a: tx count 18:01:59 and when i run this hashblob trough keccak 256i still get different result from actiual block id 18:02:26 what am i doing wrong? 18:03:14 *misspelled: 9801: is varint-encoded length of rest of a blob, not of header 19:50:38 is the blockid computed on hash blob 22:33:51 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:01 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:06 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:10 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:17 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:42 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:51 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:34:55 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:35:02 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:35:07 /!\ this chat has moved to irc.crimeircd.net #0 /!\ 22:53:45 MVyc66J8ypXDo60zUSmzMbtNSzXahAmj2afhRrQ0srGTgtRMC4Lq4LqdNe5J3HfxxaeLaBuJgFOFXZ5756VztcRqkux2em8P9qKr8GPRkkrGxQcPGQmL5EtW