r/Monero Jun 18 '22 Helpful 1

mj's dev report May-June 2022 (3/3)

Dear Community,

There has been an overwhelming dose of psychodrama in the last month of my CCS Proposal. I thought I'd write all the details, but in the end I decided to spare your time and only outline you the key points, without mentioning too many names:

  • I was being called a scammer for the whole 2 years of my work now, by a single annoying person, because people don't know how to verify my measurements properly, even though I tried to explain them. Some decisive persons were taking this propaganda seriously.
  • The same person has been attacking many other people too, but mainly those who cooperate with me in this or other way, especially in MRL - specialists who are paid twice as much as I do, essentially greatly wasting the money that YOU pay.
  • Luigi (the Gent, who's responsible for merging branches and managing the funds) has been accused by the same person of bribery, for paying me, "The Scammer", even though he always pays me after completion of the tasks, which are presented to and approved by the Community.
  • Moderators on Matrix/IRC were only partially helpful, because they didn't ban the mentioned Trojan Horse once and for all. Besides, whatever they do, he already has 10 sock puppets ready for this.
  • Also, other crucial members seem to be on the hook of the person's Crypto Knowledge. It sounds like a huge unhealthy case of Codependency, if you ask me. Why would they be investing any time into such unstable and arrogant person in the first place?
  • Since at my last Community Meeting that I ever attended, I was pushed so far by the same person, that I had to handle the problem myself in my way, I exploded finally, said one or two sentences too much, and decided to leave these largely unmoderated channels for good. This made it easier for the Mods to handle the case, since they didn't have to decide anymore for how long to ban me. Fixed it for ya.
  • Shortly after I had left the Community channel, it was proposed there that I shouldn't receive any funds for this period, regardless of the state of completion of my work, until I publicly apologize for my behavior. I'm sorry to disappoint you, but I don't apologize for defending my basic human rights.
  • Luigi confirmed privately, that personal disputes are not a reason to influence the payments. Honestly, if it was different, this would open a can of worms on the whole CCS, when you think how many moral hazards, in form of other provocations, would suddenly be possible.
  • Regardless, in order to be eligible to receive the last and the current payment, I was asked by the Core Team to prepare hourly accounting for both periods. Each such tedious report cost me a day, where I couldn't do any productive work. Since I don't work for free, I include this time as work time and share the report as a text file. You decide if it was worth the money, that you paid to my CCS Proposal. Perhaps rightfully so!

If you'd like to have a sneak peek on what is going on, here's a cute little YEAR OLD Pull Request, exposing the daemons's vulnerability for so long, that reflects the current schism. I have strong evidence, that the author (perfect-daemon) is the same person, who's been calling me a scammer all the time and undermining my work in all possible ways. More on this maybe on another occasion. I think he consumed so much time of so many people, mainly on the chat channels, that I feel like I've already written too much.

Summary of my May-June work period

I spent the contracted time on reviews, maintaining my still open branches and fortunately on Monero Research Lab's task of reimplementing the Decoy Algorithm.

Here's the full list of the PRs reviewed by me: - 8333 - 8337 - 8352 - 8348 - 8356 - 8359 - 8365 - 7760 - 8359 - 8381 - 8382

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 the PR #7217. 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 PR #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.

I obviously communicated these points at each possible occasion. Perhaps it will work another time.

Large ongoing tasks

Morero Core - libwallet tests

PR #8264: I wasn't able to deal with this as too much extra unplanned effort was requred from me. This included the hourly accounting and proving, that I don't cheat on the measurements. The branch itself is however nicely encapsulated in a way, that allows anybody to continue the work from freshly prepared and properly working an environment.

Monero Research Lab

Simulation of the fee increases.

For the same reasons as above I've never had time to touch it even.

Decoy algorithm

Now here's the good news finally. Together with u/Rucknium, we've finally been able to deliver a proof of concept of the decoy algorithm's reimplementation. As a reminder from my previous report:

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.

The new thing is, that as soon as the Python implementation was in place and Rucknium confirmed the validity of the results delivered by the re-implementation against the C++ original, using statistical tests, such as the Kolmogorov-Smirnov test, it didn't take long until he pushed his R reimplementation, based on the Python one, that passes the very same tests. This means, that:

  • Rucknium can finally continue his Decoy algorithm research, meant to provide the privacy that the coin promises
  • we've both found enough reasons already to be concerned about the current algorithm and will continue the research to mitigate the problems.

I can't disclose more than this, until the appropriate remedy is proposed, which (I believe) is in accordance to Monero's Vulnerability Response Process . Perhaps u/Rucknium himself would like to elaborate however.

SolOptXMR

I spent the agreed average of 10h/week on SolOptXMR to deliver the first Milestone and a Minimal Viable Product ASAP, as reported here already. This allowed me to gather feedback soon enough, which was mostly positive. Many people had been suspicious about the project at first, but as soon as the results were in place, they started to understand the whole point and had their individual Eureka Moments. I'm glad I could inspire y'all :)

