11:38:16 <koe> does anyone have detailed timing data related to syncing a new node?
11:40:54 <moneromooo> rbrunner might (6282).
11:41:06 <Inge-> It varies a lot
11:41:42 <Inge-> just after a release, with updated hashes in the code, I think I did it in like an hour, while the same hardware required 3-4 hours some time later...
11:42:30 <koe> mostly interested in the proportion spent on different activities, within the various hard fork eras
11:42:57 <koe> one hour for the entire blockchain?
11:48:03 <Inge-> iirc yes.
11:48:14 <Inge-> I can try a fresh sync now and see what it is
11:49:52 <koe> maybe I am using the wrong words.. I mean verifying the entire blockchain from genesis to now (all the signatures, blocks, etc). One hour seems super fast but maybe your computer is badass.
11:53:44 <moneromooo> "with updated hashes in the code" <- not full verification.
11:57:52 <Inge->        
11:58:13 <Inge-> It takes a good deal longer if you need to run full verification
11:58:30 <Inge-> Possibly single threaded verification, moo?
11:58:42 <Inge-> or at least I don't think it uses anything near the cpu core limit
11:59:06 <koe> I am mostly interested in the time spent sorting block sizes, especially in the latest version with long block times where every block sorts the previous 100000 blocks at least once. A full timing profile could reveal other interesting things too.
12:00:21 <koe> MRL spends a lot of time thinking about tx verification speeds, how do actual contributions stack up?
12:01:11 <moneromooo> IIRC the brute force median on 100k too on the same order of magnitude as the rest of the block verification. Very roughly.
12:01:34 <moneromooo> took the same
12:02:57 <koe> does that include tx verification or just the block itself (header and miner tx)?
12:03:20 <moneromooo> Probably the whole thing.
12:04:01 <moneromooo> Actually, scratch that, not sure enough to tell.
12:04:24 <koe> same order of magnitude sounds like 10-50%
12:04:28 <moneromooo> Oh, since iy must have been testnet, it was likely the same either way.
12:14:02 <koe> ah this rolling median struct might be what Im hoping for
12:16:58 <moneromooo> It does not handle the pop one case if you fancy making it so. I looked at it and it was a bit hairy so I left it. Though I did make a patch to only recalc after popping all the blocks IIRC.
16:08:58 <moneromooo> BTW, someone's talking about PGP/SHA1 in another channel, so for everyone who uses git to GPG sign commits, please check whether you sign using SHA1 or SHA256:
16:09:28 <moneromooo> Find your latest signed commit and display it with: git log --show-signature --format=raw
16:09:41 <moneromooo> Copy the signed part into: gpg  --verbose  -v -v -v --verify
16:09:42 <sarang> There's a paper on practical SHA-1 attacks with applications to PGP: https://eprint.iacr.org/2020/014
16:10:02 <moneromooo> Checl the line with: digest algo N,
16:10:13 <sarang> There will be a talk on it shortly at RWC, after the current talk; you can watch: https://totalwebcasting.com/view/?func=VOFF&id=columbia&date=2020-01-08&seq=1
16:10:24 <moneromooo> If N is 2, you're hosed. If it's 8, you're good. If it's something else, it depends on the details.
16:10:38 <moneromooo> I *think* using a recent git is enough to have it use SHA256.
16:10:52 <sarang> Did they actually migrate?
16:10:58 <sarang> I know it's been discussed
16:11:16 <moneromooo> Well, my sigs use SHA256 and I did not modify my git.
16:11:30 <sarang> Oh, excellent
16:11:39 <moneromooo> pony uses SHA256. luigi does too now. I have not checked other people.
16:11:57 <sarang> What about object identifiers? Those were SHA-1
16:13:01 <asymptotically> they are planning to do the migration away from SHA-1 in two steps. firstly converting local repositories to SHA-1
16:13:32 <asymptotically> https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt
16:13:57 <asymptotically> s/to SHA-1/from SHA-1/
16:14:06 <sarang> an important difference!
16:14:14 <moneromooo> :D
16:14:22 <sarang> Soon, MD5
16:16:07 <sarang> FWIW there are apparently methods for detection of such collisions, and git apparently incorporates them
16:16:34 <sarang> GitHub discussed it in 2017: https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/
16:16:48 <sarang> (for an earlier SHA-1 collision)
16:19:37 <moneromooo> Oh, very nice. So if you pull and the repo got worked on you'll see some error when pulling ?
16:20:15 <sarang> I'm not sure what the user-facing effects are
16:20:42 <sarang> Hopefully it still means a quick-but-safe migration away from SHA-1...
16:33:31 <luigi1111w> updating git was all it took, no other changes
16:33:55 <luigi1111w> fyi moneromooo
16:34:24 <sarang> The SHA-1 talk is happening now on that livestream
16:34:27 <moneromooo> ty
21:17:52 <hyc> when the previous SHA1 collisions were being discussed, simply committing the PoC to your repo was enough to permanenetly corrupt it.
22:16:36 <koe> where can I find the max block weight check? This handle_block_to_main_chain() calculates block weight, but does not verify it's within the max block weight.
22:24:20 <moneromooo> get_block_reward
22:27:32 <koe> nvm apparently hiding in handle_block_to_main_chain() -> validate_miner_transaction() ->  get_block_reward(); it's confusing because m_current_block_cumul_weight_limit isn't really used for much
23:46:06 <koe> https://xmrchain.net/tx/eabbcf7c86134836659d5f71133879f57788a72385ad4ee612648fb35292ba6b it looks like this transaction is taking pre-coindenomination inputs and combining them into pre-ringCT outputs. Is this a bug? Shouldn't all new outputs be ringCT?
23:46:19 <koe> easier to see here https://moneroblocks.info/search/eabbcf7c86134836659d5f71133879f57788a72385ad4ee612648fb35292ba6b
23:49:30 <moneromooo> It's as intended. It created "nice" outputs, and these will yield rct outs when spent.
23:49:59 <koe> ok, qute ancient history ^.^