What version of Armory and Bitcoin Core are you using (do no just say "latest", give a version number)?

In Bitcoin Core, go to Settings > Options and click the button "Open Configuration File". Add txindex=1 to the text file that is opened and save it. Then restart Bitcoin Core, it will say that a reindex is required, click OK. The blockchain will be reindexed and the transaction index will be built so that you can request any arbitrary transaction.

Yes, you are.

The lightning network is useful for paying the grocery store or your landlord because you do so on a repeated basis. Instead of making 1 on-chain transaction for every single payment to the grocery store or to your landlord, you can use LN to essentially batch your payments so you are paying them but only need to make 2 on-chain transactions over a course of a year, for example (instead of 12 monthly rent transactions).

Furthermore, your landlord or your grocery store is likely to be a hub with many open payment channels with other people. So if you wanted to pay someone or receive money from someone, instead of making an on-chain transaction to pay that person or making a payment channel with them, you can route a payment through your landlord or your grocery store to that person. For example, say your neighbor wants to pay you some Bitcoin. He can either make an on-chain transaction sending you money, or he can use his currently open LN payment channel with the landlord and route the payment through the landlord. This essentially means that he gives the landlord money over his payment channel with the landlord and then the landlord sends you the same amount through your payment channel with the landlord.

The dbcache is used for holding the UTXO set in memory. Once the dbcache is full, the UTXO set will be flushed to the disk. Having a higher dbcache means that it is flushed less so it will reduce disk IO from the UTXO set side of things. However during the syncing process, blocks are being written and deleted from disk so that is a major source of disk IO and slowdown.

It is entirely passive. Nothing needs to be sent anywhere nor registered anywhere.

You do not need to be fully synced to create an unsigned transaction. However if you are not fully synced, you could potentially have a problem where the inputs that you are spending are already spent in a transaction that is later on in the blockchain. If you are already fully synced, you can go offline briefly to make the transaction, but I don't see why you would want to do that because nothing is ever transmitted for an unsigned transaction.

You have to expose your Bitcoin addresses in order to receive Bitcoin to spend, so no, that's not really possible. If you ignore that, then yes. In fact, you will always only expose your addresses (ignoring the receiving part) when you broadcast a signed transaction.

Note that it is practically impossible to figure out the IP address of the node that a transaction originated from. Transactions are not tied to IP addresses and Bitcoin addresses are not tied to IP addresses. The IP address that you see on block explorers like blockchain.info are the IP addresses of the node that first relayed the transaction to blockchain.info's node. That node is most likely not the node that created the transaction.

Increase the size of the dbcache by starting Bitcoin Core with the -dbcache=<n> option or adding dbcache=<n> to your bitcoin.conf file where <n> is the amount of RAM in MB that you want to dedicate to the database cache. Increasing this will reduce the amount of disk IO that is done as the database will be flushed less frequently. A dbcache of ~6000 should allow the entire database cache to be held in memory so only on flush is required.

You are not understanding correctly. The previous system was much much slower than the current one. Just because you are experiencing this issue does not mean that everyone else is too and that the process must be slow for everyone. The original design was way worse and performed horribly compared to the current system.

Do this, but instead of killing it, start ArmoryQt. Also remove --cookie from your command.

According to your logs, it was able to parse all of the data but for some reason everything it did was not saved to the database. You may have killed the process too early before everything was done.

No, that has nothing to do with fee estimation. In order for the fee estimator to work, you need to have your node be one for some time. It needs to have received several blocks with a mostly up to date mempool in order to actually estimate fees. This is because it will compare what in its mempool got into a block and how long that took to happen, so it cannot use historical blockchain data.

Payments to one person do not necessarily have to follow the same route. A different route can be chosen to route around the fact that someone has closed a channel. One person closing a channel in the route just means that that route can no longer be used. All of the other channels in that route can remain open.

You should use Armory 0.96.3. That should fix your problems with Bitcoin Core 0.15.0.1. There are known issues with older versions of Armory and Bitcoin Core 0.15.0.1.

If it is not part of the JSON-RPC 2.0 specification, then Bitcoin Core probably does not support it.

No. Payments are not dependent on channels remaining open after the payment has completed (i.e. the HTLCs have been fulfilled).

Segwit2x and Bitcoin Gold are two completely different things.

Both are hard forks and they are set to activate by block height. Because they are activating by block height, predicting the actual time of activation is somewhat difficult. There is no pre-announced date of fork because that date is not concrete.

Bitcoin Gold will fork at block 491407.

Segwit2x will fork at block 494784.

What version of Armory are you using (don't just say latest, give a version number)?

Do not close that command prompt or Armory will not work. It is a prompt for a background process that Armory runs and it must stay open for that to work. Do not close it, Armory should close it for you when you stop the wallet.

Yes, that is certainly possible.

You should not use that website, they are known to have issues in the past where people have had their money stolen when they used vanity addresses generated on that site. Even if they are not scammers, you should never use a service where they generate a private key and give it to you to use; you never know whether they are holding on to that private key and can thus steal your money in the future. You should instead use local vanity address generation software like vanitygen: https://bitcointalk.org/index.php?topic=25804.0. Or you can use a service which uses split key vanity address generation. Split key generation keeps your private key private, the person generating the address only has part of the private key and they can't get the full private key.

These are called vanity addresses. They are made by randomly generating addresses until one is found by chance to have a prefix that you want.

For privacy and security reasons. It is recommended that you do not reuse addresses, so every time you want to get an address to give to someone, your wallet will give you a new address. Your old addresses will still work, just that your wallet knows it has already given you that one, so it gives you a new one. This helps preserve your privacy and makes it easier to keep track of your coins. It can also help protect your coins in the event that ECDSA is broken.

This topic has been moved to Trashcan.

Duplicate

This topic has been moved to Trashcan.

Duplicate

There is no such thing as a "WIF file". WIF is not a file type, it is an encoding for private keys. You can get your private keys from Armory is WIF format by going to Wallet Properties > Backup This Wallet > Export Key Lists. The WIF format private keys are labeled as PrivBase58. You should also check the box "omit spaces" at the bottom of the window so that the keys can be easily imported.