Here is a little something regarding Obfuscation. It is a way of making transactions a bit more difficult to track. It is one of the services provided by the masternodes. This is not the anon tech we are working on, but gives us a good base to build from.

Well, you clearly did not follow the instructions. In order for you to get the output you posted you had to enter zapwallettxes in the console. In order to do that the wallet had to be running, if you did the first step the wallet would not have been running. So, again, shut down the wallet....... Wait, I thought you said the wallet wouldn't start? Please, join us on slack or skype.

Stop the wallet, delete everything in the data directory except your masternode.conf, darknet.conf, and wallet.dat, start the wallet with -zapwallettxes. If that doesn't work, repeat those steps, but use a pre-PoS wallet backup and start the wallet normally. If you are still having issues hop on skype or slack, links in the OP. For slack, send s3v3n a PM with an email address and he will send you an invite. It is much easier to send a bunch of messages back and forth quickly like that, you will get squared away a lot quicker than going back and forth here, where sometimes posts get lost in the pile.

So, I did a little playing around last night. I know, I know, I do have better things to be doing with the coin, but I can take a break from time to time, right?

Anyway, I used Obfuscation to mix some coins and give it a little test. I only used 2 rounds of mixing, if I was really trying to be sneaky I would have used 8. I created a new address in my wallet and sent 50 DNET to it using Obfuscation, I have 10,000 DNET for anyone who can tell me one of the other addresses in my wallet based on the transaction history of this new address. The address I created is DEZZ3RifTfpSXEbddZ64d9qccN6uxjyR2u.
To claim the 10k you must tell me how you determined the other address was indeed in my wallet, so don't just guess. Use the block explorer to see the action, http://www.presstab.pw/phpexplorer/DNET/address.php?address=DEZZ3RifTfpSXEbddZ64d9qccN6uxjyR2u.

It took me a while to mix these coins, and we had to ask some of the cats in the skype chat to turn on Obfuscation in order for it to even work. The more people use this feature the better it will work for everyone, so, go ahead and turn it on. You can go to settings->options->main and set the number of rounds to use and the amount to keep anonymized, then on the overview page of the wallet click on start Obfuscation.

This is a good example of the Obfuscation process in action. It works pretty good, but we are after something even better.

Edit: I just remembered bitcointalk doesn't like what seems to be giveaways based on posting addresses, this could be misconstrued as such, hop on slack or skype if you think you have one of my addresses.

To those still having issues, can you please hop on skype or slack so that we can help get things figured out? Just checked in with a few of the folks there and they have Windows wallets that are ticking along just fine on v2.1.2.1, staking and serving as controller wallets at the same time. I am doing it on Linux, and s3v3n is doing it on Mac. There are still some underlying things to tweak, but there is no reason you shouldn't have a fully functioning wallet.

The links to skype and slack are in the OP, shoot s3v3n a PM with an email address for a slack invite.

I was finally able to get my wallet to crash, I had to do so much screwing around with it to get it to crash I am not 100% sure what I did that caused it. I did find that it would continue to crash until I replaced my wallet.dat with a backup and resynced. I was able to get the wallet to start again by starting it with -salvagewallet, but that would eventually crash again.

It seemed everything was running fine until the chain stalled, so I am hoping that once everyone gets things back to normal the problem will go away, I am still trying to find the underlying cause of the crashing issues.

Remote masternodes have empty wallets, so removing everything in the data directory except for the darknet.conf and restarting the daemon should fix the issue for them.

Sporks are a way of mitigating network confusion and disagreement when there are either either hard or soft forks. If you run "spork show" in the console you can see the current state of the various sporks. When we push new updates that have protocol level changes we disable sporks 8, 9, and 10. Those are the ones needed the most. The others have not been needed by us so far.

Yes, I can control them, I am the only one with the associated private key needed to do so. That doesn't really effect decentralization, as beyond allowing older versions of a wallet to communicate with newer versions during transitional periods, they serve no other function. I can't use them to roll back the chain, disallow certain users, deny blocks, or any other type of thing.

The only spork that could even be misconstrued as a decentralizing thing is spork 10, the pay updated nodes spork. It is used after a protocol level change, which is generally a mandatory update, to decide when to stop sending masternode payments to masternodes still running the older version of the wallet. It lets older versions of the wallet continue acting as masternodes and getting paid for it during the transition, preventing a situation where there were no masternodes, or even very few, weakening that side of the network.

