how i get free monero

allenwrench[m]: 😆

since monero doesnt let users see others wallets, whats to prevent me from filling my wallet with dope monero?

🤦🏻‍♂️

<allenwrench[m]> "since monero doesnt let users se" <- Please take this discussion to #monero (or nowhere lol) this isnt the right room for that.

Hey all, just sharing my first CCS proposal: xmrSale - a self-hosted monero payment processor (based around bitcoin's SatSale).

try.xmrsale.org

You would be able to receive donations, and also use it for woocommerce wordpress webstores. I think this is an underdeveloped area for the self-hosted tools stack, and monero could more easily be accepted for payments

lmk if you have any questions / feature requests

thanks!

sorry if this isn't the right place for this btw, if there's a more appropriate channel please let me know

<tarkdools[m]> "Hey all, just sharing my first C" <- Python tho 🤢, we also started writing a payment gateway although in Go gitlab.com/moneropay/moneropay

Stnby[m]: awesome ill check it out!

Python does make contributions from noob devs easier :)

Also we have up to date fork for for walletrpc bindings in Go

* Also we have up to date fork for for walletrpc bindings in Go

under same Gitlab user

> <@stnby:kernal.eu> Also we have up to date fork for for walletrpc bindings in Go

> under same Gitlab user

Other go walletrpc bindings have this bug where they don't have omitempty in their request structs. It causes undefined behavior.

By default the unspecified fields such as the optional parameters are either 0 or false and it gets sent anyway. It's weird how nobody else noticed that.

who uses go ...

I found out recently that R is more widely used than Go, according to the TIOBE Index 😁

tiobe.com/tiobe-index

> <@rucknium:monero.social> I found out recently that R is more widely used than Go, according to the TIOBE Index 😁

> tiobe.com/tiobe-index

The higher it is in that list the shittier it is (1 exception C)

>go is matlab tier

sounds about right

* >

go is matlab tier

sounds about right

Explains why m$ languages are high up

Or python

Abominations

I'd like to have a talk with whoever is looking up Prolog :D

Update on 7821 + 7798: I'm testing different combinations of solutions to the decoy selection algo, and plotting a smooth simulation of each solution against observed

I believe luigi1111 's intuition was correct, and that dumping many outputs right at the first block would lead to marginally greater issues with under-selecting later outputs. I think I'll have another solution ready by Monday/Tuesday (headed to Vegas this weekend)

cool

Also, I think the yellow triangle above the orange line chart makes it extremely clear that either:

1. the current algo under-selects recent outputs (which is explained by both 7821 + 7798)

2. there exists a popular wallet implementation not using the gamma distr, and is using another algo that over-selects recents

I'm looking into the latter possibility as well when trying to deduce real spents, as it doesn't look like #1 *fully* explains it but *mostly* explains it

If you want another set of eyes on this, I have a pretty deep background in statistical theory. On the other hand, I don't feel like I understand XMR quite enough on a technical level yet, so I would probably need to do additional reading to understand the problem and the proposed solution.

Yes more eyes the better :) I'll write up an explainer

Or just send me links to what I could read to get up to speed. I mean, I've seen the discussion in passing, but I haven't really concentrated on it.

This is probably the best to start on I think: monero-project/monero #7807#issue-953417717

This explains exactly what the problem is that is causing that issue: monero-project/monero #7821

And here is a second issue that causes the algorithm to under-select recent outputs as well: monero-project/monero #7798

Does the selection algorithm select based on number of seconds or number of blocks?

Seconds

Ok good. I was going to say, if it's number of blocks then I would see why it's hard to select recent outputs since Gamma is a continuous probability distribution, not discrete like blocks.

But then you have to map it onto actual blocks to get the transactions..? 🤔

Anyway, I will see if I can read through things. Thank you.

It calculates average seconds per output over the prior year, then divides the exp(x) spit out by the gamma by average seconds per output to arrive at the expected output

Then it finds the block that expected output is in, and just picks a random output from that block

Off-the-cuff: If I were designing this, I would also adjust the shape parameter of the Gamma distn based on the last year's txs. The linked paper just developed those parameter values based on fitting to a distribution based on data prior to Feb 2017. The optimal parameter values could have changed since Feb 2017. (But maybe the algorithm already does this?)

The paper uses empirical data of known real spents to arrive at the shape. Since last year, we don't have a distribution of real spents with which to use, since they have been hidden by the algorithm

What are the academic disciplines of the authors of the "An Empirical Analysis of Traceability in the

