The feeling when you find some diamonds is always great

If you keep your wallet always running, those 400 DMD will definitely stake every few days. Just make sure you keep them in one pile. If they won't, there is some other reason.

Great slogan!

You cannot stake DMD with Terracoin wallet software. You need DMD wallet, see the beginning of this thread for links.

I see bunch of masternodes come and go on the network.

You can have your DMD masternode hosted for 5 DMD/month on an always up and well connected server, where you don't have to have any knowledge or do any maintenance of the OS, software, hardware, confguration - just remotely activate it from your wallet, lock and power off your wallet and watch rewards coming in.

If you are interested, contact me here or on Slack.

Miningfield will be offering this service fully automated via web interface, in case you want to stay anonymous etc.

On your questions.

1. You do not have to encrypt the wallet in order to stake. In fact, the opposite is true. In order to stake, the wallet must not be encrypted (or of encrypted, must be unlocked). You encrypt the wallet for your own security, especially if you use insecure environment or OS.

2. There is no point to encrypt the wallet if it will be unlocked without you entering the password (which only you know). See 1. In such cases, simply do not encrypt the wallet.

3. This is good news. It means that DMDv3 was able to recover all of your keys (and addresses), but becaus ethey are in different format, transactions and address book entries cannot be preserved. In this case, run the wallet with -upgradewallet (or if useing the GUI, the same action is in the Repair Wallet option).
At this point your wallet should behave like normal. But it will still be one large file. In order to shrink it to the minimum, the more agressive -salvagewallet can be used.
Please note both could be unsafe in some circumstances, especially if your wallet was messed up (but the message you cite indicates this might not be the case).
You can export the private keys, with "dumpwallet" (in console) or manually as explained.
Then remove wallet.dat and import them with "importwallet".

If you imported your private key(s), then your addresses are still there, but because you did not import the address book you don't see them. You can verify what addresses your wallet thinks you have (only those that ever received coins) with the command "listaddressgroupings".

3c. It should be gone after -upgradewallet.

PS: As helmut mentioned, if you want to be safe, use only the exported keys and do not use the old wallet.dat file. See "listaddressgroupings" for the list of what addresses you have there.

As announced earlier, hosted masternodes will be provided as service to the community. The rationality is you have the funds (DMD), I have the resources to run it and the inclination to fiddle with compiling code and administering servers. You don't have to do any of that.

The service will be provided for a fee. I was educated it's not nice to provide free services
Today, the fee is 5 DMD/month.

The procedure to rent a masternode is as follows (short instruction):

1. You contact me, with your order. Use PM here.
2. I provide you with an address where to pay the fee.
3. You pay the fee.
4. I provide you with the IP address/port and key of the masternode.
5. You send 10k DMD to your own address. You then obtain the transaction output, with the following console command:

masternode outputs

6. In the masternode.conf file in the directory where your wallet.conf is located, you enter:

LABEL IP:PORT KEY TRANSACTION INDEX

The label is anything you care to remember. The IP:PORT and KEY you get from me, and the last two pieces come from "masternode outputs"
(you may have more than one, if you sent more than one 10k pile to yourself).
7. Restart your wallet.
8. You then open the Masternodes tab, where your new masternode will be visible under "My Masternodes". An inactive masternode is with status "MISSING". Click the "Start Missing" button or right-click each "MISSING" entry and select "Start-Alias".
Important: Wait at least 15 blocks after step 5. A masternode collateral needs to be at least 15 blocks old in order to start the masternode. Don't worry -- it will eventually start all by itself, later.
9. In a while (such as after 15 blocks), check your Masternode list again -- Active should be ticking. If you don't intent to actively stake with that wallet, lock it up and shut it down.
You are done. Enjoy DMD pour in your wallet.
10. You might want to set up MultiSend to make the earned coins go to your "main" staking address and be grouped with/staking with the rest of your DMD.

Please note, that it is advisable to do steps 5 and 6 one by one, because after seeting the transaction in masternode.conf upon start, the wallet locks it, so it's less likely you re-send the same 10k over and over.

When other hosted masternode services start appearing, they will use pretty much the same procedure, so if someone finds ways to improve this instruction, please feel free to contribute.

It will probably depend on how bloated/messed up your wallet.dat is.

I have sucessfully imported an wallet.dat file created in 2013, with the new wallet complaining only one public/private key pair was unreadable. But the balance was the same, so v2 software likely just silently ignored that key anyway.

However, I only did this as an experiment! As cryptonit wrote many times, it's not safe procedure and if possible should be avoided.

The process of exporting / importing the keys can of course be scripted. The v2 and v3 wallets provide RPC interfaces where you can query for the list of addresses in the wallet, then for their private keys, build a list and then similarly feed the private keys to the new wallet.

