[MOON] Mooncoin 🌙 Proof-of-Work, launched in 2013

[bctmanilla]

I saw that there was an announcement about a new .18 client release that offered some network security and new features. So I got curious and started looking into the previous mooncoin releases.

https://github.com/realmooncoin/mooncoin  --> this version doesn't validate blocks - "who released this?"
https://github.com/mooncoindev/mooncoin   --> this version doesn't validate blocks - "who released this?"
https://github.com/mooncoincore/wallet/releases/tag/0.13.9-segwit-b257fcd --> this version doesn't validate blocks  - "who released this?"
https://github.com/mooncoincore/wallet/tree/v0.17.1.0  --> this version validates the full block chain and purges the network of invalid blocks - "who released this?"
https://github.com/MooncoinCommunity/wallet  --> this version validates blocks after 1801000 and removes the standard consensus rules that are inplace to protect the chain and transactions (validation.h: static const int64_t DEFAULT_MAX_TIP_AGE = 90 * 24 * 60 * 60;) (net_processing.cpp: return g_last_tip_update < GetTime() - consensusParams.nPowTargetSpacing * 20 && mapBlocksInFlight.empty() - "who released this?"

So it makes me curious, why do miners and exchanges prefer insecure wallets? It seems that the only secure wallet ever offered to the mooncoin community is being rejected by miners and exchanges. As this coin's community seems to prefer to not secure transactions through consensus consensus rules, how are chain transactions secured? Before purchasing mooncoin do we make a donation to the mooncoin_foundation? How much is the going rate for 'protection' and how many transactions are covered?

0.18.1 was a paid job by Mooncoin_Foundation to fix the Blockchain of its previous "doesn't validate blocks issue" & develop "LIKES" as a feature - It got designed to be compatible with 0.13.9 and fix these issues on a set Blockheight 1801000 which ensures that nobody is left behind or on a fork upon the release. 0.18.1 does validate the new Blocks but lacks of historical validation as this would have lead to a fork. - 0.17 did this and forked away alone as it wasnt compatible with the previous version 0.13.9.

Historical validation should be added to 0.18.1 but wasnt directly necessary or doable without breaking the consensus instantly. Validation has been restored on the 0.18.1 Client and a fully validating 0.18.1 version can be released.

As 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 ).

I think these question was about the .18 build to the people that built and maintain the .18 version nothing to do with .17 or .13. The people that built the .17 and .13 versions can answer questions about those versions.

why was this consensus value changed to 3 months from a default of 24 hours and was not dependant on the "fork" block height?
(validation.h: static const int64_t DEFAULT_MAX_TIP_AGE = 90 * 24 * 60 * 60;)

why was this consensus value changed to 20 blocks from a default of 3 blocks and was not dependant on the "fork" block height?
(net_processing.cpp: return g_last_tip_update < GetTime() - consensusParams.nPowTargetSpacing * 20 && mapBlocksInFlight.empty() )

[1715347153]

1715347153

[1715347153]

1715347153

[1715347153]

1715347153

[1715347153]

1715347153

[1715347153]

1715347153

[bushstar]

I think these question was about the .18 build to the people that built and maintain the .18 version nothing to do with .17 or .13. The people that built the .17 and .13 versions can answer questions about those versions.

why was this consensus value changed to 3 months from a default of 24 hours and was not dependant on the "fork" block height?
(validation.h: static const int64_t DEFAULT_MAX_TIP_AGE = 90 * 24 * 60 * 60;)

why was this consensus value changed to 20 blocks from a default of 3 blocks and was not dependant on the "fork" block height?
(net_processing.cpp: return g_last_tip_update < GetTime() - consensusParams.nPowTargetSpacing * 20 && mapBlocksInFlight.empty() )

Thought my work was complete on Moon but I keep being pulled back in!

Code:

int64_t DEFAULT_MAX_TIP_AGE = 90 * 24 * 60 * 60;

This was set in the 0.13 client, seemed very old to me but I set it verbatim as I did not consider it my place to judge at that point. Should have revisited this after discovering that 0.13 also hacked out large portions of block validation. This plays a part in IsInitialBlockDownload, once block sync is 90 days old from the current time it will no longer be considered the "initial block download". This can be changed to 24 hours or whatever people consider suitable for Moon.

Code:

(net_processing.cpp: return g_last_tip_update < GetTime() - consensusParams.nPowTargetSpacing * 20 && mapBlocksInFlight.empty() )

