libera #monero-dev

30 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

• 00:02
  tusko
  ELI5 how checkpointing is necessary and not a privacy concern?
• 00:03
  jeffro256[m]
  Old block probably wont change. Make hash of hash so sync go fast. Not privacy concern b/c why would it be
• 00:04
  tusko
  I'm sure IP addresses would at least be exchanged between nodes and the DNS operators, would they not?
• 00:05
  jeffro256[m]
  Only if you use DNS checkpoints
• 00:06
  tusko
  So the tradeoff is use DNS checkpoints and always stay on the 'right' chain but lose some privacy, or maintain privacy but security model is fucked without DNS checkpoints?
• 00:15
  tusko
  How is MoneroPulse not a trusted third-party?
• 00:16
  jeffro256[m]
  <tusko> "So the tradeoff is use DNS..." <- The daemon also has hardcoded checkpoints built right into the binary. If you don't use DNS checkpoints, your sync will be a little slower, that's it
• 00:19
  selsta
  the last checkpoint on moneropulse seems at height 1680000
• 00:19
  selsta
  that was years ago, it's basically unused
• 00:20
  jeffro256[m]
  Yeah honestly that feature can probably be removed IMO but the node will sync just fine with checkpoints
• 00:21
  jeffro256[m]
  *without
• 00:22
  tusko
  Yeah, I guess my question then is when will it be deprecated? AFAICT nodes still phone home so-to-speak
• 01:59
  gingeropolous
  i think it can be useful in case of emergencies
• 02:00
  gingeropolous
  not just for speeding up.
• 02:20
  tusko
  If it should remain for some incomprehensible reason, then why can't the callback to the centralized servers at least be sent over Tor.
• 02:23
  gingeropolous
  dunno. make it happen
• 02:24
  tusko
  I might do
• 07:26
  sech1
  .merges
• 07:26
  xmr-pr
  8794 8805 8808 8810 8811 8813
• 07:28
  sech1
  Can everyone take a look at these PRs one final time and maybe it's time to finally release?
• 12:38
  jeffro256[m]
  8794 needs to be opened against release
• 12:38
  jeffro256[m]
  moneromooo:
• 12:41
  moneromooo
  selsta: do you want that for 0.18 ?
• 12:44
  moneromooo
  jeffro256[m]: I just saw your last comment, updated.
• 12:44
  selsta
  moneromooo: luigi somehow only merged the one against release
• 12:45
  selsta
  monero-project/monero 1328048
• 12:45
  selsta
  so we need the last change against release
• 12:45
  moneromooo
  Oh it already open against 0.18. OK.
• 12:46
  moneromooo
  Last change you mea just the assert then, right ?
• 12:47
  moneromooo
  I'll undo that assert change since I did not realize it had been merged to 0.18 yet.
• 12:47
  moneromooo
  Less confusing to have matching patches.
• 12:51
  jeffro256[m]
  Oh I didn’t see release got merge either oops
• 12:52
  jeffro256[m]
  Yeah Probably better to keep them matching
• 12:53
  jeffro256[m]
  I’ve got a PR ooen which addresses that assert condition but it’s not as important as the rest of the PR
• 13:15
  jeffro256[m]
  I don't know anything about Windows systems programming, so I can't vouch for/against 8810 & 8811, but everything else looks good
• 13:16
  sech1
  I didn't know about this specific _beginthread() restriction either, I was just investigating why monerod ran out of resources on my PC
• 14:28
  selsta
  .merges
• 14:28
  xmr-pr
  8794 8805 8808 8810 8811 8813
• 14:29
  selsta
  moneromooo: there's a typo in 8794
• 14:29
  selsta
  `THROW_WALLET_EXCEPTION_IF` has two commas and build fails
• 14:44
  moneromooo
  fixed