A piece of cake, just few lines of shell code 

The shared masternode technology was engineered and tested already. There can be also many providers of such service, so no centralisation of coins need to happen.

In addition, we are prepared to offer hosted masternodes, that is, you have the Diamonds, we have the hardware/software/network/setup and you just "invest" your 10k DMD in running (renting) one. The network benefits from having more masternodes and you, the investor benefit from higher payout on your 10k DMD investment. Again, there might be many providers of such services.

Or you can arrange it all yourselves. It's everyone's choice how to invest/benefit -- or just play with all this stuff.

By the way, 193.68.21.19 had 114 active connections..

I am shutting all of the nodes that were running to keep DMDv2 ticking. Hopefully this will help a bit for it to cool down.

By the way, the only reason to run a node in v2 is to monitor if there are still people running that old code and send them allerts from time to time.

As they say, so long and thanks for all the fish

danbi's pool is now completely shut down.

The pool has operated since 2013 and was helping Diamond survive some of the harsh waters it went trough.

I was running this pool as a hobby project/experiment and in order to support Diamond. The thrill will be missed, especially the fun dealing with coins mined while in a fork or when the wallet software and the pool software would mess things up and surgical operations were neccesary.

The pool mined some 262,428.34345940 DMD. Of interest is during it's whole operation, the pool has received 1,887.82270622 in fees and 721.84439137 DMD in donations. Here is the list of the top 100 donors. Thanks for your support!!!

Name	%	DMD Total
reggie	2.01	323.12
danbi	2	53.98
djzmei	20	41.74
eliano	5	22.36
pokeytex	0	19.67
pandaminer	2	17.90
djmic2k	1	17.24
dmd38	1	16.45
DMDCreeper	1	14.63
xyz123	1	14.53
Slowness	2	11.14
jmfcanada	0	10.49
eastcoastminer	2	9.44
poisk	1	8.34
marvingateway	1	8.13
Igor916	1	7.83
mrp	1	7.59
cryptonit	0	7.40
y85922	1	6.79
Nadador06	1	6.53
mitchellmint	1	5.85
barmaglod	1	5.69
physixz	1	5.59
donnk	5	5.06
mailbox2001bg	1	4.60
Surftycoon	0	4.48
kmetax	0	3.89
andromed	1	3.32
Henle	1	3.22
funtom	0.5	3.21
whocares	1	2.69
koka	1	2.55
Blank	1	2.51
my98olds	1	2.43
lborg	1	2.27
Mister1k	1	2.12
jepistons909	0	2.11
nighthawk2k3	1	2.02
ptic	1	1.62
DiamondMiner	0	1.60
Spidersbox	1	1.59
cgminer	1	1.42
moork666	1	1.21
reftop123	0	1.14
DarkIlluminatus	2	1.09
sgeorginni	1	1.08
Kasvain	1	1.06
arfcz	1	1.04
Smit675	1	0.99
saitas	0.5	0.88
shukukei	2.5	0.80
polanskiman	1	0.67
TrixMiner	1	0.64
superkev	1.5	0.57
araelius86	100	0.54
braddrab	1	0.54
pagubg	1	0.53
boozer	1	0.51
stillontop	1	0.48
Atomicat	1	0.47
dkeu	5	0.46
iikezoop82	0	0.46
mcdoom432	0.5	0.42
rickybobby	1	0.40
cakes	1	0.32
gehonna	1	0.32
dphilo	0	0.31
kanemochi3worker	0	0.29
Fonetik	1	0.26
ruleland	1	0.26
exi	1	0.25
processorhog	1	0.24
Jarski	0	0.22
Odyssey	1	0.21
small	1	0.21
chinox25	0	0.20
kryptm	0.5	0.20
Stargazer	0	0.20
vromadanov	0	0.20
Bemx2k	1	0.19
chris_dmd	2	0.18
fanfare	1	0.18
PurplePeopleEater	2	0.18
tiggity	1	0.18
newQui	1	0.16
Spaceman72	1	0.15
DMark	0.1	0.14
meteor	1	0.14
ReiMomo	1	0.14
CrushedPuppy	1	0.13
zveryock	1	0.13
nfa	1	0.12
annulusoddity	2	0.11
jrshawts10	1	0.11
kingsaladmonkey	1	0.11
bennormous	1	0.10
daishi	1	0.10
shoky	0	0.10
rolioez	1	0.08
thefrog	1	0.08

danbi's pool is not mining anymore.

The pool will shut down for good at the time Diamond switches to version 3 (about 12 September 2017). Make sure you withdraw your coins before that day.

