The difference in receiving and accepting blocks is due to network latency and verification time. There isn't anything that can be done to make every single peer instantaneously know about a block the moment it is created; the laws of physics prevents that. It takes time for data to be transmitted and more time for the computer to verify the block. This is all dependent on the hardware of the connected machines and of the internet connection between peers.

No, Bitcoin has not hard forked before, and all releases are actually backwards compatible since all protocol changes have been soft forks. As 2112 said earlier, you can actually get past the BDB lock issue with some special configuration. So in theory, you could sync a 0.1.0 client fully up to date with some special configuration.

To fully validate a block, you would need all of the block data, which can be up to 4 MB. That data is required to validate all of the signatures. To validate that the block header is correct (but not check signatures), you only need the non-witness data, which can be up to 1 MB. To verify only the proof of work, you only need the 80 byte block header. To build a new block, you only need the 80 byte block header, but basically no validation will be done.

The largest possible size of a block with segwit is 4 MB. That is the most data that you can receive over the wire for a block message.

P2SH was a soft fork so older versions which technically do not support it can still partially validate those transactions and blocks. However, in order to fully verify P2SH transactions, you would need to have bitcoin 0.5.4+

What are you asking for? The prune option can already be changed by the user.

The wallet files are not text files. There really is no way to search for them since file extensions mean nothing and there may not be any unique text inside of the files.

P2SH (commonly known as multisig) was implemented in 2012, before 0.7.2. P2SH transactions can be validated by earlier versions.

If one of your private keys were compromised, then whoever has that private key will be able to figure out the rest of your private keys. All they have to do is go a few billion keys +/- of the one they have and they can get all of the private keys that you will ever use.

BIP32 derivation is vastly superior. In order to figure out all of your private keys, an attacker would need to know the master private key and the derivation paths. This means that if one of your private keys were compromised, your whole wallet isn't compromised. It is far easier to protect one key than it is to protect billions of keys.

Are you the person who sent it (as in you control the private keys) or did coincafe send it (as in they control the private keys)? If the former, make sure your wallet is synced and send again. If the latter, contact coincafe's support.

Whoever actually made the transaction (either you or coincafe) made it incorrectly and it spent from an output that was already spent by another transaction. This means that it is a double spend. The other transaction probably confirmed thus making your transaction completely invalid. Blockchain.info removed your transaction from their database because it is pointless to keep invalid transactions. You may be able to find your transaction on another block explorer, but it wouldn't help anyways if it is a double spend.

You can't. I know for certain that all versions of Bitcoin/Bitcoin-qt 0.7.2 and earlier will not be able to sync with the network due to an insufficient number of Berkeley DB locks which then essentially imposed a block size limit at around 500kB. This issue is what caused the March 2013 fork. Because of this, all versions of Bitcoin/bitcoin-qt 0.7.2 and earlier will be unable to fully sync the blockchain.

Yes.

Again, you can't import the files created by Multibit into Core. You need to import each private key through the debug console. You can only do this one by one.

You cannot import a Multibit wallet into Bitcoin Core. They use different wallet formats and there is no reason for them to be able to support the various wallet formats of other wallets.

The only way to "import" is to get the private keys and import them into Core. Or you can use Multibit to load the Multibit wallet and send the Bitcoin to an address in your Core wallet.

You aren't quite synced yet. You're a few hundred blocks short. Your most recent block is 468447. However your transaction was confirmed in block 468610. You won't be able to see the transaction until you have that block. The current latest block is 469389.

Run Bitcoin Core only and let it sync. Then stop it and run Armory.

Based on the errors in the log, it looks like a pretty simple fix. I will work on a fix and probably submit a PR for that sometime tomorrow.

Goatpig said that he will be out until Sunday, so don't expect anything to be merged or any releases to be made.

I have been able to replicate and confirm that there is indeed an issue with transaction broadcasts timing out with 0.96, particularly with the checking mechanism. A pull request to fix the issue has been made here: https://github.com/goatpig/BitcoinArmory/pull/241. Please help test it out.

The drama most certainly was not over in 48 hours. The intentional hard fork to fix the problem took until August 2013 while the unintentional one occurred several months before that in March 2013. Up until Autust, everyone was still using the consensus rules forced by the database locks. Even in the emergency situation, a hard fork still took several months to actually deploy. We aren't in such a situation now; a hard fork will need to take longer to deploy so that all of its consequences can be considered and tested.

Just because what seems like a large number of lines of code have yet to be written does not mean that it is "dead in the water". More than half of the companies, services, and wallets listed on the segwit adoption page have already completed their implementations.

Did you install Bitcoin Core? If it is not installed, you need to install it. If it is installed (or once you install it), is it fully synced? If not, let it fully sync before stopping it and running Armory.