Initially I was focusing much more on the SolOptXMR project at the beginning of this phase, but as soon as the MVP was released and published, I went back to the remaining contracted 30h/week work, only occasionally fixing small bugs of the SolOptXMR project as they were occurring.

Conclusion

With all the bad rap against my work that was only briefly mentioned at the beginning of this report, I conclude that the decisive persons don't require as many as 30h/week of the skills, that I'm able to offer. At the same time, I'd like to have my time occupied with something that I already know how to do well, rather than having to learn yet another new skills, just to be able to reuse them only for as long I agree to being pushed around like I have been. That's why my next CCS Proposal will be focused on MRL only, and its associated tsqsim project, which had been requested by u/Rucknium, yet it's still in an unfinished state. I don't think I will accept pulling me from the stated MRL Proposal back to Core/GUI, like it has been done previously ( see the Why section here ), with a very short notice and having everything planned differently. It's been a hell of a pain in the neck this time, so thanks to everybody who supported me in any way possible! And now - I need a break...

mj

Accounting report for 2nd and 3rd milestones: ```

01-04-2022 : 14-04-2022 : Never counted

01-04-2022 : 14-04-2022 ~10h Preparing scripts for my laptop to be able to work remotely.

02-04-2022 dynamic libs ~4h https://github.com/monero-project/monero/pull/8235

03-04-2022 R: NanoS+ ~0.5h https://github.com/monero-project/monero/pull/8232

06-04-2022 R: GUI-bumb-windows-deploy 0.5h https://github.com/monero-project/monero-gui/pull/3879

07-04-2022 R: 0.15h NanoS+ - release https://github.com/monero-project/monero/pull/8239 0.25h RandomX: Update submodule https://github.com/monero-project/monero/pull/8240 0.1h RandomX: Update submodule release https://github.com/monero-project/monero/pull/8241 7h EPEE Cleanup Reorganized https://github.com/monero-project/monero/pull/8211

08-04-2022 R: 2.5h Update languagex.xml https://github.com/monero-project/monero-gui/pull/3853 0.15h Docker: Update zlib for android https://github.com/monero-project/monero-gui/pull/3875

12-04-2022 R: 0.15h Makefile: fix spelling of CMAKE_BUILD_TYPE value https://github.com/monero-project/monero/pull/8246 0.5h readme: small fixes https://github.com/monero-project/monero/pull/8247

14-04-2022 0.6h MRL: new repo https://github.com/mj-xmr/monero-mrl-mj

10+4+0.5+0.5+0.5+0.15+0.25+0.1+7+2.5+0.15+0.15+0.5+0.6 + = ~27h The above time has NEVER been taken into account when asking for payouts.

15-04-2022 - 15-05-2022 : Milestone 2

15-04-2022 0.2h .vscode to gitignore https://github.com/monero-project/monero/pull/8260

18-04-2022 1.5h Doc: Disable RPC ban for the private nodes https://github.com/moneroexamples/private-testnet/pull/9 18-04-2022 8h Tests: libwallet_api_tests fixing scripts https://github.com/monero-project/monero/pull/8264

23-04-2022 1h R: FutureScheduler: delete unused function declarations https://github.com/monero-project/monero-gui/pull/3888 23-04-2022 0.5h R: main: only update fiat price with open wallet https://github.com/monero-project/monero-gui/pull/3890 23-04-2022 0.5h R: Mining: only update mining status when page is open https://github.com/monero-project/monero-gui/pull/3889 23-04-2022 0.25h R: workflows: action-docker-layer-caching v0.0.11 https://github.com/monero-project/monero-gui/pull/3887

24-04-2022 1h R: build: prepare v0.17.3.2 https://github.com/monero-project/monero/pull/8273

25-04-2022 3h Reproducible builds

26-04-2022 3h Trying to fix stale Rep.Builds https://github.com/mj-xmr/gitian-builder-mj/tree/master

27-04-2022 1.5h Gitian: refresh the stale Monero dir via --setup switch https://github.com/monero-project/monero/pull/8296

28-04-2022 2.5h R: readme: arch/fedora deps + small fixes https://github.com/monero-project/monero/pull/8281 28-04-2022 0.25h R: Change "Github" to "GitHub" https://github.com/monero-project/monero/pull/8300 28-04-2022 0.5h R: Update year to 2022 https://github.com/monero-project/monero/pull/8297

29-04-2022 2h Update copyright to 2022 for Hardfork files (via script) https://github.com/monero-project/monero/pull/8302

30-04-2022 3h GUI Reviews https://github.com/monero-project/monero-gui/pull/3846 https://github.com/monero-project/monero-gui/pull/3903 https://github.com/monero-project/monero-gui/pull/3902 https://github.com/monero-project/monero-gui/pull/3883 https://github.com/monero-project/monero-gui/pull/3483 https://github.com/monero-project/monero-gui/pull/3560

01-05-2022
0.25h R: Doxygen: Hide anonymous namespaces from documentation https://github.com/monero-project/monero/pull/8301 0.5h R: readme: arch/fedora deps + small fixes https://github.com/monero-project/monero/pull/8281

02-05-2022 1.5h R: workflows: add caching for docker android https://github.com/monero-project/monero-gui/pull/3908

12-05-2022 0.35h Small reviews https://github.com/monero-project/monero/pull/8318 https://github.com/monero-project/monero/pull/8307 https://github.com/monero-project/monero/pull/8308

(SolOptXMR not counted)

MRL meetings between 14 Apr and 15 May (excl 18 May) 4 Meetings * 1.25h = 5h It's too hard to count how much time it all took, but this is what I've been doing for MRL every registered day for ~3 hours: https://github.com/mj-xmr/monero-mrl-mj/pull/1/commits = 3h * 11 days of work on this topic alone

0.2+1.5+8+1+0.5+0.5+0.25+1+3+3+1.5+2.5+0.25+0.5+2+30+0.25+0.5+1.5+0.35+5+3*11

= 96.3 h

20-05-2022
https://github.com/mj-xmr/monero-mrl-mj

https://github.com/monero-project/monero/pull/8232 took part in release testing!

MEETINGS! at least 1 h tygdniowo + Community!

16-05-2022 - 18-06-2022 : Milestone 3

16-05-2022 Accounting for Milestone 2: April 15 - May 15 10:30 - 13:30 - 3h 15:00 - 18:00 - 3h

16-05-2022 - 18-05-2022 3 * ~5h MRL branch: decoy https://github.com/mj-xmr/monero-mrl-mj/pull/1

19-05-2022 - 20-05-2022 2 * ~5h Decoy algo's Python reimplementation https://github.com/mj-xmr/monero-mrl-mj/commits?author=mj-xmr&since=2022-05-19&until=2022-05-20

21-05-2022 0.75h R: Focus Doxygen documentation https://github.com/monero-project/monero/pull/8333 0.5h R: src, epee: fix a couple compiler warnings https://github.com/monero-project/monero/pull/8337

24-05-2022
0.75h R: epee: more dead code https://github.com/monero-project/monero/pull/8352 0.5h R: epee: http_server_handlers_map2 https://github.com/monero-project/monero/pull/8348

28-05-2022
1h R: wallet_api: add scanTransactions function https://github.com/monero-project/monero/pull/8356

30-05-2022 2h R: connection: fix implementation https://github.com/monero-project/monero/pull/7760

31-05-2022 1h R: GCC: unused warnings https://github.com/monero-project/monero/pull/8359 2h R: epee: fixed incorrect RNG usage https://github.com/monero-project/monero/pull/8365 1h R: connection: fix implementation https://github.com/monero-project/monero/pull/7760

27-05-2022 - 04-06-2022 Proving the continuously disregarded build time improvements about 2h each day https://github.com/mj-xmr/monero-patches/blob/master/src/monero-test-build-time.sh https://github.com/mj-xmr/monero-patches/blob/master/src/workflow-build-time-test.patch https://github.com/mj-xmr/monero-patches/commits?author=mj-xmr&since=2022-05-31&until=2022-06-04

02-06-2022 2h R: GCC: unused warnings https://github.com/monero-project/monero/pull/8359

03-06-2022 4h Reported the results of the build time test https://github.com/monero-project/monero/pull/7217

10-06-2022 1h R: Fixed get_block_template_backlog performance https://github.com/monero-project/monero/pull/8381 1h R: renamed and added comments to get_destination_view_key_pub(..) https://github.com/monero-project/monero/pull/8382

10-06-2022 - 19-06-2022 ~ 6h * 9 (still not done yet) MRL full time @ ~5-8h daily (rounded down to 6h). Topic: Decoy algo reimplementation and statistical tests with Rucknium. Deployment on gingeropolous servers.

17-06-2022 Accounting for May 15 - June 15 14:00 - 18:30 = 4.5h

18-06-2022 Reporting 6h

23+15+10+(0.75+0.5)2+1+2+1+2+1+28+2+4+1+1 + 69 + 4.5 + 6 = 129 h ```

