01:04:27 <selsta> luigi1111w: let's act like 3 hours passed
01:11:03 <gingeropolous> the earth is spinning faster according to the internets
01:52:07 <selsta> luigi1111w: need to go to sleep soon and would like to tag before that
01:53:56 <nioc> luigi1111 approved these changes 3 hours ago
02:04:53 <ofrnxmr[m]> luigi1112:  luigi1111_: 
02:05:20 <ofrnxmr[m]> (He did say to said msg all of them 😅)
03:34:45 <luigi1111w> merged
14:15:50 <selsta> luigi1111w: tag pls whenever you wake up and come online
16:11:15 <Guest29> Wht is all this stuff,i am just tired of the questions in mind. As ECC is based on discrete logarithm problem but everyone knows Dlp repeats the sames result when squaring crosses modNo-1 means  two relativity prime no and the mod one is 17 the no squared is 7 when reaches 7^17-1 the result produced will be same so do the same happens in ecc or not
17:04:27 <luigi1111w> .
17:05:26 <sech1> I've started building v0.18.1.0
17:06:29 <jeffro256[m]> @Guest29 Could you try rephrasing please? I'm having trouble parsing that sentence
17:09:40 <jeffro256[m]> .merges
17:09:40 -xmr-pr- 8299 8323 8352 8359 8379 8381 8415 8419 8427 8428 8442 8444 8450 8460 8462 8464 8465 8490
17:10:22 <jeffro256[m]> @selsta luigi1111w are we merging the stuff in the merge queue before tagging 18.1.0 or just tagging ?
17:11:38 <luigi1111w> the queue has nothing to do with the taggin
17:11:51 <luigi1111w> g
17:18:10 <jeffro256[m]> well yeah but I was under the assumption that we were gonna flush the queue before tagging 0.18.1.0
17:18:20 <selsta> different branches
17:27:45 <selsta> v0.18.1.0 is tagged at all who participate in reproducible builds
17:41:15 <jeffro256[m]> Ah, I didn't release that ALL of them were master merges. That makes sense 
17:56:50 <scoobybejesus> linux: https://bsd.to/OQCZ/raw
18:00:16 <sech1> my hashes match with these ^
18:00:31 <sech1> still building (Windows and MacOS left)
18:01:27 <selsta> please upload them again like last time
18:01:34 <sech1> sure
18:01:41 <hyc> just started a build
18:01:49 <sech1> I'm on a notebook so it's sloooow
18:08:08 <hyc> my linux hashes match scooby
18:12:46 <hyc> ca8c9daeaee758d482d5cde94912d33b2f62656719c821b2a496fd81c0d52a79  monero-aarch64-linux-android-v0.18.1.0.tar.bz2
18:12:46 <hyc> 0ea5ddb0630d6657810d38b1968ae76ba8e54806f46a2cc9bd02602f999aa741  monero-arm-linux-android-v0.18.1.0.tar.bz2
18:16:23 <hyc> 1076d260b8b8fe513653916dabfa3c3790030836750d3af6bca56fc138a06af1  monero-x86_64-unknown-freebsd-v0.18.1.0.tar.bz2
18:24:44 <hyc> ed18233503b6135a29732a79b261b50aced24b99686843bc11e7e9fb2d50cf42  monero-i686-w64-mingw32-v0.18.1.0.zip
18:24:44 <hyc> d0e2b3255163ec0499de42639cc86cf4ddae0bc5fa65aa7377ff9c40305da8fd  monero-x86_64-w64-mingw32-v0.18.1.0.zip
18:31:57 <hyc> 065766f5799c6b972145e2b27830a584c18f64bdd276f31801493b7ef9e51b3c  monero-aarch64-apple-darwin11-v0.18.1.0.tar.bz2
18:31:57 <hyc> da87ac5c713f17985cd57bcd007ec76ffe75123cb546cd655edb14fdd8c3d745  monero-x86_64-apple-darwin11-v0.18.1.0.tar.bz2
18:32:00 <hyc> all done
18:32:43 <sech1> lol, how many CPU cores do you have?
18:32:56 <sech1> I started 2 hours before it was tagged, and it's still building on my notebook
18:44:14 <hyc> 8 cores, make -j8
18:47:34 <sech1> hmm, I use 4 cores and it's been going for almost 4 hours. Maybe it's because it's a fresh Ubuntu VM
18:48:34 <hyc> this system already built v0.18.0.0 so all the dependencies were already present
19:21:56 <sech1> my hashes: https://paste.debian.net/hidden/8de04bc0/
19:22:54 <sech1> selsta binaries: https://p2pool.io/v15/
19:23:43 <selsta> ty
19:31:27 <sech1> Running v0.18.1.0 on my nodes, so far so good
19:34:21 <hyc> just noticed this on my v0.18.0.0 console
19:34:21 <hyc> 2022-08-10 12:38:10.371 I Recalculating difficulties from height 2661600 to height 2686520
19:34:26 <hyc> never seen that before
19:34:33 <selsta> it shows up once per week or so
19:35:42 <hyc> ok. well, it's on 18.1 now
19:38:52 <sech1> It was a workaround for some old difficulty bug which is fixed now, but the weekly recalculation is still there just in case
19:39:59 <selsta> difficulty bug was not fully fixed while https://github.com/monero-project/monero/pull/8384 was merged
19:40:04 <selsta> so there is still a bug somewhere
19:40:44 <hyc> hmm. not reassuring...
19:41:16 <selsta> but it's also possible that it got triggered because "Make RPC server functions that read db thread safe" was wrong
19:41:48 <selsta> sech1: i remember you also got back inconsistent data with it, right?
19:43:25 <sech1> yes, ZMQ notification returned new block, but get_block_template returned the old block height
19:44:51 <selsta> since we currently calculate the difficulty once with cache and once without there is no risk if a difficulty drift is detected, it would just print a spammy log message
19:46:35 <jberman[m]> unless I'm missing something I don't think 8384 is related to this difficulty recalculation
19:46:43 <sech1> it isn't
19:46:50 <selsta> not recalculation
19:47:07 <selsta> while we had 8384 merged the daemon would get a difficulty drift every couple days
19:47:16 <selsta> the cache and the non cache values would drift apart
19:47:31 <selsta> ofrnxmr[m] can confirm
19:47:50 <jberman[m]> interesting
19:48:03 <selsta> sorry, not 8384 but the patch that got reverted by it
19:48:55 <jberman[m]> right I follow, that's strange
19:49:16 <selsta> https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L978
20:03:16 <hyc> huh, #8491 didn't get merged into v0.18.1.0?
20:05:38 <selsta> should be fine to include in the next release
20:08:01 <selsta> .merge+ 8491
20:08:01 <xmr-pr> Added