Quote from: Cheesus on August 27, 2014, 09:30:51 AM

The XMR team in their missives report a lot of work being done. However, we haven't seen any meaningful update for the last several months. Of course, the work on GUI wallet is in progress, buy GUI is not related to the underlying protocol, which XMR copied form Bytecoin and apparently cannot maintain any further.

Why on earth would we constantly change the underlying protocol? Protocol changes will come when they are needed, not because we feel like making random changes to the protocol.

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

Have a glance at the compilation of XMR missives. How many of them are meaningful? The problem is that XMR devs are good at creating the illusion of development while not touching any underlying module (unlike Bytecoin which e.g. implemented multisigs and reworked so many code lines in a month that GitHub cannot even show the diff).

Commit early, commit often. Committing a whole bunch of changes in 1 commit is going to lead to a disaster when you have multiple people working on the same project, because everyone needs to rebase off everyone else's commits. I guess Bytecoin don't need to worry about that.

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

The truth is, among all the well-promoted XMR "development" activities, they've only managed so far to release transaction splitting and deterministic wallet. Everything else you see is either an irrelevant micro change or "a work in progress", which has never been released. It's easy to make an illusion of hardwork development going on, but the fact is XMR developers are not delivering.

Again, disingenuous given that we work in branches before committing to the development branch to make rebasing easier. Things are only merged into master (staging) when they are ready.

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

Take i2p integration as an example:

I guess you must be struggling with your eyesight.

Prior to that blogpost, all the way back on July 25th, Meeh and I confirmed the formation of Privacy Solutions to enable i2pd development to progress to the benefit of both Anoncoin and Monero. Even further back in July the 13th's Missive this was set in motion when we said: "I2P: subsequent to discussions with the I2P team, we are going to be making a bit of a diagonal movement from libi2pcpp to i2pd. This should end up with us slightly ahead on the I2P integration project than we would've been. The major focus at the moment is getting TCP streaming (for persistent connections) to work, and that is where the largest focus is at present."

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

The original blog post about "XMR partnership with i2p" has even been removed from the i2p project's blog. It is quoted in fluffypony's post, but cannot be found on the i2p website: fluffypony bragging (mirror), the blog post has been deleted

This situation is the best evidence. XMR devs are incompetent. Their "partnership" with i2p was yet another hype.

It was replaced with this one: https://geti2p.net/en/blog/post/2014/08/15/The-privacy-solutions-project in order to clarify that we've moved away from i2pcpp and to i2pd instead. The original blog post is archived here: https://web.archive.org/web/20140703064626/https://geti2p.net/en/blog/post/2014/05/25/Monero-partnership

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

XMR devs roll out an undergraduate level C++ bug that might end up with users' money being lost:

Not a single person's money was lost. It was an error that was fixed in a branch and was not merged into master. That was, indeed, a grave mistake, one that has prompted us to focus on adding RPC unit tests so that this does not happen in future. TDD is hard when you're doing it in retrospect.

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

XMR devs used to copy&paste code from other repositories (mostly, Bytecoin & Boolberry) without attribution.

Not true.

We credit and attribute every time. Very early on there were some changes that were merged without attribution before this standard could be universally enforced, that is true. However, all of this changes are also in the CryptoNote Starter (the reference implementation) where it specifically says "Copyright the CryptoNote Developers", so we retain their copyright and really should be attributing the work to them and not Bytecoin.

Quote from: Cheesus on August 27, 2014, 09:30:51 AM

XMR copies the code from BCN, but trolls to death anyone who does the same to their code. One particular case is out of all proportions. Here XMR devs blame XDN devs for breaking the copyright. However, it turns out that the code in question was originally developed by BCN and taken by XMR without attribution.

Blatantly incorrect. The github commit in question from Jun 2nd is clearly titled "Added 'payment_id' optional argument to 'transfer' wallet RPC method". The duckNote developer was confused, and implied that we were trying to claim we wrote the payment ID functionality initially. This is not true. Payment IDs were added to the reference code when it was still in the Bytecoin repository, and we acknowledge that CryptoNote wrote that. However, we added the payment ID option to the RPC call.

Contrary to what you claim, you can see where our code was taken and used by Bytecoin without attribution in their commit on June 25th -
https://github.com/amjuarez/bytecoin/commit/76bb193b0556aaaa3ffa5d48db7bd28eceb36300#diff-b7ff5388bca1357894178fd7f93d4ad8R55

They even took our exact code and stripped the comments out -
https://github.com/monero-project/bitmonero/commit/117393d562fc9782efed0e1b25f6470d9f8102b2#diff-297e4d3d4221d9bf7ea37267597959f9R106
https://github.com/amjuarez/bytecoin/commit/76bb193b0556aaaa3ffa5d48db7bd28eceb36300#diff-297e4d3d4221d9bf7ea37267597959f9R88

Visually -

Our commit on June 2nd:

Bytecoin's commit on June 25th:

Again, Bytecoin did this without attribution. Even duckNote in their commit backed down and attributed us, and I have the utmost respect for them doing so.

Seriously, this stuff isn't rocket science to get right, I don't understand how your post can have so many gaping errors.