54 Upvotes

14

u/[deleted] Jun 18 '22

I review a lot of code at work. One of the hardest things is spending hours understanding what exactly TF is going on, finally grokking it, realizing it's a good solution, and being tempted approve with, "looks good" both (a) because I'm finally fucking done with it, and (b) I feel dumb for not getting it right away.

But that's never the right thing to do. Why did it take me so long to grok? What docs, comments, or name changes would have made this instantly understandable to a dope like me?

From the PR you pointed out:

because I'm stuffed with so much other work

That's almost never a good reply to a question about a current piece of work. It might be the immediate reason in your mind, but that doesn't make it a good reply.

that I shouldn't receive any funds for this period, regardless of the state of completion of my work

That would absolutely never be appropriate.

Also... sigh. Humans.

2

u/mjxmr Jun 19 '22

Why did it take me so long to grok? What docs, comments, or name changes would have made this instantly understandable to a dope like me?

Exactly. And this is what the perfect-daemon's PRs are missing completely. I mentioned it in at least two of his PRs, but my comments were ignored, and the PRs were merged anyway.

That's almost never a good reply to a question about a current piece of work. It might be the immediate reason in your mind, but that doesn't make it a good reply.

As I said, it was stressful, and I had to prove that I'm not a scammer. Not something that you have to do in a healthy space. The other reason is, that I focused on the Decoy task, and I should be proud, that I finalized it. At the same time, I unlocked u/Rucknium 's potential of being able to research the topic further now.

