00:24:28 <bbqcore[m]> is the monero codebase mirrored/self-hosted anywhere?
00:25:04 <bbqcore[m]> i see there was a move to gitlab back when MS bought github but i just the the CCS on there
00:25:11 <bbqcore[m]> s/the/see/
01:15:18 -xmr-pr- j-berman opened pull request #8178: Bump ring size to 16 for v15
01:15:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8178
01:27:55 <selsta> bbqcore[m]: we have backhub.co setup
03:56:56 <jrandom[m]> Hey guys, somebody knows where in the codebase can I find the function that encodes the seed to get the mnemonic?
03:56:56 <jrandom[m]> The equivalent of this
03:56:56 * jrandom[m] uploaded an image: (301KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/axFIMslEUybSqEwUhoTVEsOd/image.png >
03:58:34 <jrandom[m]> s/Hey/Hi/
06:42:07 <rbrunner> jrandom[m]: Check this for seed to key and vica versa: src/mnemonics/electrum-words.h
06:44:04 <rbrunner> Do you know already my page about seeds? Maybe it will be useful to cross-check and help debugging: https://monerotech.info/Home/Seed
11:45:18 -xmr-pr- moneromooo-monero opened pull request #8179: wallet2: decrease the amount of data exchanged for output export
11:45:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8179
14:46:55 <bbqcore[m]> <selsta> "bbqcore: we have backhub.co..." <- wouldnt a self-hosted solution be better in case shtf?
14:47:54 <bbqcore[m]> endogenic: i sent you DM
14:48:03 <selsta> self hosted solution for what?
14:50:16 <bbqcore[m]> the project code base
14:52:30 <selsta> https://github.com/monero-project/meta/issues/236
14:52:37 <selsta> it was decided against it
14:53:46 <bbqcore[m]> yeah i read that, but arent the concerns still valid?
15:15:18 <selsta> it's a bit of an endless discussion, we have a backup and we can move somewhere else in case the repos get taken down
15:29:36 <bbqcore[m]> i think a public self-hosted mirror would remove the trust aspect of uploading a backup in case github gets taken down without notice (hypothetical worse case)
15:31:01 <bbqcore[m]> users should be able to verify the codebase on their own in such a situation 
15:31:26 <selsta> git is decentralized, a lot of people have a copy of the repo
15:31:31 <selsta> commits are signed
15:32:57 <bbqcore[m]> yes but lets say it goes down and i dont have a copy before
15:33:09 <bbqcore[m]> how can i verify its the same code? 
15:34:45 <selsta> if you don't have a copy of the code and if you don't trust anyone else then you can't
15:35:22 <selsta> but that's kinda a pointless what if, the code could also change now and if everyone is in on it you wouldn't notice
15:35:51 <bbqcore[m]> right - a public self-hosted mirror would allow me to verify on my own
15:36:14 <bbqcore[m]> selsta: yeah i know, this is all hypothetical and assuming some onewith commit access has been compromised
15:37:10 <moneromooo> What makes you able to verify authenticity of the source depending on how you obtain it ?
15:38:20 <bbqcore[m]> moneromooo: if there was a public mirror that would survive a github takedown, id be able to download the latest code and verify it against whatever backup comes on line after
15:38:59 <moneromooo> Why is not the same as "if there was any other person having the source, id be able to download the latest code and verify it against whatever backup comes on line after" ?
15:39:51 <bbqcore[m]> what do you mean? id have to trust whatever code comes back online after such an attack
15:40:10 <bbqcore[m]> im sure loads of people will be able to call out any shady commits, but id have to trust them
15:40:26 <moneromooo> Are you implying you would not have to trust it if it where that self-hosted mirror ?
15:40:49 <selsta> you can't trust no one and then trust a random mirror :D
15:41:03 <bbqcore[m]> moneromooo: id at least know that whatever was re-upped is the same as what was taken down
15:41:19 <bbqcore[m]> apart from fully auditing the code myself theres already an obvious element of trust
15:41:23 <moneromooo> How would you do that, and at the same time not be able to do that if you got it elsewhere ?
15:42:01 <bbqcore[m]> because id be trusting some one elses copy of the code
15:42:25 <moneromooo> So you're basing this on "I trust what comes from this source", correct ?
15:43:15 <bbqcore[m]> no, im basing this on not being able to verify for myself if there was any fuckery between take-down and re-up
15:43:16 <moneromooo> (I mean it's a fair default, but you started off with not having to trust)
15:43:34 <selsta> how do you know that no one tempered with the mirror?
15:43:39 <bbqcore[m]> i guess something like uploading the code to a torrent would solve this
15:44:27 <bbqcore[m]> selsta: id be able to check, before every back up id download both sources and see if they match
15:45:00 <bbqcore[m]> of course this is assuming the monero project isnt already compromised before anything like this happens
15:45:06 <bbqcore[m]> thats not the approach im taking
15:45:08 <moneromooo> I think you need to work the steps out in detail.
15:45:12 <selsta> just because they matched in the past doesn't mean they don't diverge at some point
15:45:19 <moneromooo> And I mean *detail*.
15:45:41 <bbqcore[m]> selsta: of course, so the whole point is to see where that happens for myself
15:46:01 <selsta> the easiest is to make your own mirror
15:46:31 <moneromooo> (btw, I pushed a PR to decrease the output export data size, which you'd expressed interest in, still chunky though)
15:47:02 <bbqcore[m]> selsta: yeah thats true, just thought a public one would be good for the project
15:47:32 <moneromooo> It'd be good for availability.
15:47:40 <bbqcore[m]> moneromooo: link? thanks for taking that up. what kind of reduction we looking at?
15:47:51 <moneromooo> https://github.com/monero-project/monero/pull/8179
15:48:08 <bbqcore[m]> cheers. can the same be done for key images?
15:48:15 <selsta> https://git.wownero.com/monero-project/monero
15:48:19 <selsta> that's a public mirror
15:48:21 <moneromooo> Took about 2/3 off for the cold_signing functional test, but thse are pretty much only coinbase outs.
15:48:35 <moneromooo> I think it'll save a little more in most cases.
15:49:10 <moneromooo> Key images are mostly https://github.com/monero-project/monero/pull/8179incompressible really.
15:49:39 <moneromooo> And that data is way smaller already.
15:50:33 <moneromooo> Now I'm wondering whether this should be a wallet flag... export all data, or just what's needed for cold signing.
15:52:09 <bbqcore[m]> thanks moneromooo, ill pass this on to airgap and get this QR standard rolling
15:56:31 <plowsof[m]> Thanks moneromooo 
16:07:32 <bbqcore[m]> <moneromooo> "Now I'm wondering whether this..." <- you mean like seed, view keys, addresses etc?
16:11:23 <moneromooo> I meant whether the "send subset of data for size optimization" should be an option. To avoid the cold wallet having "dummy" data for outputs.
16:11:45 <moneromooo> ie, run incoming_transfers and the txids will show up as 0000 I expect.
16:18:50 <bbqcore[m]> oh ok i thought you meant if there was a way to reduce all data in the wallet for export
16:18:58 <bbqcore[m]> cause there was talk of restoring wallets via QR also
18:45:51 <moneromooo> hyc: if I want to lookup N arbitrary records in a table, is there a faster way to do it ? ie, sort them first ? MDB_MULTIPLE seems to be only for writing.
18:46:56 <moneromooo> Ideally I'd want to minimize the number of uncached disk reads.
18:47:46 <moneromooo> So I'm not sure sorting matters enough to bother with, root and level 1 are going to be likely cached, the rest probably uncached.
18:47:50 <moneromooo> (the table is large)
18:48:00 <moneromooo> Any other tip ?
18:48:50 <moneromooo> It's DUPFIXED|DUPSORT btw.
19:07:32 <moneromooo> Naively, it seems lmdb could implement MDB_MULTIPLE for lookups, locate the last non-leaf page for all requests, and use iovec for the last step, which will be full of cache misses. And hope the I/O scheduler can work with that intelligently.
19:15:55 <jberman[m]> MDB_GET_MULTIPLE / MDB_NEXT_MULTIPLE
19:16:10 <jberman[m]> I remember seeing this here: https://github.com/monero-project/monero/blob/9aab19f349433687c7aaf2c1cbc5751e5912c0aa/src/blockchain_db/lmdb/db_lmdb.cpp#L2565
19:16:30 <moneromooo> Thanks. That's not really what I want here.
19:17:14 <moneromooo> It could be used for a manual scan for small tables (or large amounts of lookups) but that's not my case.
19:20:57 <jberman[m]> Ah I see
20:37:51 <moneromooo> I guess we won't really prevent seeks, unless really RAM starved. They'll just happen in another order :/
20:38:44 <moneromooo> Except if we query neighbours but that's not very likely in this case.
23:42:53 <jeffro256[m]> Can someone please explain to me what the point of contrib/epee/include/copyable_atomic.h is? The class extends std::atomic<uint32_t> but doesn't appear to add any functionality. Thanks!
23:44:24 <jeffro256[m]> Especially since std::atomic<uint32_t> is used in other places throughout the project