02:24:13 <r4v3r23[m]1> is there a full list of actions that can only be done when --trusted-daemon is set?
02:36:25 <Lyza> 2nd answer: https://monero.stackexchange.com/questions/10925/which-part-of-the-daemon-rpc-is-restricted
02:36:41 <Lyza> <r4v3r23[m]1>
02:44:02 <r4v3r23[m]> Lyza: thanks
02:47:55 <r4v3r23[m]> whats the worst that could happen if a basic wallet app didnt use any of those functions but still set all nodes as trusted?
04:25:17 <ofrnxmr[m]> Restricted-rpc isnt relevant to trusted-daemon.. am i wrong
04:27:43 <ofrnxmr[m]> --trusted-daemon is a wallet side flag to trust a daemon. --restricted-rpc is a daemon side flag to not-trust a wallet(/connections)
04:28:48 <ofrnxmr[m]> Monero sets all but localhost to untrusted by default
04:29:46 <ofrnxmr[m]> pinging moneromooo:  :) 
06:36:34 <moneromooo> ofrnxmr[m] is correct.
06:37:49 <moneromooo> Worst that can happen if you trust all nodes... probably privacy leaks along the lines of "the daemon now knows which outputs are mine if I use rescan_spent".
06:38:29 <moneromooo> Worst than can happen if a node trusts all wallets... probably "wallet sets my computer to mine for it" or "trivial DoS".
06:38:56 <moneromooo> Then again, "easy DoS" is possible even then.
06:44:26 <ofrnxmr[m]> How about the --trusted-daemon flag for wallets? I think r4v3r23 would like to know about the drawbacks of always using that flag / the difference between trusted and untrusted
07:09:31 <moneromooo> Worst that can happen if you trust all nodes... probably privacy leaks along the lines of "the daemon now knows which outputs are mine if I use rescan_spent".
07:15:42 <r4v3r23[m]> right but if the wallet didnt use the  mining/rescan_spent functions?
07:17:20 <moneromooo> I do not have a full list for you. If you do not use any function that changes behaviour based on the trusted flag, then you do not get any drawback of course.
07:17:57 <moneromooo> But "refresh" is one such function, at least at startup.
07:18:29 <moneromooo> (it quantizes the current height to determine which blocks to sync on startup)
07:24:46 <r4v3r23[m]> and the benefits? ofrnxmr: mentioned it shaves ~20mb off everytime it connects to node
07:30:40 <moneromooo> Better privacy.
07:32:20 <moneromooo> In general: it trades optimizations for privacy.
07:34:47 <r4v3r23[m]> would be great to know what options to avoid using to benefit from optimizations while avoiding privacy leaks
12:58:20 <ghostway[m]> hello, what are your thoughts about specifications for a key container?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/87cb1f9f23e96bbe12540f34fbb7f33e72ebd01b>)
13:12:13 <moneromooo> You could explain what you mean by a key container. Since you mention mlock, I assume it's not an on-disk "vault" with keys in it, which is the first thing that came to mind from the name.
13:12:58 <ghostway[m]> Ah, makes sense. I mean the keys that are contained while in memory. Like in wallet2
13:18:00 <moneromooo> Do you mean (secret) keys in general ? As in, crypto::secret_key ?
13:18:18 <ghostway[m]> In particular jamtis keys
13:18:38 <moneromooo> They're not 32 bit EC scalars ?
13:19:02 <ghostway[m]> They are, most of them at least. Some are scalars I think
13:19:16 <ghostway[m]> But do not take my word for it
13:19:27 <moneromooo> So you want to... replace crypto::secret_key with some other object ?
13:19:42 <moneromooo> Or improve crypto::secret_key ?
13:19:59 <moneromooo> There are two things I can think of that'd be nice to improve there:
13:21:11 <moneromooo> 1: ringct uses a rct::key type, which is a catch-all for public keys, secret heys, hashes... Those aren't mlocked or zeroed on scope end. But they're used in so much places that replacing it with secret_key/public_hey_hash would probably be prohibitively invasive
13:22:12 <moneromooo> 2: mlock works at page level I think, so locking a 32 byte key locks 4 kB (typically). Locking 8 keys locks 8 pages, at random places. It would be nice if secret_key could be unobtrusively made to pool the backing memory in contiguous data.
13:22:32 <moneromooo> However, that'd likely impact performance due to an extra indirection.
13:22:48 <hyc1> yes, mlock is page based
13:23:15 <moneromooo> But you could then also, if you were very paranoid, ensure you get a no-read page before and after the keys. So noone can get to read lots of data from a random place and snarf keys that way.
13:23:25 <hyc1> gnutls/libgcrypt had a secure_malloc that tried to do this
13:24:05 <hyc1> afaik libgcrypt has been abandoned in favor of nettle tho, and I don't think they copiedthat feature
13:24:44 <moneromooo> Pooling all disparate keys into a small number of contiguous pages ?
13:25:10 <hyc1> that was the idea, any module that wanted to allocate memory for something sensitive would use the secure_malloc
13:25:29 <hyc1> one problem is many systems require superuser access to use mlock
13:25:58 <hyc1> or the default rlimit for mlockable pages is zero
13:25:59 <moneromooo> It's a bit hard to retrofit too. Like, if you have "crypto::secret_key skey;" on the stack, which we do, then you need to override operator& for instance, since the backing store isn't on the stack anyore.
13:26:20 <moneromooo> Honestly, I'm not sure it's worth doing.
13:26:22 <ghostway[m]> Yea I do think it is page based, like you and hyc said. It's for seraphis, shouldve said this clearly. I have it written, it uses a structure called jamtis_mock_keys (mocks for now), and it is a collection of keys. I'm making a wrapper on top of that struct to mlock all of it (so that we wouldn't take so many pages) and reading/writing methods
13:27:13 <hyc1> so far every software project I've seen try to use that has shown it was more trouble than it's worth
13:27:24 <moneromooo> Oh, but seraphis would involve rewriting pretty much all of the wallet code, right ? I think I read that before... 
13:27:43 <ghostway[m]> Well yes, that's the plan heh
13:27:58 <moneromooo> OK, in that case you can disregard what I said about secret_key, doesn't apply to you.
13:28:44 <moneromooo> I like the counter based "ref/unref" thing I made in wallet2. Default encrypted, you ask for access, and the keys are encrypted whenever noone has live access.
13:28:53 <ghostway[m]> It still uses secret_key. Can you explain what you meant by retrofitting? You got me interested 
13:29:11 <ghostway[m]> moneromooo: Yes, that's what I made, something like lock_guard 
13:29:13 <moneromooo> I just meant if you want to do the pooling on existing code.
13:29:40 <moneromooo> But hyc says there's past evidence of it being not worth it.
13:29:44 <hyc1> how many keys need to be managed, really?
13:29:55 <hyc1> doesn't sound like you're going to be pooling a lot of info
13:30:25 <moneromooo> You could look up snarks too, IIRC it's about regularly changing in-memory encryption key. I forget what this was meant to be protecting against, so not sure if it's applicable.
13:30:45 <moneromooo> (nothing to with with ZK proofs, name collision)
13:31:06 <ghostway[m]> hyc1: No, not really. 9 keys, but I thought it would be nice to have that
13:31:21 <moneromooo> Ensure they're aligned on a suitable boundary for cache performance.
13:32:17 <ghostway[m]> moneromooo: hmm, I'd imagine it's for spectre/meltdown stuff, when they can leak memory, but very slowly
13:32:30 <hyc1> mlock won't prevent that
13:32:44 <moneromooo> Predates that by a lot. Unless this was known to some types at the time.
13:32:49 <hyc1> not even sure mprotect will
13:32:53 <ghostway[m]> He mentioned something with changing the keys
13:33:49 <moneromooo> I *think* the idea was to prevent someone from locating high entropy sections of a dump which never change. If so, it seems like security by obscurity but my memory's very hazy here.
13:34:20 <hyc1> the only point of using mlock is to prevent in-memory keys from being written to a swapfile
13:35:30 <hyc1> to prevent sidechannel access you need to remove read access, which is what mprotect does. but I'm not sure that pagetable access controls even affect spectre attacks.
13:35:57 <hyc1> I think that was part of the problem in the first place, they accessed memory that they shouldn't have had pagetable permission to see
13:37:05 <ghostway[m]> hyc1: I think they don't, but not sure
13:37:05 <ghostway[m]> moneromooo: I see, ok. So in summary, what should I include? Do you think that ref/unref solution would be helpful? What I did is to use the copy constructor of the guard I made to increase the ref, and when it destructs it reduces the ref. But it could be that this is utterly unnecessary, and could be that the functions that this calls use the internal structure (being jamtis_mock_keys) and wouldn't need it
13:37:31 <ghostway[m]> (I mean wouldn't need more than one level of guard, because they'd pass a reference to the keys themselves)
13:38:08 <ghostway[m]> (about the first, they don't need read access)
13:38:28 <hyc1> yeah, that's what I recall
13:39:03 <moneromooo> Honestly if you have mlock and secure zero on dtor, you've got most of what you need.
13:39:39 <moneromooo> Guard pages without read on either side is nice too to avoid read overflow for exfiltration.
13:39:52 <moneromooo> Mainly on lower addresses.
13:40:43 <ghostway[m]> I see. But I think there's no input/dma I need to worry about, or at least one that I know of
13:41:18 <moneromooo> Well, on x86_64 you don't control DMA really. Not sure what you mean by input.
13:41:57 <moneromooo> Scratch my first sentence here.
13:42:46 <ghostway[m]> Input that controls what I need to read and spit out. But this doesn't matters much, I guess
13:47:05 <ghostway[m]> thank you
14:40:53 <vtnerd> Is there documentation anywhere on how monero addresses are encoded?
14:44:02 <moneromooo> I think I've seen this on monero.stackexchange.com a long while ago...
15:03:30 <vtnerd> yeah, this was solved with a google search, sorry
20:37:05 <xFFC> I am ex-big tech employee (who worked at C++ product with billion user in of the unicorns with experience in cryptography research), I want to spend my professional life on Monero, because I believe in its mission of privacy. The catch is monthly $250, I need to cover my living costs. Are there anyway to make money as Monero developer?
20:37:45 <xFFC> (This is kind of related to *dev*, so asked here)
20:38:04 <hyc> some projects occasionally come up with bounties to be paid on completion
20:38:13 <hyc> i dunno what's outstanding at the moment
20:39:42 <xFFC> I can make $250k annually in SF. But I want to work on Monero, and the costs are very low in Latin America. So if anybody knows anything ping me.
20:41:48 <ofrnxmr[m]> Ill let HR know
20:46:13 <Rucknium[m]> xFFC: Welcome. There are a couple of different ways you can be paid to work on Monero. You must show that your contributions would be worth it, first. Usually you would do that by submitting PRs to the code base.
20:51:43 <xFFC> Rucknium[m]: thanks. I am familiar the process, actually I have a few contributions to open source project you might be using at the moment to run your desktop (linux kernel). But the problem is, I want to invest my full time expertise on Monero. And to cover bare minimum living I need $250 monthly. (I can make way way more than something like this if I work for company. But I prefer to work on something I admire).
20:53:30 <hyc> A lot of us can make way more working for a private company
20:54:02 <hyc> $250/month seems like something you could get working part time in a fast food restaurant, leaving plenty of time for hobby coding
20:54:24 <xFFC> hyc: exactly. Because I am new to this community, I don’t even know even it is *possible* to make trivial amount money doing (serious) contributions.
20:55:49 <UkoeHB> it is certainly possible
20:55:58 <xFFC> hyc: that is the catch, forget about my previous job, already a ADAS company paying me to work on their OS for $12k monthly. But I prefer to work on something I admire.
20:56:02 <hyc> as a newcomer it would be unreasonable to expect to be paid for new work right away
20:56:30 <hyc> so - watch the discussions in this channel, if an interesting problem comes up that you can help solve, do it
20:56:36 <xFFC> hyc: totally agree. I would pay newcomer either.
20:56:55 <hyc> demonstrate your coding ability, and then you'll have some credibility when you propose a project to be paid for
20:57:53 <hyc> then you can write a proposal, submit it to the CCS, and people will vote on whether to support it, and if it gets enough support, people will donate to meet whatever payment target you set.
20:58:04 <xFFC> hyc: great. And if project get approval, I will get paid (emphasizing: amount of money is not important.)
20:58:15 <hyc> that's the general idea, yes
20:59:20 <xFFC> hyc how many projects get approvals? Is it well defined path? (Don’t worry about technical side, I am quite technical person. I am afraid about its inter-community politics)
20:59:27 <hyc> CCS is good for projects with clear milestones
21:00:02 <hyc> there's also another path, going thru an organization called MAGIC, to be paid as an employee. I'm not a good source for details on that route.
21:00:28 <Rucknium[m]> xFFC: People that have been coding C++ on Monero for a while, supported by community fundraising, have a pay rate ranging from $43/hour to $105/hour right now.
21:00:46 <xFFC> hyc Yeah, I hate organizations. Particularly if that means I have to expose my identity.
21:00:52 <hyc> you can examine other CCSs here https://repo.getmonero.org/monero-project/ccs-proposals/
21:01:37 <hyc> all the supported ones tend to get funded quickly, the community is pretty enthusiastic about new development work
21:01:38 <xFFC> Rucknium[m]: Excellent. I am in! Not because of the money. Just because that would cover my living cost definitely (and I get to work on something I like).
21:01:41 <Rucknium[m]> xFFC: Go to #monero-community:libera.chat and ask plowsof  for details of CCS process.
21:11:25 <valldrac[m]> xFFC: Hey there! Besides C++, what other technologies do you know about? 🤔
21:12:15 <xFFC> valldrac[m]: OS and compilers, software security, a little bit of cryptography. Basically anything system software related. I am in.
21:13:43 <xFFC> When I say I know C++, it is very confusing. Nobody knows C++. Not even standard committee. And I believe me, I have talked to them. They don’t know C++ :))
21:17:29 <valldrac[m]> xFFC: I agree. So what languages do you know? 😏
21:18:40 <xFFC> valldrac[m]: I have spend most of my life doing C/C++ (And CMake). Used to follow Rust around 2013,2014. I can pick it up fast.
21:24:36 <valldrac[m]> <xFFC> "valldrac: I have spend most of..." <- There are projects related to Monero that use Rust, but the core development will still be done in C++
21:27:59 <xFFC> valldrac[m]: prefer C++. Worked on its compiler for few years. It is ugly. But I like it :))
21:32:01 <valldrac[m]> xFFC: https://i.imgur.com/3wlxtI0.gifv
21:34:20 <xFFC> valldrac[m]: you have to try Template Meta Programming :)) it is going to be fun. Each error message is like an actual torture!
21:43:08 <valldrac[m]> <xFFC> "valldrac: you have to try..." <- Nope, I'm having a hard time with basic C++ 😅
21:54:18 <xFFC> 1. Why libsodium instead of OpenSSL? Or BoringSSL? What was the rationale behind libsodium? 2. I wish Monero ditches Boost and switches to https://github.com/facebook/folly or Google/abseil
23:45:27 <sech1> constexpr functions > template meta programming