If this was left at 3 then 0.18 would have considered nodes as stale after 4.5 minutes. Bitcoin's setting of 3 is 3 * 10 minutes, so it takes 30 minutes of no blocks being sent for a node to be considered "stale". 20 is then the same for Moon, 20 * 1.5 = 30, so tips are considered "stale" after 30 minutes same as Bitcoin.

[bctmanilla]

I think these question was about the .18 build to the people that built and maintain the .18 version nothing to do with .17 or .13. The people that built the .17 and .13 versions can answer questions about those versions.

why was this consensus value changed to 3 months from a default of 24 hours and was not dependant on the "fork" block height?
(validation.h: static const int64_t DEFAULT_MAX_TIP_AGE = 90 * 24 * 60 * 60;)

why was this consensus value changed to 20 blocks from a default of 3 blocks and was not dependant on the "fork" block height?
(net_processing.cpp: return g_last_tip_update < GetTime() - consensusParams.nPowTargetSpacing * 20 && mapBlocksInFlight.empty() )

Thought my work was complete on Moon but I keep being pulled back in!

Code:

int64_t DEFAULT_MAX_TIP_AGE = 90 * 24 * 60 * 60;

This was set in the 0.13 client, seemed very old to me but I set it verbatim as I did not consider it my place to judge at that point. Should have revisited this after discovering that 0.13 also hacked out large portions of block validation. This plays a part in IsInitialBlockDownload, once block sync is 90 days old from the current time it will no longer be considered the "initial block download". This can be changed to 24 hours or whatever people consider suitable for Moon.

Code:

(net_processing.cpp: return g_last_tip_update < GetTime() - consensusParams.nPowTargetSpacing * 20 && mapBlocksInFlight.empty() )

If this was left at 3 then 0.18 would have considered nodes as stale after 4.5 minutes. Bitcoin's setting of 3 is 3 * 10 minutes, so it takes 30 minutes of no blocks being sent for a node to be considered "stale". 20 is then the same for Moon, 20 * 1.5 = 30, so tips are considered "stale" after 30 minutes same as Bitcoin.

It seems there is something wrong with the forbidtx list.

This makes sense:
2QovBjnVke4fgn9UXdz9osheNLxQCk3d8R --> https://chainz.cryptoid.info/moon/address.dws?846906.htm
1278 transactions


This does not make sense:
Old wallets with large balances? Why are they included? both from 2014 one of these wallets is from a dev that created the .17 wallet. Is this some personal attack?
2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK --> https://chainz.cryptoid.info/moon/address.dws?2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK.htm
24 transactions

2JA3Cqf9on8YuxngxdXStCFKanAGnaQU5A --> https://chainz.cryptoid.info/moon/address.dws?2JA3Cqf9on8YuxngxdXStCFKanAGnaQU5A.htm
71 transactions

Even then the total count of transactions is wrong. the count of transactions from the validation.cpp is 1386 ... but the count of transactions from the three wallet addresses from chainz.cryptoid.info is
1,373‬.

[michi]

So I've been avoiding posting here because of the politics and not wanting to get into the fray. But it looks like our heroes have dragged me in one way or another.

I'm Michi, and I've been a core Dogecoin developer for years; and I, on a volunteer basis, became one of the lead "volunteer side" mooncoin devs about two years ago when I built the mac wallet, which the community was in need of.

I currently fill the role of lead developer of the Mooncoin Core team, which obviously now differs from what I'll call the "Mooncoin CEO Team" which includes Mooncoin_Foundation (an individual, not a foundation), AGSWinner, and their hired contractor, ChekaZ, who subcontracted Peter Bushnell (Bushstar) of Feathercoin fame.

-----

Recently I've been working with Mebagger on work leading up to 0.17; I've received no pay for my work in the last two years - unlike ChekaZ, who is a contract hired gun; but it looks like no good deed goes unpunished.

My question is this:

Mooncoin_Foundation, ChekaZ:  

Is there a reason why on Feb. 7, in a commit for the 0.18 build, changes are made to 0.18 (before its release) to block *my personal wallet* along with the 62 billion mooncoin?

The only contact you, MF, have had with my wallet, is when you paid me the princely sum of 500,000 mooncoin (Back then around USD $12,  now about USD $6) as a "thank you" for completing the Mac wallet. Little did I know that that payment would come with my wallet being on a banlist later on.  I would have refused that if so, bringing the total amount of pay I've gotten for working on the Mooncoin project down from $12 USD to $0.00.

This seems like a vindictive action. I want to know why.  

