01:51:55 <nittlocus[m]> hello! id love to learn more about how to contribute to monero development! any suggestions on what resources to use to get started? sorry of this is a basic question.
02:24:03 <endogenic> what's your background? would help to know
02:24:09 <endogenic> nittlocus[m]: 
02:24:51 <endogenic> oh, i guess you just mean dev overall - thought this was #monero 
02:25:18 <endogenic> i guess the github repo issues.. you could also look at something like mastering monero and read various MRL articles
02:25:25 <nittlocus[m]> ahh im sorry is #monero the correct place for that question?
02:25:28 <endogenic> no no
02:25:38 <endogenic> i'm just trying to do 4 things at once :P 
02:26:25 <endogenic> though if you do have a specific background like, say, in networking, or storage, ... etc then people could point you in specific directions
02:26:37 <nittlocus[m]> ahh okay cool and my background is that im currently a cs indergrad student with c++ and c experience mostly
02:26:43 <endogenic> nice
02:26:52 <nittlocus[m]> so im not particularly experineced in a certain field
02:27:13 <nittlocus[m]> more just extremely onterested in being a  crypto dev and i have always supported monero
06:30:32 <mj-xmr[m]> <nittlocus[m]> "hello! id love to learn more abo" <- To learn what the current problems are, you can look at the issue list, like it was said, or here:
06:30:32 <mj-xmr[m]> http://cryptog.hopto.org/monero/health/
06:30:53 <mj-xmr[m]> Go ahead and read about the tools to learn what they do.
06:32:14 <mj-xmr[m]> Then to learn how to start:
06:32:14 <mj-xmr[m]> https://github.com/monero-project/monero/blob/master/README.md#contributing
06:32:14 <mj-xmr[m]> https://github.com/monero-project/monero/blob/master/docs/CONTRIBUTING.md
06:32:14 <mj-xmr[m]> https://github.com/monero-project/monero/blob/master/docs/COMPILING_DEBUGGING_TESTING.md
06:39:35 <nittlocus[m]> thank you!! ill start on this tomorrow i really appriciate it!
12:53:23 <MasFlam[m]> is monero::monero_wallet_full from monero-cpp supposed to connect to monerod or monero-wallet-rpc? the js and python libs have examples supposedly using monero-wallet-rpc, but no class in the c++ lib has 'rpc' in its name so i'm confused
12:54:10 <MasFlam[m]> well there is one class but it's just a data class
13:08:57 <UkoeHB> MasFlam[m]: from what I can tell it sets a monerod connection for a wallet2 object to poke. All the function calls are direct wallet2 wrappers.
13:31:58 <MasFlam[m]> ok, thanks for the help. i'll look into how js and py libs connect to the wallet rpc then
15:54:34 <codeofco[m]> Hello there. Would anyone be happy to give me some advice please? It's regarding not receiving 10.1 moneros to my only wallet and obviously, I'm wondering how to find them. Thanks.
15:55:54 <t-900-a> codeofco[m]: Not here
15:56:17 <codeofco[m]> Where do recommend I head to please?
15:57:21 <rbrunner> You may try #monero, or https://old.reddit.com/r/monerosupport/
15:57:38 <rbrunner> (This channel here is for dev-related questions)
15:58:41 <codeofco[m]> Thank you rbrunner, really appreciate your guidance. All the best to you.
15:58:50 <rbrunner> You are welcome.
17:34:16 <selsta> We need reviews for 7845 and 7821 for the next release.
17:52:57 <UkoeHB> selsta are both stabilized?
17:53:33 <selsta> I think so
19:47:42 <jberman[m]> Stable on my end, nothing further planned for those PR's from me. Apologies for the confusion
19:53:51 <Rucknium[m]> I am doing my own review of 7821 now.
20:29:49 <Rucknium[m]> jberman: Questions and comments on 7821:
20:29:49 <Rucknium[m]> 1) You say  "considering we've only observed ~0.5% of outputs in this age range [10-11 blocks], it appears as though only a very small percentage of real spents would have been identifiable." If all 0..5% of outputs in that range were real spends, wouldn't it be close to 5% of all spends are identifiable, since real spends only account for 1/11 of the total density of the observed pdf of output age? A, I missing something?
20:31:23 <Rucknium[m]> 2. With graph https://user-images.githubusercontent.com/26468430/129026276-5fd0749d-1e4f-4d27-8a53-a02069392e06.png and similar, do the areas of each curve all add up to the same amount? It looks like not. Maybe scale them so that they are all proper pdfs, i.e. the areas under each curve sums to 1. It may be easier to visualize the differences easier that way.
20:33:53 <Rucknium[m]> 3.a With some work I may be able to get a sense of how big the risk could be to non-upgraders. My sense is that the risk will probably be low unless certain non-upgrading users are very prolific spenders. Basically, 11 observations is not much to go one when you, as an adversary, are trying to come up with which of two similar distributions a given set of mixins was selected from. 
20:37:52 <Rucknium[m]> 3.b If someone is spending a lot, however, there may be some way to track the outdated mixin selection because the sample size would be higher, in a sense. Would be difficult since you have to track across multiple txs with all their decoys. One interesting note here is that increasing ring size would increase the statistical signature of which mixin selection algorithm a user's wallet is using, since the sample size rises with an
20:37:52 <Rucknium[m]> increased ring size. Something to maybe keep in mind for Triptych.
20:41:03 <Rucknium[m]> That's the end of my comments and questions. Overall, it looks like a good solution. The key is to "thicken" the part of the mixin selection algorithm's probability density function that has very young outputs, which this patch does. I mean, I assume it does this since I am not good at reading C++. I am relying on what jberman wrote in the comments to the pull request.
22:11:35 <jberman[m]> Will be back by my computer later tonight to go through this in more detail. But quick answers:
22:11:35 <jberman[m]> 1. I think you’re right, the % of rings affected would be higher than % of outputs affected by roughly that factor. I have to relook at it. I also have a local setup to get an improved estimate that iterates over every ring and checks if it includes an output too young to be a possible decoy. I’ll update and revise those numbers
22:11:35 <jberman[m]> 2. The areas under each curve included in the photo are not the same because the x-axis is cut off to zoom in on the younger output range, where it’s easier to visualize the differences in the curves (as you go further right, they all converge to what looks like the same low y-value). But the areas of each curve when zoomed out without cutting off the x-axis should be the same. Agreed plotting PDF’s would probably be more useful there
22:11:35 <jberman[m]> since absolute output frequency doesn’t tell you much, but still the area under each would be different because I cut off the x-axis
22:13:06 <jberman[m]> Will think more on 3 too