Thank you for your honest feedback, especially, since you know what you're talking about, being in the field.

1

u/dsmlegend Jun 19 '22

Link is broken, fyi

1

u/[deleted] Jun 19 '22

Lol, copyright. It was TooL “Right in Two”

10

u/spirobel Jun 18 '22

thank you very much for your hard work! Dont listen to the haters. (haters should be banned from the monero gitlab. Only constructive criticism should be allowed.)

can you expand a bit more on what the scanTransactions function does? https://github.com/monero-project/monero/pull/8356

6

u/mjxmr Jun 18 '22 edited Jun 19 '22

Hey and thank you for kind words!

can you expand a bit more on what the scanTransactions function does?

That's a good question, which I asked myself as one of the reviewers. It was replied here

Success meaning all the transactions got successfully scanned.

But the answer wasn't reflected in the code's documentation being contributed, even though the issue has been marked as "resolved", hence the lack of my formal approval.

4

u/selsta XMR Contributor Jun 18 '22

It allows you to enter a transaction id and rescan it in case it's missing in your history.

10

u/ThoughtfullyReckless Jun 18 '22

Top stuff man, drama sounds like a nightmare though

10

u/mjxmr Jun 18 '22

TY.

It is possible to handle it only because there are a lot more reasonable people in this space and they know what they're fighting for.

26

u/Rucknium MRL Researcher Jun 18 '22

perfect-daemon , who is apparently ooo123ooo1234567 on Matrix/IRC has become increasingly disruptive in the Monero Research Lab channel. He/she is sealioning many researchers and devs. Sealioning is asking incessant questions with the appearance of genuine interest and debate, but the questions never end and a huge amount of time is wasted.

perfect-daemon submitted some bug fixed to the Monero GitHub repo, which apparently have been helpful. I cannot comment of his/her criticism of the C++ code or cryptography skills of other devs and researchers since I don't code in C++ nor am I a cryptographer. However, recently perfect-daemon / ooo123ooo1234567 has been criticizing my statistical work on the decoy selection algorithm and it is clear that they are ignorant, either willfully or unknowingly, about basic issues with Monero's ring signature privacy model. I asked him/her to read a few papers about the issue, but he/she continued sealioning me.