Can you, ChekaZ and Peter Bushnell explain why my personal wallet was added to 0.18's block/forbidden list, along to the 62 billion coins - with no explanation?

Bushnell, you made the commit that added the ban. Who gave you the list of txids to ban?  That wasn't explained in the commit on Feb. 7; the txid was simply...included, when it wasn't before.


https://github.com/MooncoinCommunity/wallet/commit/c9c275d85aef837f612e86db1e69e175de528f8d#diff-25d902c24283ab8cfbac54dfa101ad31


I understand that due to the magic of concensus, the Mooncoin "community" has "decided" on 0.18 because of MF and ChekaZ' marketing tactics, the inclusion of a few "features" (Smart Likes and Moon Word) which don't actually *do anything* yet; seemingly bread and circuses.

But I'd really like to know the rationale for the 0.18 "team" adding other devs' personal wallets to the block list, surrepetitiously?

I half expect something vague and nebulous from M_F's sycophants along the lines of "Well if they froze your wallet, they must have a reason!" - Sorry, nah, this will not do. I want to know the rationale that lead to the decision. Otherwise you guys are lacking transparency.

Bushstar - if the ban list didn't come from M_F or ChekaZ, who *did* it come from?

ChekaZ, Mooncoin_Foundation - what's your rationale for adding my wallet to the list?

... Furthermore, If you're running 0.18 and ChekaZ/MF's builds, and MF and crew decide they don't like you ... will they freeze your wallet, too?

[ChekaZ]

Hi Michi!

As you correctly said, it was a paid job, we got this list of addresses from Mooncoin_Foundation with the following tags:

We have 3 addresses to block :
2QovBjnVke4fgn9UXdz9osheNLxQCk3d8R (the 1st one with 62B)
2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK (Dec, 2014 thefts)
2JA3Cqf9on8YuxngxdXStCFKanAGnaQU5A (Dec, 2014 thefts)

These addresses with their corresponding tx'es got included into the consensus protection by Peter.

Neither Peter nor me have any personal opinion on these blocked Funds, we just got the list.

[michi]

It's interesting then that my wallet's inputs are in that list.  I also am not sure why you guys would add a ban list sight-unseen without any rationale from the people giving it to you whatsoever?

I thought our concern was the stolen Cryptsy-based 62 billion coins; not a couple collections of "mystery transactions" without any explanation as to their source.

I'd like to note that the only reason we discovered this ban/freeze was that we were in the process of working on ways to make 0.17 and 0.18 interoperate, to bring everyone back to one chain and solve this current dilemma and move forward. It was odd when test transactions from me started being mysteriously rejected by 0.18.  We looked at a lot of things, but honestly my wallet being on the ban list was one of the last things we figured would be the case.

I should add that I feel this is one of the dangers of unaffiliated developers doing the behest of "a guy", (even if that guy calls himself a foundation.) - and the problem with a "bounty list" development model. There was no community stake here. Just a person telling a hired developer to add a txid to a banlist. No questions were asked, it seemed; and now that wallet is widely adopted, my mooncoins are immovable. Any txid could have been on that list, and it wouldn't have been vetted.

This isn't how consensus is supposed to work.

