libera #monero-dev

12 Mar 2023

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Monero GUI dev is at #monero-gui || Monero website dev is at #monero-site || Non-dev questions -> #monero, please || No fork help, you’re on your own

• 10:00
  sech1
  As far as I can see from the code, it's possible to speed up sync by providing up to date checkpoints: github.com/monero-project/monero/bl…r/src/checkpoints/checkpoints.h#L40 and github.com/monero-project/monero/bl…onote_core/cryptonote_core.cpp#L383
• 10:00
  sech1
  How to generate this checkpoints.json?
• 10:01
  sech1
  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
  sech1
  selsta moneromooo ^
• 10:02
  moneromooo
  Checkpoints don't speed sync up, it just prevents you from syncing the wrong chain.
• 10:02
  moneromooo
  Which is kind of a speedup in a way, but I don't think that's what you want ?
• 10:03
  moneromooo
  The hash of hashes system does speed things up.
• 10:03
  moneromooo
  And that one's generated with monero-blockchain-export
• 10:03
  moneromooo
  I do't think thr json checkpoints system was ever used beyond testing. It's *really* old.
• 10:04
  moneromooo
  It was a crutch to allow people to sync in case of attack early on.
• 10:12
  moneromooo
  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
  sech1
  Yes, I mean hash of hashes that's used to speed up sync until certain height
• 10:33
  sech1
  Because as soon as monerod runs out of these, sync gets really slow
• 11:02
  selsta
  sech1: v0.18.2.0 contains hashes up until 2-3 weeks ago
• 11:04
  selsta
  ./monero-blockchain-export --output-file checkpoints.dat --block-stop 2817000 --blocksdat
• 11:11
  sech1
  So there's no way to feedd this file to monerod except compiling it?
• 11:15
  selsta
  i don't think so
• 11:21
  moneromooo
  Correct. Easy to change though if you want, it's loaded as a blob.
• 11:36
  sech1
  Ok, so I can just build my own monerod every time
• 20:13
  hyc
  why can't we propagate hash-of-hashes lists across p2p?
• 20:22
  someoneelse49549
  <hyc> "why can't we propagate hash-of-..." <- Could you be more precise?
• 20:25
  hyc
  they're currently hardcoded, compiled into each new release binary
• 20:25
  ofrnxmr[m]
  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
  ofrnxmr[m]
  (I was replying to someonelse, not reasking 🙏)
• 20:26
  hyc
  there is an element of trust involved, obviously the HoH list in the binaries is in a reproducible build, and trustworthy
• 20:27
  hyc
  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
  hyc
  could have some rule like: use hash-of-hashes until within 1000 blocks of chain tip
• 20:32
  hyc
  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
  ofrnxmr[m]
  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
  ofrnxmr[m]
  Ones with the flag will use hoh up to 720 blocks until tip
• 20:33
  sech1
  it requires trust right now
• 20:33
  sech1
  if nodes included it in blocks they mine, it would've been a different story
• 20:33
  sech1
  then it would be confirmed with PoW
• 20:34
  hyc
  sounds like a good feature to add for next hardfork?
• 20:37
  sech1
  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
  sech1
  Then syncing node will only need to check PoW
• 20:38
  sech1
  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
  hyc
  makes sense
• 20:39
  hyc
  not in every block, only in blocks numbered (N % 256 == 0)
• 20:40
  sech1
  yes
• 20:40
  hyc
  that would eliminate a ton of random I/O from block verification
• 20:40
  sech1
  the same way built-in hashes work now
• 20:40
  DataHoarder
  plaster it inside the tx hash list on those :')
• 20:40
  sech1
  no, in tx_extra for the coinbase transaction
• 20:40
  DataHoarder
  fair enough
• 20:42
  hyc
  worth writing this up as a github issue?
• 20:43
  DataHoarder
  wouldn't mining a block already include the previous 256 hashes, in the way of the PreviousId chain?
• 20:55
  sech1
  technically yes
• 20:56
  sech1
  hash of hashes allows monerod to skip transaction verification in exchange for using trusted source of hashes (built into the binary)
• 20:57
  sech1
  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
  DataHoarder
  so only needs headers ever 256 blocks
• 21:15
  ofrnxmr[m]
  And nodes that are up to sync would be verifying on the fly. Only nodes who fall behind would skip verification.