10:00:16 As far as I can see from the code, it's possible to speed up sync by providing up to date checkpoints: https://github.com/monero-project/monero/blob/master/src/checkpoints/checkpoints.h#L40 and https://github.com/monero-project/monero/blob/master/src/cryptonote_core/cryptonote_core.cpp#L383 10:00:24 How to generate this checkpoints.json? 10:01:23 Suppose I have up to date Monero node and want to bootstrap a new one, and I don't want to just copy over lmdb/data.mdb 10:01:49 selsta moneromooo ^ 10:02:39 Checkpoints don't speed sync up, it just prevents you from syncing the wrong chain. 10:02:55 Which is kind of a speedup in a way, but I don't think that's what you want ? 10:03:17 The hash of hashes system does speed things up. 10:03:34 And that one's generated with monero-blockchain-export 10:03:59 I do't think thr json checkpoints system was ever used beyond testing. It's *really* old. 10:04:27 It was a crutch to allow people to sync in case of attack early on. 10:12:04 But to the actual question, I do not know offhand, but I assume it's by hand, same as the hardcoded ones. Lookup the hash at a given height, write this with the right keys. 10:32:15 Yes, I mean hash of hashes that's used to speed up sync until certain height 10:33:55 Because as soon as monerod runs out of these, sync gets really slow 11:02:56 sech1: v0.18.2.0 contains hashes up until 2-3 weeks ago 11:04:47 ./monero-blockchain-export --output-file checkpoints.dat --block-stop 2817000 --blocksdat 11:11:00 So there's no way to feedd this file to monerod except compiling it? 11:15:18 i don't think so 11:21:06 Correct. Easy to change though if you want, it's loaded as a blob. 11:36:12 Ok, so I can just build my own monerod every time 20:13:28 why can't we propagate hash-of-hashes lists across p2p? 20:22:00 "why can't we propagate hash-of-..." <- Could you be more precise? 20:25:39 they're currently hardcoded, compiled into each new release binary 20:25:57 Instead of doing what sech said and hardcoding each node, why cant we have node update and share the hash of hashes dramatically 20:26:59 (I was replying to someonelse, not reasking 🙏) 20:26:59 there is an element of trust involved, obviously the HoH list in the binaries is in a reproducible build, and trustworthy 20:27:48 anything pulled over the p2p link could be fake, but that isn't any different from following a fake/forked chain is it? 20:31:07 could have some rule like: use hash-of-hashes until within 1000 blocks of chain tip 20:32:47 so whenever you're doing IBD or catching up from a long time offline, it will use the compiled in HoH for as long as they last, and then HoH from network until it's nearly caught up, then switch to normal verification 20:32:57 Maybe should use hardcoded hoh without a special flag "--sync-using-hashes". Nodes without flag ignore hashes from others, but still calculate them to distribute. 20:32:57 Ones with the flag will use hoh up to 720 blocks until tip 20:33:25 it requires trust right now 20:33:45 if nodes included it in blocks they mine, it would've been a different story 20:33:52 then it would be confirmed with PoW 20:34:20 sounds like a good feature to add for next hardfork? 20:37:30 A mining node includes hash of the last 256 block hashes in block N, and syncing nodes check PoW for the next 256 blocks (N...N+255) to consider this hash of hashes confirmed by the network. Something like this. 20:37:37 Then syncing node will only need to check PoW 20:38:23 In practice syncing nodes will just download blocks until N+256 first, then check PoW and consider blocks up to N valid after checking hashes 20:38:33 makes sense 20:39:03 not in every block, only in blocks numbered (N % 256 == 0) 20:40:17 yes 20:40:19 that would eliminate a ton of random I/O from block verification 20:40:26 the same way built-in hashes work now 20:40:27 plaster it inside the tx hash list on those :') 20:40:43 no, in tx_extra for the coinbase transaction 20:40:49 fair enough 20:42:03 worth writing this up as a github issue? 20:43:46 wouldn't mining a block already include the previous 256 hashes, in the way of the PreviousId chain? 20:55:33 technically yes 20:56:15 hash of hashes allows monerod to skip transaction verification in exchange for using trusted source of hashes (built into the binary) 20:57:22 so it's basically "yolo" sync mode where it only checks PoW and trusts that other nodes which produced that PoW, also checked transactions 21:01:51 so only needs headers ever 256 blocks 21:15:28 And nodes that are up to sync would be verifying on the fly. Only nodes who fall behind would skip verification.