I certainly had nothing to do with Cryptsy or any thefts.  My wallet has very few transactions in it at all; the vast majority being Moon that I mined back in the Deaconboogie days. (I've been involved in Mooncoin going back to January 2014.)   I *lost* Mooncoin to Cryptsy, I didn't gain it. (And those transactions bear it out, too.)

But for example;  here we have a blocked transaction in 0.18.

Code:

020-03-04T18:20:49Z tx: CTransaction(hash=fdc42f37a1, ver=2, vin.size=2, vout.size=2, nLockTime=1808773)
    CTxIn(COutPoint(23f1ade1a9, 763), scriptSig=473044022027ec0f8dbd2eb9, nSequence=4294967294)
    CTxIn(COutPoint(ebc527bc00, 1), scriptSig=473044022063249c2b3207d3, nSequence=4294967294)
    CScriptWitness()
    CScriptWitness()
    CTxOut(nValue=1.00000000, scriptPubKey=76a914331239adb02567181be42742)
    CTxOut(nValue=0.01097187, scriptPubKey=a914eb3614bc94909a809ea2a7a884)
 has triggered forbiddentx alert (n=23f1ade1a9, txdebug=101)

n=23f1ade1a9

80 bits. 80 bits from the 0.18 ban list added in the Feb 7 commit: https://github.com/MooncoinCommunity/wallet/commit/c9c275d85aef837f612e86db1e69e175de528f8d#diff-25d902c24283ab8cfbac54dfa101ad31.
(Note I haven't scoured all of my transactions so this isn't exhaustive. This is one example.)

https://imgur.com/a/eBYGt1D

This transaction leads to my wallet:

https://imgur.com/adxHgnR


As I've said I haven't been paid for doing any work on Mooncoin, except for the 500k MOON that Moocoin_Foundation sent to me on 3/18/2018 (Along with a list of expectations, by the way) for building the Mac wallet back then.   The only other transactions between then and now in my wallet have been 1 MOON test transactions for development purposes; going to and from my own test wallets.

Meaning: The only person who has had exposure to my personal Mooncoin wallet is Mooncoin_Foundation.

The only other possible explanation for my wallet's input txids ending up in the banlist is literally, a *minimum* of 80-bits of coincidence.

While that's possible, realistically, it isn't.

[Mooncoin_Foundation]

Michi, this address was blocked in 0.10.5 in 2016 when a dev was barrysty1e. So, it was nothing new in 0.18. I will look for history of posts at Bitcointalk and prove it.
Also, I never sent coins to you. Maybe it was agswinner who did it in 2018.

Edit: and in 0.13.9 by Vas in 2017 again this address is locked. Only coins from these 3 addresses, posted by ChekaZ, were locked whenever in Mooncoin history, so again nothing new.

Michi, can you please post your address and why have you decided that it does not work? Have you tried to send coins from it?

You can easily look at Github history of 0.10.5 and 0.13.9 wallets to have a proof that these addresses were locked in 2016 and again in 2017, when you were not close to Mooncoin development.
By the way, the problem with validation (security issue) was also present in 0.10.5, not only in 0.13.9.

[agswinner]

The December 2014 hacker attack

https://bitcointalk.org/index.php?topic=389403.8660

"On the 15th EVERYTHING has been stolen. The hacker's wallet is 2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK. He has over 6 billion moon. Presumably all stolen...."

[Mooncoin_Foundation]

Found something:

Additionally; the new client prevents sends from accounts containing funds known to be stolen.

Can someone help me discover who owns 2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK?
He has all my billion mooncoins.

Please compare this address and one which is in question now:

This does not make sense:
Old wallets with large balances? Why are they included? both from 2014 one of these wallets is from a dev that created the .17 wallet. Is this some personal attack?
2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK --> https://chainz.cryptoid.info/moon/address.dws?2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK.htm
24 transactions

Anyway thank you, Michi and btcmanilla that you started to discuss things at Bitcointalk. It is a good sign and there is nothing to hide in 0.18, all questions can be answered transparently.

[Taranis67]

Hi Michi!

As you correctly said, it was a paid job, we got this list of addresses from Mooncoin_Foundation with the following tags:

We have 3 addresses to block :
2QovBjnVke4fgn9UXdz9osheNLxQCk3d8R (the 1st one with 62B)
2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK (Dec, 2014 thefts)
2JA3Cqf9on8YuxngxdXStCFKanAGnaQU5A (Dec, 2014 thefts)

These addresses with their corresponding tx'es got included into the consensus protection by Peter.

Neither Peter nor me have any personal opinion on these blocked Funds, we just got the list.

Wait, you blocked wallet addresses on the say so of one person?

Exactly how many wallets did you block, was it 3 or more than that?

[Mooncoin_Foundation]

Your question was to ChekaZ, let him answer.
I have a question to you, to get better understanding of situation. Did you know about the vulnerability in the 0.13 Mooncoin wallet before ChekaZ released .18?

[Taranis67]

Your question was to ChekaZ, let him answer.
I have a question to you, to get better understanding of situation. Did you know about the vulnerability in the 0.13 Mooncoin wallet before ChekaZ released .18?

Yes I did.

[Mooncoin_Foundation]

Your question was to ChekaZ, let him answer.
I have a question to you, to get better understanding of situation. Did you know about the vulnerability in the 0.13 Mooncoin wallet before ChekaZ released .18?

Yes I did.

Were you informed about it by ChekaZ , by Michi or by mebagger2 and when?

Edit: when exactly and by whom were you informed?

[Taranis67]

Your question was to ChekaZ, let him answer.
I have a question to you, to get better understanding of situation. Did you know about the vulnerability in the 0.13 Mooncoin wallet before ChekaZ released .18?

Yes I did.

Were you informed about it by ChekaZ , by Michi or by mebagger2 and when?

Before you paid Chekaz to do your work.

[Mooncoin_Foundation]

You probably know that we contacted mebagger2 before the release and he was auditing it, so-called 'my work' was discussed with him and with other members of community who donated money for ChekaZ,
Edit:the release contained nothing the community did not come to the consensus about, it is all about details, in this or another way to implement it, and misunderstanding,
if you answer my question, from whom and when exactly you knew about the vulnerability, it will be really more understanding.

[Taranis67]

You probably know that we contacted mebagger2 before the release and he was auditing it, so-called 'my work' was discussed with him and with other members of community who donated money for ChekaZ,
Edit:the release contained nothing the community did not come to the consensus about, it is all about details, in this or another way to implement it, and misunderstanding,
if you answer my question, from whom and when exactly you knew about the vulnerability, it will be really more understanding.

I have already answered.

I don't have the exact date because the discussion was over a long period. From knowing there were vulnerabilities...we ALL knew that (remember when we fixed the problem with CoinExchange?) to discussing options of how to fix.

[Mooncoin_Foundation]

You probably know that we contacted mebagger2 before the release and he was auditing it, so-called 'my work' was discussed with him and with other members of community who donated money for ChekaZ,
Edit:the release contained nothing the community did not come to the consensus about, it is all about details, in this or another way to implement it, and misunderstanding,
if you answer my question, from whom and when exactly you knew about the vulnerability, it will be really more understanding.

I have already answered.

I don't have the exact date because the discussion was over a long period. From knowing there were vulnerabilities...we ALL knew that (remember when we fixed the problem with CoinExchange?) to discussing options of how to fix.

You knew about it over a long period. However, do you realize that this vulnerability could easily lead to the end of Mooncoin blockchain just in several hours?

[Taranis67]

You probably know that we contacted mebagger2 before the release and he was auditing it, so-called 'my work' was discussed with him and with other members of community who donated money for ChekaZ,
Edit:the release contained nothing the community did not come to the consensus about, it is all about details, in this or another way to implement it, and misunderstanding,
if you answer my question, from whom and when exactly you knew about the vulnerability, it will be really more understanding.

I have already answered.

I don't have the exact date because the discussion was over a long period. From knowing there were vulnerabilities...we ALL knew that (remember when we fixed the problem with CoinExchange?) to discussing options of how to fix.

You knew about it over a long period. However, do you realize that this vulnerability could easily lead to the end of Mooncoin blockchain just in several hours?

So you KNOW that we had already seen the problems and were working on fixing it, the work on CoinExchange wallet took weeks to find and fix. You

You're going down a rabbit hole here. EVERYONE knew of the problems with vulnerability.

CoinEXchange was a symptom of the problem.  Altilly had notified me on more than one occasion to say someone was trying to double spend and I discussed with them possible future solutions to it.
I contacted YOU on November 11th 2018 to discuss the situation, specifically stating "Our First priority is stabalising the blockchain, And iron out the issues with it (such as the current CE problem)". So you KNEW we were working on it.  
It took many weeks to find out where the problem was and then to guide CE through the fix.  It also set us back with our wallet build as we had to then go back to the very beginning of the blockchain and start again, taking a root and branch approach to fixes.

Agswinner knew in March 2019 of our plans as I had discussed them with him and one other member of this group. I had given him full disclosure of all of our plans, including the blockchain AND the problems with the blockchain.  To make out you were ignorant of our work is disingenuous.

[Mooncoin_Foundation]

It is not aboit CE. The vulnerability with validation was much serious. Someone could just attack Mooncoin and mine the total supply with low difficulty in a very short period of time.
Edit: my understanding is that an attacker would even not need majority of hashrate for that.
If you don't believe, ask mebagger2, ChekaZ, or Peter.

[Taranis67]

It is not aboit CE. The vulnerability with validation was much serious. Someone could just attack Mooncoin and mine the total supply with low difficulty in a very short period of time.
Edit: my understanding is that an attacker would even not need majority of hashrate for that.
If you don't believe, ask mebagger2, ChekaZ, or Peter.

It IS about CE. Someones WAS trying double spends, exploiting the vulnerability in the blockchain. That person was ALSO trying it with Altilly as I have already stated.

CE showed how it was being done, once an investigation was conducted. It was then, again I have already stated and had informed you and Agswinner, that we had to go back to find out where ALL the issues were. Your developer couldn't prove he did or didn't build the wallet that CE were using.