does anyone have detailed timing data related to syncing a new node?

rbrunner might (6282).

It varies a lot

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...

mostly interested in the proportion spent on different activities, within the various hard fork eras

one hour for the entire blockchain?

iirc yes.

I can try a fresh sync now and see what it is

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.

"with updated hashes in the code" <- not full verification.

 

It takes a good deal longer if you need to run full verification

Possibly single threaded verification, moo?

or at least I don't think it uses anything near the cpu core limit

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.

MRL spends a lot of time thinking about tx verification speeds, how do actual contributions stack up?

IIRC the brute force median on 100k too on the same order of magnitude as the rest of the block verification. Very roughly.

took the same

does that include tx verification or just the block itself (header and miner tx)?

Probably the whole thing.

Actually, scratch that, not sure enough to tell.

same order of magnitude sounds like 10-50%

Oh, since iy must have been testnet, it was likely the same either way.

ah this rolling median struct might be what Im hoping for

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.

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:

Find your latest signed commit and display it with: git log --show-signature --format=raw

Copy the signed part into: gpg --verbose -v -v -v --verify

There's a paper on practical SHA-1 attacks with applications to PGP: eprint.iacr.org/2020/014

Checl the line with: digest algo N,

There will be a talk on it shortly at RWC, after the current talk; you can watch: totalwebcasting.com/view/?func=VOFF&id=columbia&date=2020-01-08&seq=1

If N is 2, you're hosed. If it's 8, you're good. If it's something else, it depends on the details.

I *think* using a recent git is enough to have it use SHA256.

Did they actually migrate?

I know it's been discussed

Well, my sigs use SHA256 and I did not modify my git.

Oh, excellent

pony uses SHA256. luigi does too now. I have not checked other people.

What about object identifiers? Those were SHA-1

they are planning to do the migration away from SHA-1 in two steps. firstly converting local repositories to SHA-1

s/to SHA-1/from SHA-1/

an important difference!

:D

Soon, MD5

FWIW there are apparently methods for detection of such collisions, and git apparently incorporates them

GitHub discussed it in 2017: github.blog/2017-03-20-sha-1-collision-detection-on-github-com

(for an earlier SHA-1 collision)

Oh, very nice. So if you pull and the repo got worked on you'll see some error when pulling ?

I'm not sure what the user-facing effects are

Hopefully it still means a quick-but-safe migration away from SHA-1...

updating git was all it took, no other changes

fyi moneromooo

The SHA-1 talk is happening now on that livestream

ty

when the previous SHA1 collisions were being discussed, simply committing the PoC to your repo was enough to permanenetly corrupt it.

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.

get_block_reward

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

xmrchain.net/tx/eabbcf7c86134836659…9f57788a72385ad4ee612648fb35292ba6b 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?

easier to see here moneroblocks.info/search/eabbcf7c86…9f57788a72385ad4ee612648fb35292ba6b

It's as intended. It created "nice" outputs, and these will yield rct outs when spent.

ok, qute ancient history ^.^