It is a rough estimate of the expected outcome of all your coins staking. Of course, it's not possible to stake all of them, as there is competition, but the higher the value is, the more probable your coins will stake soon and produce more stake reward.

It is calculated by multiplying the coin pile size and the age of each coin pile eligible to stake (more than 9 days old).

This is going away in Diamond v3 however, as coin age will not be considered anymore there.

It seems I am not going away from Diamond.

Coming to think of it, I could help people setup 24/7 masternodes instead. With preinstalled daemon and chain - just supply your node key and transaction data. No coins there, you control that from your very own wallet.

Thinking about the price

danbi's pool is going down for good.

Please note that danbi's pool will stop minning around 1st September 2017 and will stop operation at the time Diamond switches to version 3 (12-13 September 2017).

Make sure you withdraw your coins before the switch day.

It may be, that the Cryptsy wallet used differen db version. The expected/standard version is 4.8, but I have compiled wallets with other versions as well -- they work just fine, as long as you don't try to exchange it with outher software. Just a wild guess.

New wallet version 2.0.5.7
Release URL: https://github.com/DMDcoin/Diamond/releases/tag/diamond2057

This wallet is not mandatory. However, due to new functionality and improved CPU usage it is highly recommended especially for loaded nodes, such as those that mine/mint, pools and exchanges. It should also improve performance for everyone.
Binaries for Windows and OS X (tonight) are provided. Just replace your own binary. If you build form source, stop old binary, start new binary. No other update action is required.

Changelog:

Optimizations to call hash calculation functions less.
Small optimization to Groestl hash routine.
Ban nodes that are disconnected due to old version/protocol.
Implement -zapwallettxes, borrowed/adapted Bitcoin code.
Implement ACL for connected nodes.
Fix bugs in seed node processing.
Add and activate seed nodes to facilitate bootstrap without config file.
Turn IRC off by default. (IRC may be removed in future)
Increase maximum number of outgoing connections to 16
Limit output to log file if debug is disabled.
Update wallet version to 2.0.5.7

Of special interest is -zapwallettxes. This command switch (or config file option) will wipe out any existing transactions in the wallet, then initiate rescan of the block chain (slow!) to find out the valid transactions for your coins. If used as -zapwallettxes=1 it would also preserve transaction comments etc. If used as -zapwallettxes=2 it will do a clean rebuild of the transactions without those details. If you put it in the config file, make sure you remove it after first use, as it will do the same (slow!) thing every time you start your wallet.
If you run a busy wallet, that sends a lot of (not PoS) transactions you might want to run this periodically to make sure your wallet transaction acconting is in sync with the block chain.

The new wallet is able to start without any config file. It would then use the seed nodes to find out about other nodes and connect to them as well. This lets us get rid of IRC in some o the next updates.

The new wallet code also makes certain optimisations to reduce the number of hash function calls for each block. More optimisations are planned in this area to improve CPU usage further. It also reduces the amount of log file output, if debug is disabled to reduce storage I/O load.

I will try with simpler sentences.

By design, Bitcoin will create new address for the change, when you send coins and there is change remaining.

It is designed this way, because people hope their transactions will remain anonymous. Nobody would know what they have in their own wallet. If you have an coin pile of 100 DMD and send 50 DMD to someone, the change will go to a new address. Nobody will know if that address is yours, until you spend it. It will also not know to which wallet the address belongs.

Some people like this and they demand it work this way. This is how Diamond behaves without setchangeaddress= setting.
This setting is unique to Diamond. I invented it.

When you use the setting, no new address is created for the change. It is send where you specify. It could be the same wallet, or different. It could be your wallet or someone else's.

Sorry for the language problems. English is not my native language. In a conversation both sides need to make some effort to understand each other.
By the way, I post these replies for other people who might have the same questions, too.

I would always recommend people sync the chain from start. Except people want to use their wallets *now*. In which case I would always recommend they make periodic backups and start from there. A year old backup since we switched algorithms is wiser than starting from scratch.

I do start from scratch test almost every day, but this is to verify that no code changes introduce problems with the existing blockchain. Preserving existing blockchain is what is required if we talk about trust at all.

Considering it could take days, even under the best conditions to sync the chain from scratch, we provide from time to time backups from those "fresh sync" nodes. For those who trust us at least a bit and who have no time to wait. By the way, if people don't trust us, they should read and compile code by themselves, even better write their own wallet -- for we could sneak malicious code in the wallet too, right?

We had few forks in the recent month, all as it seems due to different reasons. Downloading an archive of the current blockchain is the fastest possible way to get people back online. OR, restoring from your own backup a month/week ago. I guess this is why people prefer doing it this way.
The bad blockchains are still being analysed for more details to help prevent it happening in the future (or converge faster), but there aren't many volunteers doing it so that process is slow