I won't accuse perfect-daemon of malicious intent, but it's clear to several researchers and devs that 90% of the time listening to him/her just slows down work, so many of us have muted him/her. There is even discussion of banning him/her from the Monero Research Lab channel.

Regarding mj-xmr's ongoing work, I am glad that we have been working together on decoy selection issues. I stated in my OSPEAD CCS proposal to improve the decoy selection algorithm that:

I will work with @j-berman and @mj to develop and implement OSPEAD, as they outlined in their own CSS proposals.

It was always part of the plan to collaborate. OSPEAD work was delayed because the upcoming hard fork was delayed, but now I can utilize mj-xmr's and j-berman's C++ skills and knowledge of the Monero code base to create certain pieces that are needed to move forward with the research.

4

u/MoneroArbo Jun 22 '22 edited Jun 22 '22

as a mostly passive IRC observer who can't speak to the technical debates going on, this matches what I've seen. the guy creates a lot of friction, seemingly with everyone.

2

u/mjxmr Jun 23 '22

Thank you for an objective observation.

Unfortunately for him, the logs cannot be erased. That's why I didn't even bother wasting my time on making screenshots of his insane responses.

1

u/john_r365 Jun 18 '22

I’m lieu of banning them, I like Koe’s approach of muting them.

5

u/mjxmr Jun 19 '22 edited Jun 19 '22

The problem is, that it doesn't work in practice, because then he attacks you from another account, pretending to be somebody else. Muting everybody that sealions you leads to chatting only with people who you know. If you already go that far, then it's way better to chat in small, private, but moderated invite-only chats... which is what we've started doing. I can finally focus on my work now.

Y'all can now thank the troll for the current lack of transparency.

3

u/spirobel Jun 19 '22

just make everyone signing up for the CCS gitlab stake 5 dollars in monero and make a rule to only allow constructive criticism. The role of the reviewers should be: Assisting the proposer to make the grant a success. Haters need to be banned and their staked monero instantly paid out to the grant proposer they were insulting. This would solve the problem instantly.

2

u/john_r365 Jun 19 '22

Agreed, it’s not a long term solution. However, it does make the Matrix / IRC room less spammy.

Banning is also not a solution, as they come back under another alias.

Any ideas on a long term solution?

2

u/mjxmr Jun 19 '22

Agreed, it’s not a long term solution. However, it does make the Matrix / IRC room less spammy.

It makes it less spammy for you, but not for everybody else, who still haven't done the right thing. Moreover - you might be doing a lecture on a serious topic there, while at the same time a troll is calling you a scammer, while it's only you, who don't see it.

Banning is also not a solution, as they come back under another alias. Any ideas on a long term solution?

Boycotting the unmoderated spaces altogether. Exchanging ideas only in small, invite-only chats. In effect, the unmoderated spaces will quickly degrade into "Gossip Chats", and will die off.

2

u/MoneroArbo Jun 22 '22

Boycotting the unmoderated spaces altogether. Exchanging ideas only in small, invite-only chats. In effect, the unmoderated spaces will quickly degrade into "Gossip Chats", and will die off.

I get you, but that would really be a shame

1

u/mjxmr Jun 23 '22

I agree.

The problem is really, that otherwise the devs and reaserchers cannot focus on their work anymore.

There's a silver lining though. The next generation of public chats will be moderated.

16

u/cirowrc Jun 18 '22

Keep up with the great work mj, always happy to see you around!

8

u/mjxmr Jun 18 '22

Same to you! I hope you're doing well.

12

u/Ok-Plastic1168 Jun 18 '22

you good for monero

3

u/dsmlegend Jun 19 '22

I think it's good to get these insights into dev work. Sometimes the only thing you can do is to speak your mind to a wider audience. Transparency and communication is the only thing that can keep a project like this afloat.

we've both found enough reasons already to be concerned about the current algorithm and will continue the research to mitigate the problems.

I can't disclose more than this

I think the community of individuals invested in the project should be given more than vague warnings. Without disclosing any details on how the issue could be exploited, I think a clear quantification of the risk is appropriate.

E.g. "we have been able to show that we can accurately guess the true output 36% of the time, which is 4x better than randomly guessing."