I really wish I was having these same problems so that I could, not only find the underlying cause, but also figure out an easy, one size fits all, way of getting back to normal. When you say the wallet won't start at all, do you mean that it does nothing, or gives you an error, or some third thing?

OK folks, we re moving again. We are having an issue with one of the sporks, that is what caused the chain to stall for a bit the other day. When I disabled it the other day I just entered a date to activate as a few days in the future. That time passed last night stalling the chain again. I just changed the date to a couple months from now. We will have the issue resolved by then. Sorry about that.

Honestly, while we appreciate the different ideas, we want to burn these coins like we said from the beginning. We don't want to be the types that go back on their word, that sets a bad precedent, as well as gives some folks legitimate negatives to dwell on. 60k is not that much in the grand scheme of things, and we will eventually make some budget proposals to compensate individuals for their contributions.

With that said, it will be a bit before we burn them. Right now, you may have noticed, presstab's block explorer is not really showing much useful data in the transaction and address pages. He is doing some tweaking to the backend so that things will display right. Once he is done with that we will burn them, then be able to point to a specific transaction so that anyone who would like can go and verify it.

We will be sure to let you know when it happens.

Are you using a backup of your wallet.dat that is from before v2.1.0.0? One that was made before that version, and was not used with the v2.1.0.0 wallet or the v2.1.1.0 wallet. I don't think there was any issues with the v2.1.0.0 wallet, but the v2.1.1.0 wallet corrupted wallet.dat files. If the wallet.dat was in place while using that wallet you will need to use another backup, or export your private keys and import them into a new wallet.dat.

For those that seem to still be having the occasional crash, could you run the wallet for a bit with a completely new, clean wallet.dat and verify that it does not crash. I am unable to replicate the problem, so need some help from you guys to troubleshoot it.

If you could shoot s3v3n a PM with an email address and get yourself a slack invite that would be great, thanks.

There is a bug that causes the client to lock up when running start-missing when you have a lot of masternodes. This has been there for a while now, it is not new to the post PoS wallets. It also rears its ugly head when using start-alias sometimes. I have found it seems to work to start just 2 or 3 masternodes with start-alias, wait a couple minutes, then repeat. It sucks, it takes a long time, we are aware of the problem and will work to get it fixed. It is not just the Windows wallet, it is all of them. For the time being we just have to grin and bear it, sorry.

As far as the getting stuck on a block, or crashing out when staking it seems that everyone else has been able to eliminate that by using a wallet backup from before v2.1.0.0. If you don't have a backup from before that you can fire up the wallet, dump your private keys, and import them into a fresh wallet.dat.

While I would like to claim that bit as ours, we inherited it from Dash.

Yeah, this has been an ongoing thing for a few versions. I have found it is best to start a few masternodes using start-alias, wait a bit, then start a few more, wait a bit, etc. We will look into it, we have had some higher priority things to work on lately.

Not needed. If you have a Qt wallet as either a standalone masternode or controller wallet you can go into coin control and see that the input(s) for the masternode(s) is(are) locked.

Yeah, the wallet that provides the data for that masternode info page is down right now, should be back up later on today, I would think.

Good catch. The budget info is saved in budget.dat, with everyone deleting theirs it looks like all budget info is gone. I will see if using one from a backed up data directory will save things, but I am not holding my breath, may have to start from scratch there.

The pool section is useless, another good catch, thanks for keeping us on our toes. It will get removed shortly.

It is looking like you guys have come to the same conclusions and fixes regarding the crashing wallets and corrupted wallet.dat files, good job helping each other out.

If anyone notices anything else let us know, thanks.

While I have a bit of time to kill waiting for things to get going I figured I would talk for a minute about the PoS rewards for anyone who was wondering. If you either haven't been here for long, or haven't been keeping up with everything, you may have noticed that the rewards for staking don't seem to match up with what you may have expected. So here is a breakdown of what is going on, I posted this in slack when asked, so will just copy and paste it here with a bit of editing and a few additions.

Masternodes will be paid a portion of the block rewards. Refer to the OP of the ANN thread for the block rewards for any given block number. We have implemented a "seesaw" reward mechanism that is used to determine the split between the masternode and the staker of the block. Right now the value of each block is 50 DNET. 10% of that is reserved for the budget, which is voted on by the owners of masternodes, anyone can submit a proposal to be voted on. So, we are left with 45 DNET to be shared between the winning masternode and the staker

