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.

Read the technical documentation and read the source code of Bitcoin Core.

Is this the official version from bitcoin.org or a version compiled by yourself or someone else?

Actually your post is absolute bollocks.

Actually, it was not.

First of all, the hard fork was entirely unintentional. Secondly, deploying the final change that actually changed the consensus rules still took ~6 months before the situation was considered completely resolved with a block that would have been invalid under the old rules being mined and accepted by the network. The first chain split happened around the end of March. The block that marked the issue as resolved (since it would have been invalid to older clients) was mined in August (block 0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07) ~6 months after the initial chain split.

Segwit is absolutely complete. It is not activated yet, but the code is absolutely complete and those clients which are supporting it have long since completed their implementations and testing of it. In fact, part of the reason it's start date was delayed was because other wallet developers will still implementing it and testing it and wanted segwit to be done by the time the activation period started.

You are comparing apples to oranges here. The segwit changes includes tests and deployment. Your one line of change for a 2MB hard fork contains no tests and no safe deployment parameters. IIRC if you add in the necessary tests, deployment logic, and other necessary parameter changes to make it deploy safely (as with Bitcoin Classic), then you end up with ~2000 lines of code changed.

But no altcoin has the same environment as Bitcoin. None have the same market cap, visibility, number of users, trade volume, etc. No altcoin is comparable to the Bitcoin and cannot serve as accurate measures as to how successfully a hard fork on Bitcoin would be.

That's not how wallets and addresses work. To the blockchain, there is no such thing as a wallet. A wallet is an abstraction for humans to group together multiple addresses and their respective private keys. Wallet software handles wallets, and that is it. Bitaddress.org will give you 3 addresses that have no association to any wallet or any other address.

When was the last time you unlocked your wallet? If you have requested more addresses than there are in the keypool since you last unlocked the wallet, it will not be able to refill the keypool with new addresses. By default the keypool contains 100 addresses.

Yes. It contains the information necessary to get your private keys (and probably the private keys themselves). If someone were to get access to it, they could take your coins.

It is recommended that it remains offline, but if you think your password is strong enough and the wallet encryption is strong enough, you can keep it online. I wouldn't recommend it though.

You shouldn't need to ever backup individual private keys.

Yes. Anyone who can access your private keys will be able to spend your coins.

Yes. All of your private keys will be derived from those words, so anyone who gets it will be able to get all of your private keys and spend your coins.

A good resource would be Core's doxygen docs: https://dev.visucore.com/bitcoin/doxygen/

You can also just start at the entry points and work your way forward from there.

It isn't that it is easier to implement but rather it is easier to deploy segwit than it is to deploy a 2 MB hard fork. In general, soft forks are easier to deploy as less people are required to upgrade and those that do not upgrade won't be kicked off of the network. OTOH, a hard fork requires everyone to upgrade in order for them to not be kicked off of the network. Having everyone upgrade is significantly harder than getting most of the miners and some users to upgrade.

What version of Core are you using? There is no Bitcoin Core version 5.7.1. That is the version of the Qt library that Core uses, but not the version number of Core itself.

Please post the Armory log files.

It's unable to open another blk*.dat and rev*.dat file to store the blockchain. How much free disk space do you have?

The wallet manages all of that for you. There is no need for you to know what your change addresses are or how to spend from them. The wallet will track everything for you, make the change addresses for you, and spend from them for you.

There are more things to consider than just whether the blocks that are produced will be valid. There are other concerns too. For example, segwit will likely reduce transaction fees. Thus a miner will be opposed to segwit since they will make less money in the short term if it activates. But at the same time, activating segwit can also earn them more money in the long term.

Soft forks only require miners upgrade. It means that soft forks are more likely to successfully activate as less people need to upgrade and that those who don't upgrade won't be kicked off of the network. The reason most miners need to upgrade is so that chain splits do not happen if a block that is invalid under the new rules is mined.

The remaining 5% could, in theory, maintain a separate blockchain but uses the same blockchain parameters as the main blockchain but with different consensus rules. Also, keep in mind that with a hard fork, basically everyone (miners and users) need to upgrade whilst with a soft fork, only the miners really need to upgrade.

When it comes to the blockchain, the "longest chain" means the chain that has the highest sum of the nbits (difficulty specifier in a block) fields, i.e. the chain with the most work. So technically reorgs will always go to the "most work chain", but that usually ends up being the longer chain (more blocks at the same difficulty means more work) so the misnomer "longest chain" is used.

You will need to always start Bitcoin Core with the -datadir option in order for it to know where the datadir is. It will not remember the datadir location from a previous run.

You will need to always start Armory with the --satoshi-datadir=<path> option (where <path> is the path to the Bitcoin Core datadir) in order for it to know where the block data is stored so that it can read the blocks and get other information to connect to the Bitcoin Core node.

Yes, BIP 148 is backwards compatible. All soft forks (including BIP 148) are backwards compatible and allow you to spend from transactions already in the blockchain. All hard forks will likely do this too since a hard fork that prevents people from being able to spend their money is not likely to gain enough traction to be activated.

You probably have a corrupt block. That means that you will need to redownload the entire blockchain.