-
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.
-
endogenic
what's your background? would help to know
-
endogenic
nittlocus[m]:
-
endogenic
oh, i guess you just mean dev overall - thought this was #monero
-
endogenic
i guess the github repo issues.. you could also look at something like mastering monero and read various MRL articles
-
nittlocus[m]
ahh im sorry is #monero the correct place for that question?
-
endogenic
no no
-
endogenic
i'm just trying to do 4 things at once :P
-
endogenic
though if you do have a specific background like, say, in networking, or storage, ... etc then people could point you in specific directions
-
nittlocus[m]
ahh okay cool and my background is that im currently a cs indergrad student with c++ and c experience mostly
-
endogenic
nice
-
nittlocus[m]
so im not particularly experineced in a certain field
-
nittlocus[m]
more just extremely onterested in being a crypto dev and i have always supported monero
-
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:
-
mj-xmr[m]
-
mj-xmr[m]
Go ahead and read about the tools to learn what they do.
-
mj-xmr[m]
Then to learn how to start:
-
mj-xmr[m]
-
mj-xmr[m]
-
mj-xmr[m]
-
nittlocus[m]
thank you!! ill start on this tomorrow i really appriciate it!
-
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
-
MasFlam[m]
well there is one class but it's just a data class
-
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.
-
MasFlam[m]
ok, thanks for the help. i'll look into how js and py libs connect to the wallet rpc then
-
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.
-
t-900-a
codeofco[m]: Not here
-
codeofco[m]
Where do recommend I head to please?
-
rbrunner
-
rbrunner
(This channel here is for dev-related questions)
-
codeofco[m]
Thank you rbrunner, really appreciate your guidance. All the best to you.
-
rbrunner
You are welcome.
-
selsta
We need reviews for 7845 and 7821 for the next release.
-
UkoeHB
selsta are both stabilized?
-
selsta
I think so
-
jberman[m]
Stable on my end, nothing further planned for those PR's from me. Apologies for the confusion
-
Rucknium[m]
I am doing my own review of 7821 now.
-
Rucknium[m]
jberman: Questions and comments on 7821:
-
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?
-
Rucknium[m]
2. With graph
user-images.githubusercontent.com/2…49d-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.
-
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.
-
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
-
Rucknium[m]
increased ring size. Something to maybe keep in mind for Triptych.
-
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.
-
jberman[m]
Will be back by my computer later tonight to go through this in more detail. But quick answers:
-
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
-
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
-
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
-
jberman[m]
Will think more on 3 too