Alright!

So, I hit a speed bump giving the 611 token a spin.

Actually, I hit several speed bumps.

I do have a tech background but this amounts to a plea for help if anyone knows a workaround that doesn't involve me tearing into the codebase. I do have other things I need to be doing, lol!

So here's the pattern of steps I went through:

- Setup the 611 wallet
- Encrypt it
- Store backups all over
- Get my 611 tokens
- Start registering some domains (name_new & first_update)
- Registrations were happening

HERE'S WHERE I SCREWED UP: I was going to test backup and restoration and totally forgot the running node needed to be running for 12 blocks to be fully synced. So I stopped the node before the first_update(s) ran. I know... lash me for it! The first one of the set of four completed successfully.

RECOVERING FROM THE ABOVE: Has been a total nightmare. I have a full Keepass log/history and all the random numbers / registrations I would need ---BUT--- something else is wrong. I will enumerate.

- Turning the node back on with the existing encrypted wallet doesn't work. The wallet relays the open transactions and gets ignored by the network (it keeps relaying the same pending txs for hours with no progress).

- Manually deleting the pending transactions and resubmitting the transactions commands doesn't work (network ignores the requests).

- Restoring from the backup wallet doesn't work. The wallet doesn't fully sync with updated addresses and only has the "spent" addresses to work with.

- Manually pulling the wallet forward by doing "importprivkey" on the missing addresses fixes the balance on the restored wallet and brings in all the missing transactions but then corrupts the encrypted wallet entirely (encryption passphrase no longer works and I have to start the process over again).

- Being at wits end I set up a NEW WALLET ... WITHOUT ENCRYPTION and tried to do an importprivkey on a single funded address from the first encrypted wallet and I get the same import error in the log warning me about an invalid header. The balance shows correctly, the wallet lets me perform transactions on the amount, and we're back to the network ignoring me. For this test I resynced the node from the ground up with a totally clean wallet (entire .611 directory was cleared for this) and the fresh wallet cannot access the funds re:importprivkey problem.

- I'm using the debian8-611d binary (newest one) and it leaps out at me that the importprivkey corrupts the wallet file to the point where it cannot be decrypted as well as fails to function properly when an unencrypted wallet tries to import tokens (the wallet says it's sending funds and is ignored by the network).

The error when using importprivkey (for both encrypted and unenecrypted wallets) is as follows:

You can confirm this trying to import any private key to any wallet... regardless of if the private key (or importing wallet) is funded or not. (WARNING: importprivkey will corrupt the wallet in the tests I ran. Keep backups.)

Request: Have a "rescan" feature for the wallet so backed up wallets of a previous state will catch up properly. Fix the "importprivkey" wallet corruption (when it renders the decryption key unworkable it can't be my imagination). The lack of these two functions boxed me in.

UPDATE: I've confirmed that setting up a new clean wallet with clean transactions works. So it's not my network/server/firewall/etc... This narrows the problems down to literally only wallet corruption. The first wallet must be corrupt because it was shut off before finalizing the name_firstupdate transactions. The backup wallet doesn't sync up on its own and becomes corrupted when I have to do a importprivkey call on it. New clean wallets cannot import the private keys from the first wallet because the importprivkey command apparently corrupts them too (confirmed by the fact that a clean wallet without calling importprivkey works and registers names).

===================

I'm working around all of the above by setting up a new a wallet and buying more tokens and trying to finish what I started using those. This does mean that I cannot move (or register domains with) the first wallet though. It also means the first domain is stuck pointing to its current nameservers until we can fix this. So I have to try and be nice to the webhost until we get a fix.  

I was planning on holding tokens as a small investment here anyway. Now I'm committed regardless of what I want. Ha!

Pro tip: After reserving a name with name_new you should MANUALLY wait for the 12 blocks before issuing the name_firstupdate command. I issued the commands back to back and while the server was waiting for the 12 blocks to pass the Debian binary crashed 6 blocks in. This rendered the wallet unworkable. The name_firstupdate commands failed once turned back on (network ignored the wallet). I had to setup another wallet (3rd one in this post), send it new tokens from an exchange, and repeat the process there. Given that I don't see anyone else mentioning these issues I'm thinking the problems might be specific to the Debian/Linux binaries. And the wallets (when rendered unworkable) will still show balances and things but will just be ignored by the network from then on. I SUSPECT the keys that handle transactions are getting munged in the wallet files which is why the network is ignoring them afterward.