But if the coins are moving, then they can't reliably know how much is held at present time. Sure they can all be traced, but that only tells you that at one point in time, the company had X amount.

Once the coins start moving, they can't reliably know which addresses you send to are actually yours.

Even if it is, if you load that address with just the required amount, they won't know about the rest of your Bitcoin. The change will be hard to trace after a few transactions anyways.

Recompile qt from source using the compile bitcoin-qt 0.8.6 with qt 4.8 instructions in the OP.

Also, if you don't get your Bitcoin from exchanges, then you won't have an identity associated with your coins. If you do work for Bitcoins or mine them, and at no point involve an exchange, you still get Bitcoin and there won't be an identity associated with your coins. Furthermore, with Bitcoin addresses, even if you can trace Bitcoin transactions, you can't know for sure whether the next address is the same person or a different one.

I think you forgot to remove the -reindex flag from the shortcut. Better remove that now otherwise it will reindex every time you start up.

If you have a spare computer, you could set that up as a server. It would just run Bitcoin Core and you can have spv wallets on other computers that connect only to your server node. Then you can ensure that your stuff is secure while not having to have Bitcoin Core take up space on your actual computer. Core 0.11.0 has pruning included but it can't use the wallet at the same time. If you set the node up and used pruning however, as long as you didn't use a wallet on that node and used spv wallets on other computers, it would work.

I think they have a more accurate representation of the mempool than other sites. Most nodes have default rules which will reject almost all of the same transactions that bc.i does. Other sites such as tradeblock shows all unconfirmed transactions at that time, including ones considered non standard (dust) which are normally rejected by most nodes. I think that they tend to cause panic about the size of mempools when their data is not accurately representing most node's mempools. Statoshi.info is also quite reliable since that is just a node with stats.

There is actually one key which is held by many people. Those people are kept secret, but it is known that Theymos, Gavin, and Satoshi hold the key. Others do to, probably including most if not all of the core dev.

Basically it uses Bitcoin for micropayments to access cheap WiFi. This gives users cheap WiFi and lets hotspot owners make money off of offering their WiFi to people.

Did you follow all of the instructions for bitcoin 0.8.6? It looks like that coin is based off of Bitcoin 0.8.6 and thus you will need to follow those instructions instead.

The root of the problem is in the method for that command here: https://github.com/bitcoin/bitcoin/blob/ca37e0f33980a1fe96ac4ed08fd7d692a7a592a5/src/wallet/rpcwallet.cpp#L1968

The statement determining whether to show the message or not is this
As you can assume, this states that if the wallet is not encrypted and either help is true or parameters is not one, then display the help message. As you can see with that logic, since your wallet is encrypted, it will skip past this, even if help is true.

Help is set to true in this file: https://github.com/bitcoin/bitcoin/blob/240b30eaf0b94a0094b8943dd9c01448bc29c3ba/src/rpcserver.cpp by using the help command. The key part is at line 226 - 227 which are as follows
since the string that encryptwallet method returns is empty, this help output assumes that the command doesn't exist, so it prints the unknown command message.

This is clearly intentional. Why would they have a specific check for whether the wallet was encrypted or not for the help message. As to why that was done, I don't know.

For a computer, that is jumping around. It is not in order that it is reading the file in. In order to go back to a confirmed transaction, it first needs to get through the corrupted data, which it will have no idea what that data is, before it can reach any good data. Even so, depending on what it was reading, it may be corrupted in multiple places in the database. The corruption might also might not be of the transactions, but of the file and database structure itself. If that was corrupted (which is probably the case since bad transactions can just be redownloaded) then having good transactions means nothing as it cannot read them or understand the format of the data. Just to be safe, it will reindex. Reindexing guarantees that the data it reads is not corrupted. Otherwise, the data might be corrupted and such a corruption can negatively affect the entire program.

Reindexing does not mean it is downloading. It might appear that way, but it is in fact reading the data off of the blk files and indexing them into a database in ldb files. If you were stupid enough to delete the blk files then it will be redownloading. Even so, it isn't the bandwidth of Bitcoin's network, it is your own internet bandwidth that limits the download. The bottleneck for you right now is your CPU and RAM. Reindexing is all on the CPU and the RAM. If you don't have a good CPU and enough RAM, then it will take a long time. For me, I can have a reindex done in about 15 hours. Some people have them done in 1 or 2 hours, others a few days. But the problem is on your computer, not the network.

It isn't because of the wallet. I think it might be because someone is spamming again, but not at the levels as previously. That might be slowing down your transaction, although it seems to have a high enough fee.

Well the linear stuff is not just the database, but computers in general. They can't just jump around and process multiple things in different orders like humans do. What Bitcoin Core can do is migrate to a more ACID (Atomicity, Consistency, Isolation, Durability) database. That would allow it to recover better from crashes and not have to reindex every time the database corrupts. The only problem is that changing databases would require a huge rewrite of the code to support a different database and then that new version would most certainly not be backwards compatible. It would have to reindex the first time.

did you download qt 4.8.6 and put it in C:/Qt/4.8.6? It can't find a dependency that it needs which is an older version of qt.

It doesn't spam and fatten up the chain, and it is still technically in alpha.

Bitcoin is in alpha development still. That is why version 1.0 still doesn't exist. It isn't stable and ready for mainstream adoption yet, which is why it is still labeled alpha by the core developers.

As long as you close it correctly, it will pick off where it left off when you open the program again.

Nope, it doesn't spam the blockchain with more crap. It doesn't make a difference to that at all. The reason for using different addresses for everything is for security. It makes it more difficult for people to track your payments to places and it makes it easier for you to track payments to you. Also, by using multiple addresses, it is more difficult for people to know how much Bitcoin you actually have.

It can't because LevelDB (the database type used by Bitcoin Core) is not all that great with recovery. Once it corrupts, the data may still be readable, but parts of it won't be, and it does not know where. The corruption would not only be just at the end where the latest transactions are, but could be throughout depending on what was open at the time. The corruption also prevents Bitcoin Core from being able to open and read the database as it should. While humans can open the file and read it(with the right tools), the computer is not able to interpret the data since it comes linearly. Humans can jump around and look at the data to find stuff that we need, but the computer processes things linearly. If it receives data it doesn't recognize, then it will crash and error out. The corruption causes this erroring and it can't be fixed without rebuilding the whole database.

Since the data is read linearly, it won't ever be able to get to the point where it can read good data. Due to the corruption, it will error out and take the safe route of having to reindex the whole thing.

You can't. The transaction actually doesn't exist in the database. I think it is actually hard coded. Since the transaction doesn't really exist, it can't be viewed by anyone through conventional means and it can't be spent at all.

As you use more than 100 hundred addresses, Bitcoin Core will generate another 100 address for the keypool. Generating and storing those 100 new keys will of course take up some extra space. If you are doing Bitcoin transactions with the principle one input one output, then you will have to generate 100 new addresses after 100 transactions.

They can't do that.

I am fairly certain that the addresses where the Bitcoin went are change addresses. They are still your address. Bitcoin Core will send your extra Bitcoin to another address that you control so it follows the principle of one input one output for each address.

Let it download. Bitcoin Core was confused (don't know why) about your transactions. Let it redownload and reindex the blockchain. All of your Bitcoin will still be there and still be spendable. Don't panic.