Here is the actual code that is used to determine the split.

else if(nHeight > LAST_POW_BLOCK)
   {
       int64_t nMoneySupply = chainActive.Tip()->nMoneySupply;
       int64_t mNodeCoins = mnodeman.size() * 10000 * COIN;

       if(fDebug)
           LogPrintf("GetMasternodePayment(): moneysupply=%s, nodecoins=%s \n", FormatMoney(nMoneySupply).c_str(),
               FormatMoney(mNodeCoins).c_str());

       if (mNodeCoins <= (nMoneySupply * .05) && mNodeCoins > 0) {
           ret = blockValue * .85;
       }
       else if (mNodeCoins <= (nMoneySupply * .1) && mNodeCoins >= (nMoneySupply * .05)) {
           ret = blockValue * .8;
       }
       else if (mNodeCoins <= (nMoneySupply * .15) && mNodeCoins >= (nMoneySupply * .1)) {
           ret = blockValue * .75;
       }
       else if (mNodeCoins <= (nMoneySupply * .2) && mNodeCoins >= (nMoneySupply * .15)) {
           ret = blockValue * .7;
       }
       else if (mNodeCoins <= (nMoneySupply * .25) && mNodeCoins >= (nMoneySupply * .2)) {
           ret = blockValue * .65;
       }
       else if (mNodeCoins <= (nMoneySupply * .3) && mNodeCoins >= (nMoneySupply * .25)) {
           ret = blockValue * .6;
       }
       else if (mNodeCoins <= (nMoneySupply * .35) && mNodeCoins >= (nMoneySupply * .3)) {
           ret = blockValue * .55;
       }
       else if (mNodeCoins <= (nMoneySupply * .4) && mNodeCoins >= (nMoneySupply * .35)) {
           ret = blockValue * .5;
       }
       else if (mNodeCoins <= (nMoneySupply * .45) && mNodeCoins >= (nMoneySupply * .4)) {
           ret = blockValue * .45;
       }
       else if (mNodeCoins <= (nMoneySupply * .5) && mNodeCoins >= (nMoneySupply * .45)) {
           ret = blockValue * .4;
       }
       else if (mNodeCoins <= (nMoneySupply * .55) && mNodeCoins >= (nMoneySupply * .5)) {
           ret = blockValue * .35;
       }
       else if (mNodeCoins <= (nMoneySupply * .6) && mNodeCoins >= (nMoneySupply * .55)) {
           ret = blockValue * .3;
       }
       else if (mNodeCoins <= (nMoneySupply * .65) && mNodeCoins >= (nMoneySupply * .6)) {
           ret = blockValue * .25;
       }
       else if (mNodeCoins <= (nMoneySupply * .7) && mNodeCoins >= (nMoneySupply * .65)) {
           ret = blockValue * .2;
       }
       else if (mNodeCoins <= (nMoneySupply * .75) && mNodeCoins >= (nMoneySupply * .7)) {
           ret = blockValue * .15;
       }
       else{
           ret = blockValue * .1;
       }
   }

So, basically, when the number of coins locked in masternodes is between 0 and 5 percent of of all available coins the winning masternode gets 85% of the block reward. using that as a reference you can go through the code to see that if the number of coins in masternodes is more than 75% of all available coins the winning masternode will get 10% of the block reward.

There are 16 steps to the seesaw right now, over time we will tweak the seesaw as we get a better feel for how the various aspects of the network perform. We started with the idea that about 1/3 of coins being in masternodes is an ideal split. That makes for a strong masternode network, which is responsible for the Obfuscation transactions as well as the SwiftTX transactions. It should also leave enough coins in the wild to support the needed level of staking to promote blockchain security, and have a good number of coins on the exchange to provide sufficient liquidity.

A more user friendly breakdown of the steps of the seesaw is as follows.

