monero-mrl-mj VS monero-patches

Rucknium, J-Bermann and me are breaking down the decoy algorithm in order to better understand its flow by performing statistical tests on it. For this, we need to have an alternative implementation. Python was chosen to be the language, which offers a large variety of frameworks and is widely used among Researchers. My take is being documented here.

u/mjxmr has recently started a python implementation of Monero's C++ decoy selection algorithm here. One of its many uses will be to check to see if anything unintended has happened with decoy selection.

This time I saw no need of opening any branches in Monero Core/GUI. I only focused on maintaining the already opened branches and trying to get them merged. However due to negative propaganda towards my work, it was so far impossible to do it and I spent a good deal of time on trying to prove my points. So far to no avail. See the recently updated (very technical) report under this PR. An outline of this entire discussion would be that: - it was being misunderstood all the time (for 2 years now?), that my speed improvements were targeted for developers, who are supposed to compile the code very often and very quickly, rather than users, who would compile the code from source only once in a quarter. - as such, even though I provided objective methods of measurements (the Clang Build Time Analyser script), their results were being doubted all the time and confronted with measurements done from the User's perspective. In case of 7217, these measurements were underestimating my measurements greatly. - I had to create special tooling here & here, that executes the appropriate build time tests on GitHub's servers, where nobody can tamper the results in neither of the two directions.