00:02:16 <tusko> ELI5 how checkpointing is necessary and not a privacy concern?
00:03:32 <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:41 <tusko> I'm sure IP addresses would at least be exchanged between nodes and the DNS operators, would they not? 
00:05:11 <jeffro256[m]> Only if you use DNS checkpoints
00:06:38 <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:27 <tusko> How is MoneroPulse not a trusted third-party?
00:16:35 <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:23 <selsta> the last checkpoint on moneropulse seems at height 1680000
00:19:28 <selsta> that was years ago, it's basically unused
00:20:57 <jeffro256[m]> Yeah honestly that feature can probably be removed IMO but the node will sync just fine with checkpoints 
00:21:07 <jeffro256[m]> *without
00:22:06 <tusko> Yeah, I guess my question then is when will it be deprecated? AFAICT nodes still phone home so-to-speak
01:59:23 <gingeropolous> i think it can be useful in case of emergencies
02:00:17 <gingeropolous> not just for speeding up. 
02:20:18 <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:40 <gingeropolous> dunno. make it happen
02:24:57 <tusko> I might do
07:26:28 <sech1> .merges
07:26:28 -xmr-pr- 8794 8805 8808 8810 8811 8813
07:28:19 <sech1> Can everyone take a look at these PRs one final time and maybe it's time to finally release?
12:38:21 <jeffro256[m]> 8794 needs to be opened against release 
12:38:40 <jeffro256[m]> moneromooo: 
12:41:04 <moneromooo> selsta: do you want that for 0.18 ?
12:44:13 <moneromooo> jeffro256[m]: I just saw your last comment, updated.
12:44:47 <selsta> moneromooo: luigi somehow only merged the one against release
12:45:06 <selsta> https://github.com/monero-project/monero/commit/132804811d141d29bef341fa5d30dd4b934beeb5
12:45:12 <selsta> so we need the last change against release
12:45:47 <moneromooo> Oh it already open against 0.18. OK.
12:46:06 <moneromooo> Last change you mea just the assert then, right ?
12:47:50 <moneromooo> I'll undo that assert change since I did not realize it had been merged to 0.18 yet.
12:47:58 <moneromooo> Less confusing to have matching patches.
12:51:51 <jeffro256[m]> Oh I didn’t see release got merge either oops
12:52:28 <jeffro256[m]> Yeah Probably better to keep them matching
12:53:33 <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:50 <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:58 <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:17 <selsta> .merges
14:28:17 -xmr-pr- 8794 8805 8808 8810 8811 8813
14:29:29 <selsta> moneromooo: there's a typo in 8794
14:29:59 <selsta> `THROW_WALLET_EXCEPTION_IF` has two commas and build fails
14:44:48 <moneromooo> fixed