If number of coins in masternodes is between 0 and 5 percent of coin supply masternodes will receive 85% of the block rewards.
If number of coins in masternodes is between 5 and 10 percent of coin supply masternodes will receive 80% of the block rewards.
If number of coins in masternodes is between 10 and 15 percent of coin supply masternodes will receive 75% of the block rewards.
If number of coins in masternodes is between 15 and 20 percent of coin supply masternodes will receive 70% of the block rewards.
If number of coins in masternodes is between 20 and 25 percent of coin supply masternodes will receive 65% of the block rewards.
If number of coins in masternodes is between 25 and 30 percent of coin supply masternodes will receive 60% of the block rewards.
If number of coins in masternodes is between 30 and 35 percent of coin supply masternodes will receive 55% of the block rewards.
If number of coins in masternodes is between 35 and 40 percent of coin supply masternodes will receive 50% of the block rewards.
If number of coins in masternodes is between 40 and 45 percent of coin supply masternodes will receive 45% of the block rewards.
If number of coins in masternodes is between 45 and 50 percent of coin supply masternodes will receive 40% of the block rewards.
If number of coins in masternodes is between 50 and 55 percent of coin supply masternodes will receive 35% of the block rewards.
If number of coins in masternodes is between 55 and 60 percent of coin supply masternodes will receive 30% of the block rewards.
If number of coins in masternodes is between 60 and 65 percent of coin supply masternodes will receive 25% of the block rewards.
If number of coins in masternodes is between 65 and 70 percent of coin supply masternodes will receive 20% of the block rewards.
If number of coins in masternodes is between 70 and 75 percent of coin supply masternodes will receive 15% of the block rewards.
If number of coins in masternodes is more than 75 percent of coin supply masternodes will receive 10% of the block rewards.

This is a bit more rudimentary than we initially anticipated, but should work well enough for the time being until we get a good idea of the profitability of staking vs masternode ownership. We will be revisiting the seesaw once we have more data to base the numbers on.

The primary goal behind the seesaw is to ensure that it is always more profitable to have a masternode than it would be to just stake those 10k coins. The reason for that is the costs, hassles, and risks associated with upkeep of a masternode are greater than those of staking alone. But we also need to ensure that there are enough coins not in masternodes for the reasons presented above.

Yup. You are absolutely right it sure has been a mess. We are looking forward to moving past this when things start moving again tonight. We are so grateful to the community for bearing with us through all of the hassle this past week has presented us. I think that the folks in here are some of the best in crypto, and we are so glad to have you guys here with us.

We knew there would be a few roadbumps, but never expected to encounter the level of hassle that we did. There is clearly a reason all other PoS coins just stick with the old Bitcoin codebase, but if we want PoS in general to remain competitive things must advance. Most of the issues we have encountered along the way were only evident once there were a large number of people stress testing the system, we could not have done it without you guys. We are so grateful to you all.

Thank you for that. Again, I would also like to apologize on behalf of the team for having missed your request in the first place. But, your apology means a lot to us, it is not something that can be expected from most folks involved in crypto. No one here usually likes to admit mistakes, those who are willing to do so are few and far between. I am glad you see it as a mistake, we want to help in any way we can, but don't always see every post, especially in trying times such as we have been going through the past week or so.

I just want to emphasize for everyone the slack and skype contact methods. There are fewer people in slack, skype seems to be really active all of the time, but either one of those places will get you a quicker response more often than not. Links are in the OP, stop in and say hi.

Yeah, sorry, I didn't catch any previous posts asking for a 32 bit Linux binary. As jakiman pointed out, we have been pretty busy with other things lately, and haven't really spent a lot of time in here. Reaching out to us via slack or skype would have gotten you a much quicker response.

Also, you don't add .ac to the end of the name of the configure file. The configure file is used by autoconf to build the configure file that is then used to build the make file.

As mikegi stated, the correct commands to build the binaries from source are:
./autogen.sh
./configure
make

Which should work just fine assuming you have installed all of the dependencies.

To save you the hassle, https://github.com/Darknet-Crypto/Darknet/releases/download/v2.1.1.0/Linux32.zip.

Sorry you find us arrogant and unhelpful, at least no one else has accused of that. If you feel as if you are being ignored again be sure to reach out to us via some other methods, slack, skype, or PM. We are here to help those who need it, as I am sure most would agree.

Yeah. Sorry. You would not have had to if it weren't for someone modifying the code for nefarious purposes.

Really, I guess it should be taken as a compliment, someone with a bit of coding skills is keeping a close enough eye on things to try and get some quick, free coins. Just wish they would have come to us and said "Hey, I have a bit of coding know how and would like to help". They may have been able to get further ahead that way than the approach they took.

Anyway, the new source is up. s3v3n wil get the binaries up later on tonight. We are still going to restart the chain tomorrow at 9PM EST. This is the last time you will have to go through this.