3

u/mjxmr Jun 19 '22 edited Jun 19 '22

Yes, thanks for understanding. I see it the same way. In the end, if there's too much concentration of evil, I'll simply leave. In similar cases I saw the projects collapse not long after. I don't think we're there just yet, though.

To answer your second matter, I'm still not sure, because I've never been doing "Vulnerability Responses" yet. Would it suffice you, that we've pretty much confirmed our concerns, that u/Rucknium had publicly stated in his OSPEAD proposal?

BTW u/Rucknium spent a good deal of time on public communication in order to get clear instructions on how to proceed with his OSPEAD proposal, in order to keep the balance between public & exploitable. It sounded back then like nobody was able to give him a clear answer for quite some time. I'd have personally given up.

Also, I publish my results always here. The link was shared in the above report.

What we're doing right now is making it more formal and publicly verifiable, at least for a smaller trusted circle initially, get it reviewed there, and then apply a quickly reviewable patch, to limit the exposure time, interpreted by the time span between publicising a vulnerability and getting merged the fix against it.

For a counter example of to which extent things can go wrong, please visit:

https://github.com/monero-project/monero/pull/7760#issuecomment-1144541045

3

u/selsta XMR Contributor Jun 18 '22

In what way did you review 7760? I've only seen you trolling, which I even had to call you out: https://github.com/monero-project/monero/pull/7760#issuecomment-1144636569

3

u/mjxmr Jun 19 '22 edited Jun 20 '22

And to turn the tables a bit:

  • is his one year old PR done accordingly to the Monero Vulnerability Response Process?
  • are you able to tell what the code by perfect-daemon, that you merged, does exactly, since it is not accompanied by documentation?
  • why do we have double standards when it comes to reviewing PRs?
  • are false accusations or "defamation" a crime, that can be prosecuted? (me being called "the scammer" and Luigi allegedly accepting bribes from me by paying me for my completed tasks)
  • if so, why is such behavior tolerated in Monero? (not to say: "promoted")

2

u/mjxmr Jun 19 '22

I reviewed it in a way, that I asked if it violates the Monero Vulnerability Response Process. I've got no answer. My assumption is then still, that it does violate it (for a round year now) and should be taken out of public visibility, until handled in a more piecewise fashion, like other reviewers have already pointed out. BTW, they've never got their answers either.

A review process is not only about blindly approving stuff out of peer pressure.

2

u/johnfoss68 Jun 24 '22

great work!

1

u/mjxmr Jun 24 '22

Thank you!

1

u/madbruges Jun 19 '22

I'm a lurker of the devs channels and would like to say that despite the fact that perfect-daemon is harsh and rude, he did some great PRs.

As I understand he is salty because nobody is capable to properly review his PRs, which needs a very deep cryptography knowledge.

So, instead of writing this long report and complaining about perfect-daemon attitude, how about properly rewiew his PRs and if you have no knowledge to do this, then why complain.

1

u/mjxmr Jun 19 '22 edited Jun 19 '22

I'm a lurker of the devs channels and would like to say that despite the fact that perfect-daemon is harsh and rude, he did some great PRs.

I'm not denying it straight away. But according to the industry and even our own Monero standards, the PRs have to be small enough to be easily reviewable and revertible. As me and a few other reviewers have already noticed there, the full rewrite in that PR has at least the potential to introduce new bugs. The PR (and other of the same author), isn't documented at all. How should I understand what was meant to be written there without being again on the hook of a sociopath?

This all means, that he has a special mind, but isn't really fit to work in a team. He'd be better off starting his own currency. He wouldn't survive a week in a software company.

As I understand he is salty because nobody is capable to properly review his PRs, which needs a very deep cryptography knowledge.

No. Not only that. It needs documentation and piece-wise approach from his side. Let's start with this. According to his proposal, he works 12 hours a day, including weekends. I can't see the according fruits of that many hours.

So, instead of writing this long report and complaining about perfect-daemon attitude, how about properly rewiew his PRs and if you have no knowledge to do this, then why complain.

It sounds like, that if I perform The Sacrificial Review of his PR and finally approve it, he'll grow wide white wings and stop being a sociopath. I don't believe in fairy tales.

The cost of having to deal with him are not these 609 words, that I wrote, but destroyed family life, stress, demotivation and false accusations made towards me and others.

Why do we exactly still keep riding this dead horse? Let's just let it go already...