05:45:29 <br-m> <spirobel:kernal.eu> > <@ofrnxmr> The latter (i dont remember where it is) causes the chain to roll back to a block before the checkpoint (instead of switching to the alt chain that has the checkpoint). After which the node blocks a) incoming blocks that dont match the checkpoint b) incoming blocks that do match the checkpoint, but are orphaned c) newly mined blocks, because they dont match the checkpoint
05:45:29 <br-m> <spirobel:kernal.eu> @bawdyanarchist:matrix.org: take a look at the conversation around this  topic of checkpoints. It should give you some context and lead you to the code path where the reorg is handled.
05:55:26 <br-m> <spirobel:kernal.eu> https://github.com/monero-project/monero/pull/10075 the line of code linked to in the discussed issue leads to a function named handle_alternative_block https://github.com/monero-project/monero/blob/d32b5bfe18e2f5b979fa8dc3a8966c76159ca722/src/cryptonote_core/blockchain.cpp#L4605 which is called inside add_new_block after the locks are acquired in 4589
05:57:31 <br-m> <spirobel:kernal.eu> that should answer your question that adding new blocks is serial  > <@bawdyanarchist:matrix.org> Hi all, I'm working on integrating verification delays into the sim. I just want to make sure I'm modeling how nodes actually process/verify new blocks and reorgs.
06:34:57 <br-m> <spyce.:zano.org> Yo, new to understanding the privacy and core tech in general. 
06:34:57 <br-m> <spyce.:zano.org> Does the idea that selfish mining becomes profitable once controlling over 1/3 of the hash rate stem from a pool's ability to decide to secretly branch off the chain (essentially creating their own private blockchain, for the time being) which would consequently cause the public network to reweight mining difficulty of procedi [... too long, see https://mrelay.p2pool.observer/e/oqro270Kd2RkVThO ]
06:34:57 <br-m> <spyce.:zano.org> Obviously there's some nuance to this due to statistics/probability but the main gist is that it theoretically becomes sustainable once over 1/3 right?
06:35:41 <br-m> <basses:matrix.org> @spyce.:zano.org: send in this room #monero-research-lounge:monero.social
06:37:19 <br-m> <spyce.:zano.org> K, thanks.
06:41:45 <br-m> <spyce.:zano.org> Just for reference, I take it this communication channel is more for discussion of development progress, and the lounge more so for conceptual research discussions, yes?
07:04:11 <br-m> <namenet:matrix.org> @spyce.:zano.org: This room is for weekly developer meetings about CCS actionables like FCMP++, DNS checkpointing, etc. where developers discuss what they're working on. Research Lounge is just casual conversation and free discussion about technical topics related to Monero
20:41:47 <br-m> <bawdyanarchist:matrix.org> Awesome, thank you @spirobel:kernal.eu . > <@spirobel:kernal.eu> that should answer your question that adding new blocks is serial 
23:54:25 <br-m> <ofrnxmr> Lounge is not for casual discussion > <@namenet:matrix.org> This room is for weekly developer meetings about CCS actionables like FCMP++, DNS checkpointing, etc. where developers discuss what they're working on. Research Lounge is just casual conversation and free discussion about technical topics related to Monero
23:54:48 <br-m> <ofrnxmr> Edit, not for casual conversation
23:56:57 <br-m> <ofrnxmr> Think of it in a literal sense. This room is the lab. This is where work/research is done. Lounge is a slightly less formal version of lab. Non research related discussion belongs in #monero-dev:monero.social  #monero:monero.social  #monero-community-dev:monero.social  #no-wallet-left-behind:monero.social  etc