we should ban stat farming

with that I mean, an agent shouldn't add commits to pull requests that appear to be authored by a different github account

<plowsof:matrix.org> i see theyre back github.com/auyua9 ... github.com/huyua9 , are they mixing and matching commits too?

<plowsof:matrix.org> larger list privatebin.net/?bfcefd3096955cdd#BQ…xvWKnpYmjghopXQTNCtBYkcD8uZojguDf8u

<entropyhoover:matrix.org> 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? ccs.getmonero.org/proposals/jpk68-full-time-1.html

<ofrnxmr:xmr.mx> because you didnt donate

<ofrnxmr:xmr.mx> and this is a room for development, not funding. Read the channel description

<ofrnxmr:xmr.mx> And no, its called the community crowdfunding not generalfund development funding

<ofrnxmr:xmr.mx> Its not a free ride, raising the money is supposed to be up to the proposer to do

<entropyhoover:matrix.org> Seems current db salvage implementation is very flawed

<entropyhoover:matrix.org> It only reverts the transaction to the previous one

<entropyhoover:matrix.org> But most database corruption occurs because of power loss or program abnormal termination when the database is running on fast:async

<entropyhoover:matrix.org> There would be many small commit without flushing to disk

<entropyhoover:matrix.org> And if the program crash/died, the salvage won't be able to save the data base at all

<ofrnxmr:xmr.mx> Db runs in safe mode by default when at the tip

<entropyhoover:matrix.org> 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

<entropyhoover:matrix.org> 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

<ofrnxmr:xmr.mx> So the sync mode?

<thomasbuilds:matrix.org> wait till huyua9 finds out he/it can change commit dates too

<jpk68:matrix.org> Whatever they're using to generate 'random' usernames is worse than Coldcard 💀

<thomasbuilds:matrix.org> genuinly what would happen if a commit dated 2010 gets merged?

<ofrnxmr:xmr.mx> What aby huyua6? Or iuyua9?

<thomasbuilds:matrix.org> @thomasbuilds:matrix.org: probably doesn't get merged idk, needs force push?

<thomasbuilds:matrix.org> @ofrnxmr:xmr.mx: no neither did so far, i'm inspiring them

<thomasbuilds:matrix.org> giving them ideas

<ofrnxmr:xmr.mx> I mean, they already use like 20 other accts to open the prs

<thomasbuilds:matrix.org> to ban-proof I guess?

"genuinly what would happen if a commit dated 2010 gets merged" < git doesn't care, it's just a field on the entry

this happens regularly that out of order stuff is merged or rebased

<thomasbuilds:matrix.org> if you go on commit history it would show up as the first monero commit?

no. git doesn't work on date, it's chained commits that reference previous one by hash

<thomasbuilds:matrix.org> on github too?

yes. github works on git

<thomasbuilds:matrix.org> it wouldnt show up before monero-project/monero 84ca73e

first commit is effectively akin the genesis block

no

this is not #monero-dev relevant and you likely have not encountered git internals before as they are a textbook case of "hash chain"

<thomasbuilds:matrix.org> yeah force pushing actually needs to be done to alter the commit order

that changes the ids too.

<thomasbuilds:matrix.org> yeah invalidates chain

.merge+ 11198 11197 11194 11187 11186 11179 11178 11175 11174

Added

.merges

10886 10887 10964 11054 11121 11122 11123 11170 11174 11175 11178 11179 11186 11187 11194 11197 11198

.merges

10886 10887 10964 11054 11122 11123 11178 11194

<jpk68:matrix.org> ASAN builds do not enable ASAN for Rust code. Should this be changed?

<jpk68:matrix.org> It requires Nightly, FWIW

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

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).

I think I convinced myself to enforce it, but anyone have thoughts? rbrunner7 ?

<jpk68:matrix.org> @jpk68:matrix.org: I'm stupid, nevermind. ASAN is already enabled