04:02:38 <ureallyorigin[m]> <plowsof11> "make a reddit post, wait for..." <- LOL. is it that easy to get free monero? make a sob story and wait for people to give u free monero? 
04:42:25 <opsoyo[m]> <ureallyorigin[m]> "LOL. is it that easy to get free..." <- Great way to inspire usage and bring awareness. Certainly better than lectures and technical specs most won't understand.
05:04:40 <ureallyorigin[m]> <opsoyo[m]> "Great way to inspire usage and..." <- how does that bring awareness?
05:04:54 <ureallyorigin[m]> the donator is likely already aware of monero 
05:07:26 <BoBeR182> anyone have a breached account to share the links of https://breached.vc/Thread-TSA-NoFly-List-Database-Leaked-Download
05:18:26 <ureallyorigin[m]> <BoBeR182> "anyone have a breached account..." <- are u thinking that ur on the no fly list? 
05:26:22 <BoBeR182> I think it would be fun to search up some political type people
05:26:28 <BoBeR182> snowden and the like
05:26:39 <BoBeR182> but I don't have an email that's on the breached whitelist domain list
06:30:39 <cockliuser[m]> <ureallyorigin[m]> "LOL. is it that easy to get free..." <- Some absolute chad gave out 0.5 xmr on 4chan to 5 people 
06:30:52 <cockliuser[m]> God bless /biz/
06:43:22 <Nimko> I'm curious on what you guys think but is buying monero from an atm a secure way to get it aside from P2P exchanges?
06:49:57 <ceetee[m]> many ATM's require verification with ID, face, credit card or a combination of those. If you can pay with cash and without verification, ATM is a good option
06:52:18 <Nimko> ah ok thanks for the info
07:05:36 <cockliuser[m]> <ceetee[m]> "many ATM's require verification..." <- ATMs are physically in contact with you, no one knows what they can do
07:06:24 <cockliuser[m]> Wear full body clothing, gloves, and shoes that increase your height, also wear a mask, sunglass and a hat
07:06:48 <cockliuser[m]> Even after taking all those measures you still could be deanonymized if the agencies are after you
07:10:55 <feltukigna[m]> cockliuser[m]: are they really going _that_ far to identify ppl buying crypto at BATMS 
08:25:22 <cockliuser[m]> Probably not but it depends on your threat model
08:39:51 <^Tcache> Hello,
08:39:51 <^Tcache> Can someone sugest me best place to exchange also buy & sell XMR Anonymously. (Without giving them passport details and stuff) ?
08:39:51 <^Tcache> I want to buy XMR but i dont know the best place to go.
08:39:51 <^Tcache> Since im new. :(
09:08:09 <cockliuser[m]> With fiat? Try https://localmonero.co
09:09:45 <someoneelse49549> Yeah localmonero.co is just the only way to go if you want complete anonymity. Unfortunately, some countries just don't accept payments method like cash by mail etc...
09:10:51 <^Tcache> Thank you for information. I will try :))
09:27:11 <someoneelse49549> Can anyone send a post on Reddit about my CCS Proposal to discuss ? I don't like to be the one asking to be seen but my reddit account has 2 karma so i'm shadowban...
10:06:53 <ofrnxmr[m]> someoneelse495495:  which ccs
12:06:49 <opsoyo[m]> Are there many successes sending cash by mail internationally? 
12:17:26 <captaincrunchpre> <opsoyo[m]> "Are there many successes sending..." <- would highly doubt it
12:18:43 <captaincrunchpre> people send cash in the mail internationally to purchase services like mullvad and a significant number of them report not receiving time on their account meaning the mail was likely stolen 
12:18:47 <captaincrunchpre> or lost
12:18:52 <captaincrunchpre> probably stolen though 
12:19:58 <captaincrunchpre> <cockliuser[m]> "Probably not but it depends on..." <- well you are a cockliuser afterall, i imagine your threat model is higher than that guys 
12:42:01 <Stnby[m]> Who is responsible for taking getmonero.org down?
12:42:48 <Siren[m]> Maybe they're finally migrating out of Chinese shared hosting
12:43:06 <Stnby[m]> Cloudflarefuck + ChinkCDN
12:44:43 <plowsof11> someoneelse495495 if you make a thread and link it here, a kind reddit moderator can approve it or in #monero-community:monero.social 
12:45:04 <Siren[m]> Stnby[m]: Also why did it start using cloudflare?
12:45:25 <xfedex[m]> Siren[m]: Isn't Cloudflare based in USA?
12:45:33 <Siren[m]> Of course
12:45:39 <plowsof11> has it always been cloudflare?
12:45:54 <Stnby[m]> We have too smart of core
12:46:00 <xfedex[m]> Siren[m]: DDoS i guess.
12:46:00 <xfedex[m]> Monero has many adversaries.
12:46:00 <xfedex[m]> Or perhaps it just started with CloudFlare
12:46:14 <xfedex[m]> Fluffypony knows for sure
12:46:16 <xfedex[m]> ask him
12:46:22 <selsta> getmonero always used cloudflare
12:46:27 <plowsof11> core are busy with it / no ddos 
12:47:09 <fluffypony> lol
12:47:11 <fluffypony> guys
12:47:30 <fluffypony> we're just upgrading the server and we were struggling with the IPMI being unresponsive
12:47:44 <fluffypony> the CDN is still up, and we'll have it fixed in the next 12 hours
12:47:46 <fluffypony> nothing to see here
12:48:05 <sech1> BUT WE CANT DOWNLOAD MONERO
12:48:10 <Siren[m]> Very long downtime :D
12:48:10 <sech1> lol
12:48:16 <fluffypony> lol sech1 
12:48:20 <xfedex[m]> getmonero.org needs an i2p frontend by the way
12:48:26 <Stnby[m]> Do you need help with migrating a static site without downtime?
12:49:12 <fluffypony> Stnby[m]: feel free to contribute to this: https://github.com/monero-project/meta/blob/master/SERVER_SETUP_HARDENING.md
12:49:41 <fluffypony> we're also not migrating anything
12:49:53 <fluffypony> it was an OS upgrade that seems to have borked something
12:53:55 <Stnby[m]> That was going to happen eventually, it clearly needs redundant setup, reading the MD right now.
12:54:37 <fluffypony> Stnby[m]: why does it need a redundant setup? we have the CDN, binaries are on GitHub, a few hours of downtime isn't going to kill anyone
12:54:44 <fluffypony> feel free to fund a redundant setup
12:55:03 <selsta> fluffypony: problem is luigi always forgets to upload binaries to github
12:55:17 <selsta> maybe someone with github access can add them
12:55:22 <fluffypony> selsta: right but that's a fixable problem
12:55:41 <Siren[m]> Use CI/CD for that
12:55:45 <fluffypony> we've had minimal downtime in the last 9 years, I don't think we need to stress about this
12:56:00 <sech1> Binaries are not on github, they link to https://downloads.getmonero.org/ which is down
12:56:13 <fluffypony> Siren[m]: can't, binaries need to be manually checked - that's the point of reproducible builds
12:56:18 <fluffypony> otherwise it's an untrusted path
12:56:21 <plowsof11> we need to get a movie to the oscars, hopefully this is fixed soon sir 
12:56:27 <fluffypony> rofl plowsof11 
12:56:34 <Stnby[m]> This does not require a mainframe, pretty sure we can fund it
12:56:36 <sech1> oscars is overhyped
12:56:56 <selsta> https://github.com/monero-project/meta/issues/789#issuecomment-1410210834
12:57:12 <selsta> if someone asks for the binaries i have them linked here
12:57:16 <fluffypony> Stnby[m]: super low physical tin requirements, but what it does require is a well-peered, low-latency 10gbps unmetered link at a DC, and that's the issue
12:57:42 <Siren[m]> <fluffypony> "Stnby: feel free to contribute..." <- Ditch Wazuh for Falco and you'll be able to monitor both the host and the docker containers
12:57:49 <Siren[m]> It's also lighter weight
12:57:57 <sech1> 10gbps? Do people download Monero that much?
12:58:04 <fluffypony> selsta: yeah
12:58:07 <fluffypony> sech1 I mean
12:58:16 <Stnby[m]> You mentioned its behind a CDN, so what the server requires is certainly not a 10gbps unmetered link
12:58:23 <fluffypony> even with the CDN we get a ton of cache misses
12:58:49 <fluffypony> Stnby[m]: the CDN is mostly for punching through the GFW
12:58:55 <Stnby[m]> Yes I know because we do not have a proper caching setup
12:59:08 <Stnby[m]> Headers for cache do not exist basically
12:59:30 <fluffypony> so submit a PR to the document
12:59:38 <Siren[m]> fluffypony: Manually checked for what?
12:59:46 <Stnby[m]> I do not like current Docker setup
13:00:14 <fluffypony> Siren[m]: to make sure that everyone agrees what the hashes of the binaries should be
13:00:24 <fluffypony> so that nobody can backdoor the binaries
13:00:55 <fluffypony> Siren[m]: https://en.wikipedia.org/wiki/Reproducible_builds
13:02:10 <Siren[m]> I know what reproducible builds are
13:02:34 <fluffypony> so then you can see how going from an untrusted CI/CD pipeline into GitHub is a problem
13:02:41 <Siren[m]> Still doesn't make sense to me why you would do this by hand
13:02:55 <Siren[m]> fluffypony: Doesn't need to be a GitHub pipeline hell no
13:03:11 <Siren[m]> You have a gitlab instance ffs
13:03:20 <fluffypony> right but it's still an untrusted build
13:03:30 <fluffypony> someone could hack the CI/CD pipeline and backdoor the binaries
13:03:31 <Siren[m]> How?
13:03:45 <fluffypony> the point of repro builds is for everyone to agree on the hashes BEFORE the builds are made publicly available
13:03:48 <fluffypony> not after
13:04:08 <fluffypony> s/everyone/a significant number of people who have a repro build environment
13:04:16 <Siren[m]> fluffypony: Not everything coming from ci has to be pushed straight to the download page
13:05:07 <fluffypony> right but they'd still be available, even if the poisoned binaries are online for a couple of hours in a single location it's problematic
13:05:22 <selsta> binaryFate already adds the release notes to GitHub, also attaching binaries shouldn't be an issue in the future
13:05:23 <Siren[m]> fluffypony: And how do you all have a reproducible build environment? do you use nix?
13:05:31 <fluffypony> https://www.reddit.com/r/Monero/comments/dyfozs/security_warning_cli_binaries_available_on/
13:05:34 <fluffypony> it's happened before, btw
13:05:55 <selsta> Siren[m]: gitian
13:05:55 <fluffypony> they were compromised for 35 minutes
13:05:57 <sech1> Siren[m] https://github.com/monero-project/monero/tree/master/contrib/gitian
13:06:10 <Siren[m]> fluffypony: No they wouldn't be if it's multiple steps or pushes only on tag action etc 
13:06:23 <Stnby[m]> sech1: What were the investigation results?
13:06:29 <Siren[m]> fluffypony: Yeah and how did that happen?
13:06:55 <Stnby[m]> * investigation results? (oopsie wrong reply)
13:07:19 <fluffypony> Siren[m]: hard to tell; had the drives pulled and audited and the working theory was physical compromise at the DC we used back then
13:07:31 <fluffypony> new DC is much better
13:07:42 <fluffypony> actually cares about our opsec
13:08:22 <Stnby[m]> You can get compromised at personal computer, Github, DC, CDN, Cloudflare all of these points 😉
13:08:27 <Siren[m]> fluffypony: Avoiding CI/CD won't protect you from that. Did you have Wazuh ruleset to watch over the binaries?
13:08:42 <fluffypony> Siren[m]: this predates the hardened setup
13:08:53 <fluffypony> the hardened setup was as a reaction to the incident
13:09:07 <Stnby[m]> Docker needs to go out of this "hardened" setup
13:09:09 <fluffypony> anyway, I deeply appreciate that everyone here is an expert
13:09:14 <fluffypony> feel free to open a PR to the doc
13:09:35 <Siren[m]> Cloudflare will censor and potentially hurt users if US gov decides to sanction or does something stupid like that.
13:09:50 <Stnby[m]> Can we come up with a setup for the website and website only that in our eyes is redundant, hardened and idk cheaper to run?
13:10:39 <Stnby[m]> No Debian, no Docker "hardening" bs
13:10:53 <fluffypony> Stnby[m]: you can do whatever you'd like, it's a free world
13:11:34 <fluffypony> Siren[m]: we have fallbacks for a lot of the points of failure
13:11:55 <Stnby[m]> Would any of you be interested in having something done from scratch and if someone is willing to review it we will attempt it
13:12:14 <sech1> And "we" are who?
13:12:25 <Siren[m]> digilol.net
13:12:34 <fluffypony> submit the PR and let that be the point of discussion and collaboration
13:16:10 <Stnby[m]> Okay, thanks for the info, will attempt to throw something together.
13:27:54 <someoneelse49549> <ofrnxmr[m]> "someoneelse495495:  which ccs" <- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/373
14:06:27 <captaincrunchpre> <Stnby[m]> "Okay, thanks for the info..." <- whats your pfp
14:06:29 <captaincrunchpre> i dont get it
14:07:24 <ofrnxmr[m]> Its a picture of me and my uncle
14:07:51 <Stnby[m]> captaincrunchpre: https://en.wikipedia.org/wiki/Ottoman_military_band
14:08:48 <someoneelse49549> your uncle is really classy
14:13:00 <captaincrunchpre> <Stnby[m]> "https://en.wikipedia.org/wiki/..." <- are u a turk
14:13:26 <Stnby[m]> captaincrunchpre: No
14:13:54 <someoneelse49549> sounds like a turk flag behind
14:14:18 <captaincrunchpre> Stnby[m]: then why do u have a pfp with a turk flag
14:14:44 <Stnby[m]> Same reason why you don't have any pfp
14:14:54 <someoneelse49549> lol
14:15:40 <Stnby[m]> someoneelse49549: I'm with an Ottoman empire flag, which does not exist anymore
14:16:19 <someoneelse49549> wtf are you telling me you doesn't exist anymore?
14:16:20 <someoneelse49549> * exist anymore? /s
14:16:45 <Stnby[m]> Yeah I am quantum particle
14:16:56 <someoneelse49549> lmao
14:25:03 <cockliuser[m]> <someoneelse49549> "https://repo.getmonero.org/..." <- I'm going to copy paste the ccs and replace rust with c and no one can stop me
14:25:08 <cockliuser[m]> trollface.png
14:25:45 <anticarnist> I'm trying to send some dust (just barely more than the fee) from the cli wallet and I get to 'Is this okay?  (Y/Yes/N/No):' but when I type Y and hit enter, the enter key doesn't work, all I get is a ^M
14:26:17 <anticarnist> is it because of the small amount?
14:26:59 <anticarnist> Sweeping 0.000042260000 for a total fee of 0.000030640000.  Is this okay?  (Y/Yes/N/No): Y^M
14:31:48 <selsta> anticarnist: what OS are you using? how did you install monero-wallet-cli?
14:35:05 <anticarnist> selsta: pop_os. downloaded from getmonero.org. It worked yesterday, but that was with bigger amounts.
14:35:20 <selsta> ^M is carriage return, I don't see how this is related to the amount
14:35:42 <selsta> did you do anything different compared to yesterday?
14:36:09 <anticarnist> yes, doung sweep instead of tranfer
14:36:15 <anticarnist> doing*
14:36:19 <selsta> how many times did you try?
14:36:29 <anticarnist> two
14:38:05 <anticarnist> ctrl+m doesn't work either, pretty strange
14:38:29 <selsta> what happens if you just enter a lowercase y and then enter?
14:38:55 <anticarnist> same thing, enter just inputs a ^M
14:39:09 <selsta> but enter works when entering transfer or sweep ?
14:39:14 <selsta> the command itself i mean
14:39:40 <selsta> what's the output of echo $TERM
14:39:43 <someoneelse49549> <cockliuser[m]> "I'm going to copy paste the..." <- oh no a wide c maximalist appears /s
14:41:47 <anticarnist> selsta: yes, works fine up until that prompt. echo output: st-256color
14:42:41 <selsta> can you change it to one of these? https://github.com/monero-project/monero/blob/50aa0e8b7f11680be3954c176f2daa9ccf77b7dd/contrib/depends/patches/ncurses/fallback.c#L11
14:42:56 <selsta> we don't have fallback for st-256color
14:44:26 <Siren[m]> try running stty sane or stty icrnl
14:45:07 <anticarnist> okay, I tried to close the terminal and do it all again, but with lower y and enter instead of capital Y and that worked, lol
14:46:41 <selsta> wo don't have any fallback values for st-256color, try `TERM= xterm-256color ./monero-wallet-cli` or maybe what Siren[m] said
14:46:51 <selsta> capital Y should also work if everything is setup correctly
14:47:10 <selsta> (without space)
14:47:57 <anticarnist> maybe it was the fact that I closed and reopened the terminal?
14:48:20 <selsta> what does it say when you do `echo $TERM` now?
14:49:21 <anticarnist> same
14:52:28 <Stnby[m]> Seems like your terminal got stuck in a cooked mode https://en.m.wikipedia.org/wiki/Terminal_mode
14:52:41 <Siren[m]> anticarnist: Could be that previously you accidentally disabled icrnl
14:52:59 <Stnby[m]> I think it could either be issues with terminal emulator or monero or previous commands job
14:53:09 <Stnby[m]> * or monero cli or previous
14:54:06 <Siren[m]> There were cases when monero cli didn't restore terminal settings after exiting
14:54:24 <Stnby[m]> I have a feeling its monero cli related in here as well
14:54:35 <Stnby[m]> Y/n selector should be in cooked mode
14:57:20 <anticarnist> I tried again now, and now it worked with capital Y, so not sure what it was but closing and reopening the terminal solved it.
14:58:03 <ofrnxmr[m]> <selsta> "what does it say when you do `..." <- Same output?
14:59:50 <Stnby[m]> What terminal emulator were you using?
15:05:24 <anticarnist> st
15:08:59 <Stnby[m]> Probably its fault sus terminal
15:09:30 <Stnby[m]> Their philosophy is lines of code, not error handling
15:17:37 <cockliuser[m]> <someoneelse49549> "oh no a wide c maximalist..." <- Rust evangelist vs C maximalist battle
15:18:10 <someoneelse49549> epic fight
15:18:10 <cockliuser[m]> I'd bet 20WOW that the C maxi wins :3
15:36:59 <xfedex[m]> *Golang lover has joined the chat
15:40:05 <smathy[m]> QQ about the full blockchain sync, why does it go so much faster at the start than at the end?
15:41:20 <nioc> checkpoints 
15:42:28 <nioc> they are added for each release
15:43:00 <smathy[m]> ...and those have a cumulative impact on the validation?
15:43:41 <nioc> yes
15:43:45 <xfedex[m]> smathy[m]: Both checkpoints and block size
15:43:57 <smathy[m]> Thanks nioc 
15:44:11 <xfedex[m]> (newer monero blocks have more transactions than old blocks)
15:44:26 <smathy[m]> xfedex: ah cool, that was one of my guesses.
15:44:32 <nioc> yes but mostly checkpoints
15:45:06 <selsta> checkpoints are the main slowdown and the last release was months ago so a lot of blocks have to be synced without checkpoints
15:45:10 <xfedex[m]> nioc: depends on your device
15:45:30 <nioc> the blocks before ringCT are faster
15:45:38 <smathy[m]> Will the cumulative effect of the checkpoints eventually mean it becomes too slow?
15:45:44 <xfedex[m]> if you have a hard disk, then disk speed will usually be the bottleneck
15:46:02 <xfedex[m]> smathy[m]: No, not at all
15:46:22 <nioc> xfedex[m]: true, I only use SSDs  :)
15:46:41 <xfedex[m]> What checkpoints do is saying "hey, blockchain is valid till block x, and its hash is y" 
15:47:00 <xfedex[m]> so your computer needs to crunch less numbers when syncing
15:47:06 <smathy[m]> Hmm, that seems like it ...right.
15:47:21 <smathy[m]> So why does that make it slower the further through the blockchain you get?
15:47:58 <smathy[m]> (happy to ask this in dev if that's better, seems like we quickly got away from the end user space here :)
15:48:15 <nioc> no here is good
15:48:18 <xfedex[m]> smathy[m]: Because checkpoints are added every once and while (usually during hardforks); they are hardcoded into source code.
15:48:18 <xfedex[m]> Once you pass the last checkpoint, monerod must check manually that the blocks it receives are valid.
15:51:27 <nioc> smathy[m]: are you using a HDD or SSD?
15:52:19 <smathy[m]> SSD
15:52:40 <nioc> great :)
15:52:42 <smathy[m]> It's a MBP M1 Max.
15:53:15 <nioc> HDDs can be painful for initial syncing 
15:53:30 <smathy[m]> But if the checkpoints allow it to refer back to just the last checkpoint, rather than having to validate all the way back (right?) why does that explain why it takes like 3 minutes per 10% at the start of the blockchain vs hours for 90-100% at the end?
15:54:53 <nioc> the beginning had different transaction type and fewer transactions
15:54:58 <smathy[m]> nioc: right, so I hear.  Which was my other guess before asking, that this was a slowdown for something internal to lmdb once it gets a large value.
15:55:26 <smathy[m]> Right, ok.  That was another guess, that the complexity/size/number/something of transactions and/or verification process has dramatically increased.
15:55:32 <selsta> monerod ships with a list of known block hashes (checkpoints)
15:55:52 <selsta> if a block is known it has to so less verifiable work
15:55:59 <selsta> verification*
15:56:13 <smathy[m]> Right, so don't checkpoints improve the efficiency of the verification?
15:56:17 <selsta> less work per block = faster sync
15:56:25 <smathy[m]> Answered :)
15:56:45 <Rucknium[m]> selsta: Will nodes reject a blockchain re-org that is deeper than the checkpoints?
15:56:48 <selsta> all blocks that were mined after the last release are unknown
15:57:10 <xfedex[m]> Rucknium[m]: Blockchain reorgs cannot be more than 10 blocks long
15:57:12 <xfedex[m]> So yes, it will
15:57:28 <Rucknium[m]> I dont think that's true
15:57:34 <selsta> Rucknium[m]: there are two different systems with the name checkpoint
15:57:46 <smathy[m]> So, unless as time has gone on, checkpoints have been more sparse (which [the code doesn't imply](https://github.com/monero-project/monero/blob/master/src/checkpoints/checkpoints.cpp#L176)) then I don't see how that explains the sync slowing down.
15:58:15 <Rucknium[m]> Liek everything in Monero with the name ambiguity :P 
15:58:19 <selsta> one does what you describe, you can't rollback further, and the other speeds up sync with known block hashes
15:59:48 <selsta> xfedex[m]: I also don't think that's true, there's no 10 block limit
15:59:54 <smathy[m]> selsta: Ah ok, I understand that, but that'd only be at the very end.  Like even 40-50% is much slower than 10-20%.
16:00:05 <Rucknium[m]> smathy: Checkpoints have been utterly sparse since the last monerod version release :)
16:00:06 <xfedex[m]> Blocks newer than 10 blocks are referred as "tips", blocks older than 10 blocks are permanent
16:00:23 <xfedex[m]> selsta: Are you sure?
16:00:25 <selsta> smathy[m]: that's due to different usage and different cryptography
16:00:25 <smathy[m]> Rucknium[m]: Infinitely sparse :)
16:00:44 <selsta> 2014-2015 barely had usage and simpler cryptography
16:01:28 <Rucknium[m]> Bitcoin Cash has a 10 block re-org depth limit right now. The perils of being a minority hashpower chain.
16:02:04 <selsta> xfedex[m]: yes
16:03:12 <selsta> wallets have a configurable reorg limit but not the daemon
16:03:25 <selsta> (as far as I know)
16:03:28 <Rucknium[m]> I 51% attacked the Townforge testnet and re-orged about 24 hours of blocks. Townforge and Monero have about the same blockchain code.
16:05:31 <smathy[m]> So yeah, around the 44% mark it really slows down.  This was just after a log ouput "Validating txpool for v4" which I'm guessing was a fork that involved a big change in verification/security/something.
16:06:02 <selsta> v4 introduces RingCT
16:06:19 <selsta> which uses inefficient cryptography
16:06:52 <xfedex[m]> selsta: read this https://github.com/monero-project/research-lab/issues/95
16:06:53 <xfedex[m]> > Outputs in the PoW 'reorg zone' (the most recent ~1-10 blocks) can be completely removed from the chain by a reorg, because any output that can be reorged can be double-spent.
16:06:55 <xfedex[m]> from this I deduce that reorgs cannot be longer than 10 blocks
16:07:38 <selsta> once you get to v8 sync will speed up again due to advancements in cryptography
16:08:21 <smathy[m]> Ok cool.
16:09:19 <ofrnxmr[m]> xfedex @xfedex:matrix.org:  selsta has read that lol
16:09:53 <Rucknium[m]> xfedex: I think the wording there is just unclear. It's the "re-org zone" since it's the chosen safety factor of the 10 block lock on spending tx outputs.
16:10:29 <Rucknium[m]> I would recommend asking UkoeHB in #monero-research-lab:monero.social  to confirm the meaning of that statement and to revise if necessary.
16:15:39 <smathy[m]> Seeing as I have an SSD, during this v4-v8 stuff, this is all CPU-bound?
16:16:01 <smathy[m]> (fwiw, my htop suggests it's not really)
16:18:17 <nioc> sync is not bound by anything in my system 
16:21:18 <selsta> random IO speed is important for sync
16:21:42 <selsta> xfedex[m]: you'd have to ask UkoeHB to clarify, but I'm certain there's no 10 block re-org limit
16:32:19 <smathy[m]> Ok, nothing I can do about that, thanks
16:35:11 <ofrnxmr[m]> Checkpoints dont discard ALL data. Increased monero usage = more data to verify. Checkpoints decrease the workload, not eliminate it.
16:35:11 <ofrnxmr[m]> Syncing to ssd should take 8-24 hours on most systems 
16:38:51 <smathy[m]> And yeah, it just wasn't making sense that checkpoints we're the cause of the slow down, but I wasn't understanding what y'all were talking about (the final stages, after the last checkpoint) nor was I making my actual question clear (ie that it slows down way before then in the 40% range (turned out to be v4))
16:39:20 <smathy[m]> Really appreciate all the help, very new to this and you've all been very helpful
16:48:21 <ofrnxmr[m]> Its like..... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/8b59a202eac1c917e51838274770274fe638f6fb>)
18:18:36 <smathy[m]> Right, it's a checksum of all the blocks since the last checkpoint.