There was one more accusation, that in
Jan, 2020 there was an announcement at Telegram about a new release,
and ChekaZ and Peter started to work after that, 'to compete'?
Once all that was done and complete we made stakeholders aware of it (0.17) with a month's advance notice(January 12th). It was a month later that 0.18 was rushed out (Peter Bushnell confirmed he was contacted mid January to build 0.18.
here is Bitcointalk,
September, 2019:
After almost 2 years of stagnation it's clear that without community there is no progress.
Devs come and go, and if we are just waiting for them, it looks for people like the coin is abandoned.
Mooncoin always was backed by the community, like Wikipedia when everyone is able to edit, with no contracts, salaries, companies behind it.
During this stagnation people became passive and probably begin to lose faith in MOON and even don't post in the thread.
However, your posts and ideas matter.
The Mooncoin community suggests and decides things about Mooncoin.
Regarding the Coinexchange issue old investors tried to contact them, but they didn't answer.
It's not a problem to send some MOON to them to reopen wallets,
the problem is it's needed to know their MOON address and the exact amount to send.
If they have lost some MOON, maybe that could happen (to a degree though, other services and users didn't report lost coins) due to outdated codebase of MOON, the latest release was made in Dec, 2017 by a previous dev:
https://github.com/mooncoincore/wallet/releases.
Edit: other than that Mooncoin definitely has to increase its network hashrate, however, if there is no good progress (first of all, no wallet developments and no projects on top of Mooncoin blockchain), there is a lack of interest from miners and investors.
Good afternoon. I agree 100% with you. I have said it many times to the members of Development Team. This community needs positive news. Also, there are many potential investors who watch Mooncoin. However, they need to see some progress.
here is Bitcointalk,
November, 2019:
Also, to prove that our words are not just words and that the future of Mooncoin is in hands of the community,
old investors invited ChekaZ, a transparent person, CoinKit CEO
https://bitcointalk.org/index.php?action=profile;u=99330 to implement MoonWord after almost 2 years of no action from our devs,
the community cannot wait any longer.
In several days MoonWord will be completely implemented by ChekaZ into the official wallet. It will not require a fork, just there will be Mooncoin Windows wallet with intuitively clear MoonWord solution, ready to use on a daily basis, for free, with no 3rd parties, directly onto blockchain.
Great to see that legendary Mooncoin project is still alive and moving forward
Keep it up!
MoonWord has been released under Version 0.13.9.1
https://github.com/ChekaZ/moon/releases/tag/0.13.9.1 ( This is a temporary repository, will post when the new one is up. )
How to use MoonWord:
Important ( txindex=1 ) needs to be set on the config.1. Go to the MoonWord Tab
2. Choose an address from where you want to send the MoonWord ( From )
3. Put the receiving address into the ( To ) Field
4. Write your Message into the (MessageBox )
5. Press send.
How to get Reports?
If you have received a MoonWord:
1. Go to the MoonWord Tab
2. Look at the Bottom left and pick the address from the ( Received Dropdown Menu )
3. Click generate
If you have send a MoonWord:
1. Go to the MoonWord Tab
2. Look at the Bottom left and pick the address from the ( Sent Dropdown Menu )
3. Click generate
Kind regard,
ChekaZ
I will test it. However, it's a good news.
Excellent work! I will also btest this first version this weekend, everyone can suggest other implementations or adjustments.
Thanks ChecaZ
Hi for all Moon Bros, we all know that Smartlikes is Mooncoin big 'secret weapon'. Currencies like LBRY are way ahead of youtube monetization via LBRY (+ LBRY platform) I think a good idea for the people behind Smartlikes to try to pull good ideas from similar projects that are flowing solidly. I told a few months ago that several crypto projects would be close to delivering everything Smartlikes promised, I see several projects delivering products identical to the initial Smartlikes proposal in the year 2020. Anyway, just wanted to explain this, Smartlikes leaves early this year. 2020 or if released after iso is at great risk of being just a copy of something that already exists. BTC and ETH has already given an example of how pioneering is important in cryptosphere. Merry Christmas and New Year for all Moon Bros.
Happy New Year, Mooncoin Community!
Thanks for MOON at Folgory exchange, thanks to small exchanges for listing MOON,
any feedback about Folgory and Thecoin.pw will be appreciated,
and special thanks to ChekaZ for his work, MoonWord, written from scratch in 2019.
SmartLikes will come in 2020 and they too will be absolutely new solution, not copy-paste of any existing tech.
From these posts you can see that ChekaZ started to work in September, 2019, it was transparently announced and supported by community members, in November and December of 2019 there was MoonWord release, positive reaction of community, no one was against it, there was a request for SmartLikes.
Edit:
there were so many false accusations and untrue statements during last pages of this thread, that it would take a lot of time to answer them all with providing each time a proof that they are false. Not to bring that all to a new thread, I will just edit this post, when I have time, in a neutral way, without unconfirmed statements, just with facts, proven with citations.
First of all, it was not me who started Mooncoin. The Mooncoin project was announced first by
deaconboogie on Dec, 28, 2013 and here is an original ANN thread
https://bitcointalk.org/index.php?topic=389403.0.
I am not a tech dev, I am not able to code in C,C+ and can read and understand the code only to a degree, after explanation. I was trying in the past to compile a wallet, but I don't know how to do it with no issues, basically I can say that I am not able to compile a wallet,I never was given any Mooncoin Github credentials, never coded, never released Mooncoin wallets at Github. I am not a miner, never mined even 1 Mooncoin, I am not familiar and not affiliated with admins of mining pools, exchanges, online wallets, block explorers.
The original Mooncoin code was audited in 2014-2015 by Titan, a dev of Luckycoin, after Dec, 2014 thefts. He did not find security issues in the code. Mooncoin was quite famous in 2014-2015, many tech persons kept an eye on it, no one reported security issues.
When the community
asked to start a new Mooncoin thread (the original ANN thread contained outdated info after an original dev left), my understanding was that Mooncoin code was secure (there was some concern about compiled binaries from original dev, that is why walletbuilders were asked to compile new binaries without any change of original code).
I always was asking Mooncoin devs to check it for security again and again.
Recently there was
a hint from mebagger2 that there were instructions to compile 0.13.9 wallet without auditing its code.
From my PMs to mebagger2 (sent to his previous account mebagger in Nov, 2017):
I'm not a coder unfortunately, just an investor.
Are you able to analyze the code to find possible vulnerabilities if any?
Can you please answer some questions:
1) are you able to implement direct mining from the wallet with one click, for average users which are not familiar with linux and rpc?
2) warp sync - can it have potential vulnerabilities, if not, why didn't Satoshi implement this simple solution to sync faster?
3) are you sure there are no known vulnerabilities in the new code?
can you please cite all Mooncoin addresses which are unspendable in the new release, and the part of the code?
Thank you!
Vassilis was also asked to make an audit.
From my PM to polemarhos888:
Hello,
yesterday I've sent a PM to Vasillis, to help with analyzing of barry's new release for possible vulnerabilities.
From my PM to Vassilis suggesting that he had to collaborate with Mebagger:
Does it mean I am saying that Mebagger built 0.13.9? No, the point is that 0.13.9 was a community thing, not only a dev thing. Someone found Vassilis, some members helped him with issues, someone was auditing the code, other people donated money to Vassilis. Not to blame Vassilis, either, but it is not fair to blame non tech members who donate money to devs and teams that they are responsible for their code after that.
The fork went really well. I'd love to take credit for that but I can't. James and Vas did a great job putting together a solid software update. We've been observed the hash rate fluctuating since the fork and the blocks are much more consistent than before even when large pools went into maintenance and significant hash power was lost.
In 2016 a dev barrysty1e came
on his own initiative (he definitely was not just a contractor like walletbuilders, but he really asked for donations from the community). He did a lot for Mooncoin, suggested and implemented some features (fast sync, Balloon hash, MoonRush, Moon SPV) on his own initiative, he was communicating at Bitcointalk and at Discord, was instructed by community members from Bitcointalk and Discord (I communicated with barrysty1e and connected him to community members who wanted to donate him, the same was when I communicated with Vassilis, a dev who came later again not just to compile a wallet or to code the feature, but as a new responsible Mooncoin dev to stay with Mooncoin over long term).
Everything was done with the consensus of community, and notonly with consensus, it was with full 100% or 99% consensus (only one person sometimes did not agree with some things, and Discord community members did not agree with Blue Moon logo, that is why barrysty1e used their own Mooncoin logo in the wallet release, though Bitcointalk community liked more Blue Moon logo, also I personally asked him to implement SmartLikes, but devs worked not on my individual instructions, otherwise SmartLikes could be implemented much earlier, at least in 2017). Though Vassilis really said he was going to implement SL in the future.
I was waiting and hoped that finally SL would be implemented. It was very interesting for me to see how this tech would work. When finally it was implemented by ChekaZ and Peter Bushnell in 2020! after many years and during all these years community members were asking for that, I was accused that it was done to compete with MooncoinCore team, and/or with other bad intentions. While during all these years I never stated that I was a leader, and my understanding always was that Mooncoin was and had to be community-driven with equal opportunities for all supporters, without any center.
Barrysty1e sometimes was blamed for his protection against move of stolen coins which did not work, however, if there were no protection at all, the situation would be the same in 2018, the problem was that coins were moved, if there were no protection, they would be moved as well, the situation would be just the same. The code was open source and any tech person could read it and suggest how to improve the protection, there were no suggestions. We believed it worked. However, the fact that the protection did not work and that on Jan, 2018 coins were moved to the address of Vassilis, which he transparently posted in his signature at Bitcointalk led to accusations and suspicions. Let's imagine there were no protection at all and coins were moved. There would be accusations as well obviously. So, the problem was not the protection itself, but the fact that these coins exist, that there is big quantity and that if they are removed from supply, it will be good for Mooncoin. My understanding is that rightful owners of these coins agreed to remove them out of supply (by the way, a major owner of these coins who agreed to lose them for the sake of community - agswinner was accused for his decision - that' he decides things').
It is possible to remove coins out of supply whether with coin lock (freeze, protection against unauthorised move which is not irreversible and can be removed with community decision in the future) or with coin burn (destroying the coins). Though initially, in 2018 I thought that coin burn would be better, now I don't support this idea until there is 100% warranty that there would not be any risks with it. Coin burn without a private key is a dangerous precedent, it can be safe technically, but it's not great for perception of blockchain, it affects the entire idea of blockchain.
A better solution probably could be coin lock. BTW, it was done in 0.18.1, with no luck, due to difference in consensus rules with 0.17 (which was released after 0.18) and due to an issue with locked transactions, derived from 0.13.9. Moreover, if even minor part of community does not agree with that, it is not a proper solution, things like coin lock require 100% consensus obviously or there could be accusations like it happened with 0.18.1. I confirm that I never sent to ANY dev OUTPUTS, INPUTS, TRANSACTIONS to lock, never knew and still don't know Michi's address. You never informed me about critical vulnerability in Mooncoin wallet before I told you at the beginning of Feb, 2020 that ChekaZ discovered it. Even when he released an optional wallet with MoonWord, based on 0.13.9, in Nov, 2019, no one warned that the 0.13 codebase (which was in use since 2017) was insecure. You may want to prove the opposite with a screenshot of messages, or remove false statements.
There was a request about transparency, here is chronology of events 2017-2020:
November-December, 2017
Barrysty1e is not active after completing like he promised Mooncoin wallet with Balloon hash instead of Scrypt. The wallet was not ideal though.
After polemarhos888 found a new dev, Vassilis, Vassilis created a new MooncoinCore Github to develop Mooncoin, mebagger2 advisedto use Scrypt instead of Balloon, that was inspired by him earlier and pre-announced by him when the new 0.13.9 release was ready.
If we did fork this coin for an algo change. I propose we keep scrpyt and add sha256 to make a multi algo coin. I don't think it's absolutely necessary but to change the algo. But if we did make that change it would allow mooncoin to continue trading in it's largest markets on the lightning network, BTC/MOON, LTC/MOON, DOGE/MOON.
This is also another reason why we should not change our algo for an obscure algo like ballonhash.
I did help connect Vassilis with the community (however, Vassilis was 'my' or 'our' dev not more than Mich i or Mebagger) and it was one of the best periods in Mooncoin history when a dev and Mooncoin community worked together.
There were issues with 0.13.9 and Vassilis worked to fix them, with help of community members:
I just fixed today the pool mining section and the transaction issues..
we passed "key" block #1180751 with 73(?!?!?!!??!) transactions! Few more tests and tomorrow i will inform all the pools to make an update!
I must thank public @mebagger, @coinflow, @GBLASS and @Laidback!
you guys spent your time with me and your resources!
Thank you for your contribution to the Mooncoin community!
Jan, 5, 2018, there was a tragic day in Mooncoin history,
62B were sent to Vassillis to the address he posted at Bitcointalk, protection did not stop it. There is a detailed research:
https://bitcointalk.org/index.php?topic=1733963.msg38039860#msg38039860Coins from 'locked' addresses were movedto other addressesfor the first time on March, 3 - in 2017, months before Vassilis came as a dev. Now we know that barrysty1e's protection was not in the consensus rules.
The community voted to burn these coins, I also believed that coins had to be burned and suggested that coins had whether to be sent to a burn address, or to stay on their address (even if Vassilis would send coins to authorities, there could be a panic that coins were moved, also taking into account possible PC security issues, a safer solution in that case would be to move a hard disk with coins, and not coins from one address to another, to do it without even opening and syncing the wallet) some people talked about legal issues with coin burn, Vassillis decided to consult with lawyers what to do with coins and to burn no coins until he is sure there will be no legal issues and to leave Bitcointalk and development. I was never informed that anyone, except Vassilis, got an access to these coins, physical or non-physical.
After leaving development, months later, Vassillis gave MooncoinCore Github credentials to polemarhos888, a Mooncoin volunteer and investor, who found Vassillis before, and on June 7, 2018 polemarhos888 informed me via PM that he had sent these credentials of MooncoinCore Github to Mebagger.
I am pleased to announce that I will be working with the new Mooncoin team replacing Vas to maintain and deliver new features in the mooncoin core wallet (
https://github.com/mooncoincore/wallet).
On Jun, 11, 2018 I have sent to mebagger2 through PM a detailed description of SmartLikes technology to implement it.
On April, 9, 2019 ChekaZ spoke to me for the first time and asked if we would like to implement Mooncoin integration into coinkit.de.
From my PM to mebagger2 on Jun, 10, 2019, after I was told about possible move of Mooncoin to Proof-of-Stake algo:
Thank you for your reply.
About change to PoS - in my opinion, would be better first to discuss it with the community, as for me personally - don't support it, in my opinion better would be to raise network hashrate with interesting projects
On September, 6, 2019 I asked Mebagger if he planned any release in 2019.
Maybe you know why CE doesn't enable their MOON wallet? Have they lost coins again and if yes, how many?
And do you plan to make any MOON release in 2019?
Received no answer and ChekaZ was asked to build an optional (not fork) wallet with MoonWord functionality.
After the serious vulnerability was discovered and reported by ChekaZ, it required a security fix and update at pools and exchanges immediately.
https://bitcointalk.org/index.php?topic=1733963.msg53878855#msg53878855 (ChekaZ, CoinKit Founder)
https://bitcointalk.org/index.php?topic=1733963.msg53882057#msg53882057 (Peter Bushnell, Feathercoin founder explains)
From my PMs to ChekaZ regarding mebagger2:
It is important to have him on board. You can tell him that the frozen address feature requires a fork for better protection. Even that is enough argument for the fork.
I suggest first to receive kind of green light from him, and only then post a Github link in the ANN and start to contact services to update. It is important to avoid the split in the community
ChekaZ and Mebagger2 discussed things, however, ChekaZ told me that he did not see 0.17 release and did not know what was in it exactly, and that Mebagger was not qualified and that Mebagger suggested an unsafe solution, with chain split and that we had to fix vulnerability fast with a solution from Peter Bushnell with the fork block.
From my PMs to mebagger2 regarding coin LOCK and release of 0.18.1
It is possible to freeze coins if the owner of address will not organise 51 attack to hack the protection.
I also clearly stated to Mebagger, that it is not about any competition, and only about fix of vulnerability and adding other features, requested by the community earlier. Why I did not contact Michi, my understanding was that she was involved with Dogecoin and simply had no time to code Mooncoin wallet, that Mebagger is the only relevant person, responsible for Mooncoin Github and coding since 2018 (though nothing was released then after 0.13.9 by Vassilis), anyway. Logically, if Michi was involved, she would know from Mebagger about so important collaboration.
After this update you will continue, and I will be calm and will not focus on wallet updates.
We can discuss all points to reach consensus. You are not only part of Taranis new team, but also part of this community since 2014.
Though ChekaZ told me that we had to avoid disclosuring it to anyone before the update, I believe that we have to disclosure it to you, at least to avoid misunderstanding and possible disagreement regarding the fork.
Several days ago ChekaZ told me that he found a very serious vulnerability in the code, related to [removed ]. He explained it to me and it is so serious that without the fork the risk is absolute. It is needed to restore block validation with the hard fork. I told him that it would be better to collaborate with you and you began to communicate regarding the update.
However, there is a big problem. If we announce this vulnerability, bad guys could use that before the hard fork block height. Even when services update their clients, it can be some leak of info.
To avoid that we can just try to drive no attention to the fact that this vulnerability will be fixed in the new release, and simply announce that we move to a safer 0.18 (it was well tested with Bitcoin network) and with SL feature (we just have no moral right to delay it further, the community waits for it since 2017 and this feature will help increase network hashrate, also it is good timing, not to update twice). Thus, all attention will be focused on Likes and it will be clear for services why we update. One more feature which is present in ChekaZ release, the 1st address will be frozen, I understand that this solution is not 100%, but it is better than nothing. Also if you have another, more effective solution how to remove these coins out of supply (while burn looks unreal), we can certainly use your solution.
That is the situation and the most dangerous thing is leak of info regarding the vulnerability, also we have to reach consensus to avoid split of community regarding the fork, and we have to update quite fast to reduce risks. ChekaZ is fully responsible for the release and there will be his warranty that it will be proper hardfork technically and that the vulnerability will be completely fixed. The 2nd set of eyes (your audit) will also help, and likely we will understand better each other now and will be able to solve this issue in the best way.
Why I was saying to Mebagger only about the 1st address to freeze, and didn't mention 2 other addresses from Dec, 2014 thefts? It is important to understand and it can be verified that those 2 addresses were locked in 0.10.5 and in 0.13.9, which was a current version then, I was sure it was known, these 2 adrresses were already locked years ago and there was nothing to discuss, while the 1st address with 62B was in question.
Why I was saying to Mebagger that coin burn looks unreal, my understanding was that there was no tech possibility to burn coins with no private key, I asked Mebagger about it before, received no answer, even if it's possible to do it safe technically (it's uncommon thing), anyway it's obvious it's extremely bad for perception of blockchain. To say nothing of possible legal risks, reported by some supporters, it is necessary to consult with lawyers first, if you are involved with coin burn.
Do you agree with 13 Feb hard fork height? 10 days from now.
If we come with no discord about the fork, it looks it will be enough time to update clients. There are about 15 services, including exchanges, pools, block explorers and online wallets. ChekaZ agreed to contact them, and many services know him well, so there will be no problem, especially if you also support the update. I can announce it in next 1-2 days after you will have a look at the code. Only my worry that ChekaZ will not fork your code because he told me that he should be fully sure in the code to take responsibility for it and he will need too much time to audit and rewrite everything onto your codebase. We can trust him at least because he reported vulnerability to us and did not use it. And we must act fast. Maybe you will just audit his code and focus his attention on something important if it needs to be added, and after that we begin to update and he takes full responsibility for the fork?
I told ChekaZ to make stress tests, of course, he already tested everything on the testnet, but you are right, it should be done very carefully, not in a hurry. So he will work additionally until Thursday when you will return, and then you will be able to audit his code.
Yes, we agree that services must update first. However, services will look for kind of announcement to confirm that this update is legitimate, also our community, users have to be ready to update their clients to avoid issues with their transactions. I suggest that we dont mention security issues at all, anywhere, but announce it as 0.18 with SL, and first announce the news itself, and only after services update, announce the links to the client. Users will have not much time to update before the hard fork block, and we should tell them in advance about mandatory update.
Does Taranis know about the vulnerability? Would there be any discord from his side, or he understands the situation?
This was not answered, Mebagger stopped answering to me, the fork block was moved to Feb, 22 from Feb, 17, ChekaZ recompiled Mac, Windows, Linux binaries with a new fork block, after that we could not delay any longer the vulnerability fix. Moreover, ChekaZ told me that Mebagger did not understand the problem, that he suggested a solution which could be dangerous for Mooncoin chain.
However, much later after the release of 0.17 (by MooncoinCore team) ChekaZ told me that Peter Bushnell reviewed the 0.17 code and it's okay. From their side, MooncoinCore team told that 0.18 is insecure, that it restored validation, but did not restore historical validation which is important for blocks before the fork block. From comments of ChekaZ and Peter (Feathercoin founder) everything was explained:
1. Real vulnerability was lack of validation, historical validation related to blocks before the fork block was not so dangerous, and could be restored without a new fork and with no difference in consensus rules, just with one more update which they planned to do, but only after the update to 0.18 and AFTER the fork block to avoid the situation with split of chain with 0.13.9, a previous version, which had this vulnerability and was present at exchanges and pools since 2018 (adding historical validation feature immediately and not after the fork block would cause a split of chain).
2. 0.17 was released after 0.18, but about 3 days before the fork block of 0.18 (which happened on Feb,22).
0.17 did not implement any fork block. Due to that and due to invalid blocks, 0.17 instantly forked, creating a separate chain away from 0.13 and 0.18. That happened before 0.18 got majority of hashrate at pools.
They released Version 0.17.1 and it instantly forked due to introducing new consensus rules without doing so via a set block height. There is no 51% attack ongoing, the chain just split cause of their 0.17.1 release as it declines all 0.13 and 0.18 nodes.
We want a single chain after all the dust has settled, 0.17 has already broken consensus with 0.13, which is why you do not restore consensus breaking validation without doing so at a set height so everyone can upgrade in good time.
3. It was important to be on one chain and get more chainwork to be sure that 0.13.9 with vulnerability is no longer main version, but at the same time follows a main chain. Pools and exchanges updated to 0.18 before launch of 0.17. It was recommended to mine 0.18 and not old 0.13, to move hashpower from the insecure 0.13 version to 0.18.
Greetings all. Altilly is currently running on v18 as the v17 consensus had some issues. At this time it seems v18 is the most stable chain.
4. Then, on March, 1 - 0.17 supporters used about 1,000 Ghs to mine 0.17,
https://i.imgur.com/uJVhR8i_d.jpg?maxwidth=5000As how it looks of now, the developers of 0.17 mined alone on the " mebagger.webhop.net" pool, rented hashrate and tried to over-mine the pools/miners on 0.18 - They've rented up to 1TH/s to be the chain with the most chainwork and did a chain-reorg ( invalidated the last 10k~ blocks ).
as a result 0.13.9 joined 0.17, but due to that 0.18 was left alone on a separate chain, because it had coin lock (frozen address feature) in the consensus, while 0.17 removed all protection (they told they were going to burn coins later, and accused that frozen address feature was implemented with bad intentions, but if they would make a new wallet with coin burn, they could easily remove frozen address feature in the new wallet, so what's the point? 0.18 only tried to add additional, though not 100% protection, while 0.17 does not have protection against unauthorised move of coins at all).
5. It turned out that 0.18 had an issue with locked transactions, derived from 0.13.9, it could be fixed with the fork, and historical validation could be added as well, like it was planned, however, one more fork would not be a good solution, especially in the atmosphere of misunderstanding, suspicions and accusations. Also followers of 0.17 could lose their coins by using a wallet on a separate chain.
To avoid split of community and mess with separate chains .17 was chosen:
https://bitcointalk.org/index.php?topic=1733963.msg54050237#msg54050237However, both 0.17 and 0.18 were not ideally presented.
During 2 years after Mebagger came as a dev, we all were waiting for him and were thinking that there was ongoing development. And after 2 years why not listen to experts, if ChekaZ and Peter Bushnell were happy to assist.
To be fair, Mebagger was answering my messages and questions, especially before 2019 as I can see now from my PM history when doing the research. I don't know what exactly happened between him and ChekaZ, looks like it was a conflict due to disagreement about how to better fix the vulnerability.
I tried to work with the old devs, but they refused at some point and said that they were working for such a long time now on the 0.17 release.
I did share the codebase ( 0.18.1.L ) beforehand with them, they could review it and leave comments/suggestions. They on their end, never shared the 0.17 code. As they stopped answering DMs, we decided to move ahead, lay out the plans and plan the fork accordingly.
ChekaZ gave to Mebagger an opportunity to audit the code before the release (here is a proof, provided by ChekaZ:
https://i.imgur.com/Dt9pCNF_d.jpg?maxwidth=640&shape=thumb&fidelity=medium ), my understanding is that the code is open source and even if it is in public repo, not private one, it can be audited, commited, all issues could be reported before the update of wallet at pools and exchanges.
However, there was no answering, no reaction after Feb, 6, then, when pools and exchanges updated to 0.18 as it was not too much time left to the fork block (which was expected on Feb, 22), on Feb, 19, the 0.17 was released and after that all this flow of false accusations started, not only against me, and that had to be answered.
What did we do? We fixed the issue fully without announcing it until the fixed version was on a mining pool. What did you do? Announce the security issue and not fix it in a competing version and pushed it on mining pools and exchanges. I don't know why you did this reckless action but I did request that you build your new features on our base.
You did ask to build features on top of 0.17, but it was before I told you that ChekaZ found the vulnerability. ChekaZ told you did not show the 0.17 code to him before the release. There was no proof (except talks and empty promises since 2018) that the 0.17 release was almost ready.
Now 1-2 days before the HardFork takes place, the old devs release a Version without ANY commit history. The Repository has 20 commits, the commits aren't labeld or easily reviewable. Changes werent commited properly, so the commits are just a cluster of old and new code.
Now the 0.17 version does introduces new consensus rules, the problem is they didnt do it via a set block height, which you would normally do if you introduce something new regarding the consensus ( HardFork ). - The Problem here is that the 0.17 version instantly refuses the 0.13 & 0.18 clients which lead to a split of the Blockchain.
In your PM on Feb, 3 you said that as long as the vulnerability is fixed you're 'totally in agreement' with us, and in your PM from Feb, 4 you agreed with a hard fork 'to push older clients off the network', and even advised how to present 0.18 version:
My personally if the code is right I wouldn't make a general announcement of the new release. I would get the exchanges and miners upgraded first as much of the security updates would not required a fork block to take effect. But a fork block would help push older clients off the network and make the changes more clear. So in short more than a day of review is probably needed.
Maybe that is the point of different understanding of situation:
So as the problem was there from the start and for years and years no one 'mine the total supply of MOON with low difficulty', why would that suddenly change?
ChekaZ informed me in Jan, 2020 about the vulnerability and that it was there for years, and luckily there was no attack, but if you know about it and how dangerous it is, the only way is to fix it immediately, if we care about people, about the project. No other way.
You did not inform me about the vulnerability when you discovered it in 2019 or earlier, and did not fix it before 2020.
And in 2020 after Chekaz reported it, at least several persons knew about it, and there was no 100% privacy of communication. Any delay with the release would not be good. The vulnerability was fixed in 0.18 according to 2 -step solution (to avoid split of chain) from Peter Bushnell and ChekaZ before updating at pools and exchanges.
My understanding is that you did not like the fact that those experts (they were independent experts, the solution was suggested, designed and implemented by them without any advice from us) did not approve your solution which you discussed with ChekaZ, and that you wanted to deliver finally your wallet, no matter with the split of chain or not, while Taranis (as it looked from his posts in March) thought in terms of competition
and did not accept that it would look like after 2 years his team did not provide a secure wallet, while another dev (ChekaZ) did it. Meanwhile we were waiting for your 'green light' for 0.18.
On Feb, 9 you received the 0.18 code for review from ChekaZ (
https://i.imgur.com/Dt9pCNF_d.jpg?maxwidth=640&shape=thumb&fidelity=medium), you were informed about its main features in advance though.
Finally after several days of no collaboration from you (it looked like the irrational delay was not due to your review, but due to disagreement from Taranis who didn't understand all risks of vulnerability and risk of chain split with your solution, though ChekaZ said he tried to explain that to him before the release,
finally we decided to make a step, there was an upcoming fork block, the vulnerability had to be fixed immediately and with a safe solution, recommended and provided by the experts. The 2-step solution (1st step, restoring validation with the fork block to let people safely update, 2nd step restoring historical validation without split of chain) turned out to be an ideal target for accusations, as soon as the 1st step is done it is so easy and effective to accuse that the version is 'insecure', 'incomplete', while another version is fully secure (with a split of chain though).
I know .18 is insecure. There is a secure release available .17.
You understood that we were going to fix the vulnerability asap and that there was upcoming fork block in the code (ChekaZ even changed it, waiting for you and recompiled all binaries, including Mac, Linux), but to avoid a leak of information about the vulnerability it would not be a good decision to delay the release and change the fork block again and again.
What could you do if you didn't agree with the version: to inform me about your concerns, to send a list of issues to me or to ChekaZ, to post at Bitcointalk your disagreement after posts from ChekaZ and me about the upcoming release (those posts did not announce vulnerability), to agree with experts, with their 2-step solution. What you did: you stopped communicating with me after my question:
Does Taranis know about the vulnerability? Would there be any discord from his side, or he understands the situation?
and only on Feb, 19 you suddenly released 0.17, after 0.18 was adopted by pools, and just as experts warned, your solution without setting a fork block height, without 2 steps led to the split of chain and mess. And after that 0.18 was accused of the mess.
Another accusation was that SmartLikes was implemented with monetary interests.
Community members had been asking and waiting for SL since 2017 or even earlier very actively, with numerous posts. And the entire idea of technology is 'likes'-based system, Mooncoin for Mooncoin, which is rather non-monetary as it could work even if Mooncoin would have no markets at all.
Dogecoin and Elon Musk won't care about Mooncoin.
The project has to create its own value and not hope for someone else, rich and famous.
I don't see another way to defend ideas of SL and the truth, now I must stop my support for SmartLikes, until accusations of 'monetary' interests are deleted and until the community confirms that SmartLikes is implemented on request of the entire community.
For more information please read this post:
https://bitcointalk.org/index.php?topic=1733963.msg53974582#msg53974582Competing teams is a myth, there never was a Bitcointalk team, there is Bitcointalk community, not team.
The absurdity of idea that it was about 'competition', all know that we always were saying 'You are welcome' to devs and teams who were going to develop Mooncoin, added information about them to Bitcointalk topic (try it with another famous coin, and you'll see the difference) though when devs did not care about the project for long time and there were serious risks for users, exchange, pools, there was no choice.
It was necessary to fix vulnerability asap, after all, it is fixed now. That could be done in a much better way, if there were more communicating and less suspicions and accusations.