Monero Blockchain" paper? I guess I could investigate one-by-one, but anyone know offhand? The paper doesn't say

Andrew Miller is a CS/ECE prof at UIUC, Arvind Narayanan is a CS prof at Princeton

those are the 2 I know

Separately, there also may be an issue with the shape in that it is just a tad bit too low (possibly should be 19.54 instead of 19.28), which I'm waiting to hear back on

while investigating the other paths mentioned above

No statisticians? I mean, it should probably be ok. I just am querying because I have run into enough computer scientists who think they know about statistics. What they know is "an amount just enough to be dangerous". Not trying to be confrontational. It's just that different disciplines may approach things differently with a different "dialect", so it's good to know the dialect before I start reading

I'm not sure. I'm most definitely not a statistician as I think should be obvious in my dialect haha

(I mostly see the bad side in machine learning. Other subfields may be A-OK)

I did well in my probability and stats course in CS undergrad which has come in handy, that's the extent of my training

I'm an empirical microeconomist, which for this discussion translates basically into an applied statistician.

Ok I will see if I can dive into it this weekend. I will be vague and say that my training in statistics is Very Extensive. I do not understand cryptography on a technical level, however, so my understanding of the issues involved may be limited.

This is actually a 100% stats problem, not cryptography at all, so all good

(They also could have chosen to fit an empirical distribution function nonparametrically. Paper says: "We heuristically determined that the spend time distributions, plotted on a log scale, closely match a gamma distribution." Which, decoded, means, I believe, "We looked at a plot and it appeared Gamma".)

I don't mean to open a bunch of cans of worms, however 😬

Here's the code they used: github.com/maltemoeser/moneropaper/…blob/master/Monero%20Analysis.ipynb

Final section of that code is where the fitting happens

The paper said they used R, not Python, though. 🧐

I have not read the paper. I am just skipping around.

Ya, that's one weird thing talking to authors about

it does look like they used different code to get at the numbers in the paper. But the code in that repo appears correct to me (though haven't given it an extremely deep dig through), and 19.54 isn't too different from 19.28

in that shouldn't have a huge impact. I'm going to plot the simulated algo using the modified shape and see what turns out too

> 19.54 isn't too different from 19.28

To me, that would be big if the difference is "only" in porting across programming languages.

* >

19.54 isn't too different from 19.28

To me, that would be big if the difference is "only" in porting across programming languages.

* > 19.54 isn't too different from 19.28

To me, that would be big if the difference is "only" in porting across programming languages.

* >

19.54 isn't too different from 19.28

To me, that would be big if the difference is "only" in porting across programming languages.

*

"19.54 isn't too different from 19.28"

To me, that would be big if the difference is "only" in porting across programming languages.

* "19.54 isn't too different from 19.28"

To me, that would be big if the difference is "only" in porting across programming languages.

The maximum likelihood function should be globally concave in this case, I think, so just one maximum to arrive at 🤔

If I am a transaction, can I pull a mixin from the same block that I am supposed to be confirmed to -- Like, I see a transaction in the mempool and I pull a mixin from it?

No, it must be from at least 10 blocks earlier

Back when the gamma was constructed, you could pull from 1 block prior

Thus, a dilemma in exactly how to use the empirical data from between 1 - 10 blocks, since what the gamma implies is no longer possible

There is such a thing as censored and truncated distributions that may be able to help. Anyway, I should stop spamming the general chat room. I will try to read things this weekend.

Interesting, looking forward to hearing more :)

(Censored and truncated distributions are used extensively in microeconomics since often quantities are censored at zero, i.e. no purchases by some consumers, or data is simply missing)

Relevant note too, the current implementation also cuts off the ultra long tail (if seconds suggested > age of the blockchain)

I think we invented most of the statistical theory around those distributions. Ok, I'll shut up now.

jberman[m]: if the gamma suggests an output older than all plausible outputs that can be used as mixins*

Could someone please confirm that the Vulnerability Response Process to be followed is the one that is described here?:

I dm'd luigi1111 & moneromeow when I spotted those 2 issues. Was told hackerone is also good

Also, is it permitted to discuss potential vulnerabilities with persons other than the security response team, as long as it is via encrypted channels, or no?

Exercise common sense. At first approximatoin, discussing with the person who write the code is fine, discussing with some spamming nutjob is not.

If in the middle, I guess you can ask for opinions.

Ok sounds good. I assume discussing with @jberman is A-OK.

New person, but seems totally good so far.

I am also a new person, anyway ;)