03:55:54 <ArtemVorotnikov[> I wonder if block id override for 202612 can be reduced to just correct block id comparison and override after all these years?
05:48:31 <moneromoooo> Probably not. It'd just take an asshole to start serving this block and wedge any new user syncing off them.
06:08:05 <ArtemVorotnikov[> <moneromoooo> "Probably not. It'd just take..." <- You mean every single node that serves this block during sync?
06:11:24 <ArtemVorotnikov[> > <@moneromoooo:libera.chat> Probably not. It'd just take an asshole to start serving this block and wedge any new user syncing off them.
06:11:24 <ArtemVorotnikov[>  * All nodes serve it during sync just like any other block. It just has a historic anomaly in block id calculation.
06:18:08 <moneromoooo> Were there not two blocks ? I barely remember what happened now.
06:18:30 <moneromoooo> Oh, two txes. nvm.
06:18:49 <ArtemVorotnikov[>  * All nodes serve it during sync just like any other block. It just has a historic anomaly in block id calculation which could be implemented with a simple override:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ee11c2d3f6e2d6daf2b7d6b19794e5fc2222bb0f>)
06:19:31 <moneromoooo> That looks a lot like what the current code does.
06:20:23 <moneromoooo> Anyway, I see no need to change what works, but if you're reimplementing something, feel free to do it differently as long as correct.
06:21:44 <ArtemVorotnikov[> yes, except current code serializes blob and keccaks it, I guess my proposal is just to hardcode it
06:22:09 <ArtemVorotnikov[>  * yes, except current code specifically for 202612 serializes blob and keccaks it, I guess my proposal is to just hardcode the override block id
06:22:50 <sech1> to use override id, first you need to serialize and keccak the block you're overriding
06:25:20 <ArtemVorotnikov[> sech1: why not just check against the 'supposed' block id?
06:26:21 <sech1> Why would it matter
06:26:33 <sech1> you're just changing the order of comparison
06:27:32 <ArtemVorotnikov[> it's just making the code simpler fwiw
06:27:35 <moneromoooo> I just looked at the code, I think the difference is you'd trigger on the exact block, instead of any possible block for that height ?
06:28:08 <ArtemVorotnikov[> moneromoooo: 'correct' block id (if not for the override) is the commitment for that, no?
06:28:32 <moneromoooo> I do not understand "commitment" in that context.
06:28:45 <ArtemVorotnikov[> cryptographic commitment
06:30:32 <moneromoooo> Well, I guess in the absence of a bug, the block hash commits to the content of the block, yes.
08:07:26 <volkovyuri[m]> Hello! Gimme please email of the Core Team for some important questions... at site Getmonero.org I can't see full email and I see only "Email: dev[at]getmonero[dot]org"
08:07:26 <volkovyuri[m]> Maybe email is dev⊙go ? 
08:07:26 <volkovyuri[m]> Help me please)
08:23:43 <moneromoooo> Hmm. Quite a puzzle... Let me think...
08:25:11 <moneromoooo> I think you may have the correct solution. It's not for support btw.
10:57:06 * binaryFate eagerly waiting for important questions
11:02:53 <moneromoooo> What is... your fate ?
11:03:53 <moneromoooo> Helps to picture that scene from the Holy Grail on the bridge.
11:22:03 <binaryFate> ... blue!