08:43:32 we should ban stat farming 09:02:05 with that I mean, an agent shouldn't add commits to pull requests that appear to be authored by a different github account 09:08:15 i see theyre back https://github.com/auyua9 ... https://github.com/huyua9 , are they mixing and matching commits too? 09:11:43 larger list https://privatebin.net/?bfcefd3096955cdd#BQv3Mz6VRxvWKnpYmjghopXQTNCtBYkcD8uZojguDf8u 10:58:26 Just curious why this full time dev ccs doesn't get funding? Isn't the general fund supposed to fund full time dev if there isn't enough crowd sourced funding? https://ccs.getmonero.org/proposals/jpk68-full-time-1.html 11:00:29 because you didnt donate 11:00:56 and this is a room for development, not funding. Read the channel description 11:02:09 And no, its called the community crowdfunding not generalfund development funding 11:04:21 Its not a free ride, raising the money is supposed to be up to the proposer to do 12:33:29 Seems current db salvage implementation is very flawed 12:33:46 It only reverts the transaction to the previous one 12:34:52 But most database corruption occurs because of power loss or program abnormal termination when the database is running on fast:async 12:35:40 There would be many small commit without flushing to disk 12:35:50 And if the program crash/died, the salvage won't be able to save the data base at all 12:36:14 Db runs in safe mode by default when at the tip 12:39:00 Yeah, but if the program crashes or computer shutdown during the initial sync, it is very likely the databse just got corrupted. I have experienced this like twice, mostly due to monerod's massive I/O just hang my virtual machine 12:40:15 Maybe it is a better idea to accumulate blocks in one LMDB write transaction, and perform perform one fully synchronous commit, in this case if the program crashes, the salvage db can correctly revert the database 12:58:49 So the sync mode? 16:50:20 wait till huyua9 finds out he/it can change commit dates too 16:51:45 Whatever they're using to generate 'random' usernames is worse than Coldcard 💀 16:52:36 genuinly what would happen if a commit dated 2010 gets merged? 16:54:48 What aby huyua6? Or iuyua9? 16:55:22 @thomasbuilds:matrix.org: probably doesn't get merged idk, needs force push? 16:55:36 @ofrnxmr:xmr.mx: no neither did so far, i'm inspiring them 16:55:44 giving them ideas 17:00:43 I mean, they already use like 20 other accts to open the prs 17:01:40 to ban-proof I guess? 17:02:10 "genuinly what would happen if a commit dated 2010 gets merged" < git doesn't care, it's just a field on the entry 17:02:23 this happens regularly that out of order stuff is merged or rebased 17:03:00 if you go on commit history it would show up as the first monero commit? 17:04:00 no. git doesn't work on date, it's chained commits that reference previous one by hash 17:04:54 on github too? 17:05:08 yes. github works on git 17:05:17 it wouldnt show up before https://github.com/monero-project/monero/commit/84ca73ea77d50815dd6ce087c8b65980d6c2d2c3 17:05:22 first commit is effectively akin the genesis block 17:05:26 no 17:06:04 this is not #monero-dev relevant and you likely have not encountered git internals before as they are a textbook case of "hash chain" 17:07:18 yeah force pushing actually needs to be done to alter the commit order 17:07:32 that changes the ids too. 17:07:44 yeah invalidates chain 18:00:18 .merge+ 11198 11197 11194 11187 11186 11179 11178 11175 11174 18:00:18 Added 18:03:36 .merges 18:03:36 10886 10887 10964 11054 11121 11122 11123 11170 11174 11175 11178 11179 11186 11187 11194 11197 11198 18:58:10 .merges 18:58:10 10886 10887 10964 11054 11122 11123 11178 11194 20:51:46 ASAN builds do not enable ASAN for Rust code. Should this be changed? 20:51:49 It requires Nightly, FWIW 21:15:20 Right now `multisig_import_needed` only emits if you try to initiate a tx without knowing key images. It doesn't emit if you try to sign a tx (only `multisig_export_needed` if you try to sign but didn't contribute nonces). Should multisig co-signers be required to import before signing? The concern is if you sign a tx and submit it, everyone who didn't import won't be able to see the spend. So requiring imports could be a 21:15:20 workflow defense to avoid integration mistakes where importing isn't enforced by the caller. Now that I think about it though, there are no communication-round optimizations to skipping import since you can always transmit importable data along with partial txs (although more work for someone doing it manually - god save you). 21:16:00 I think I convinced myself to enforce it, but anyone have thoughts? rbrunner7 ? 21:22:41 @jpk68:matrix.org: I'm stupid, nevermind. ASAN is already enabled