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.

The latest wallet format is compatible with Bitcoin Core 0.14.0+.

The benefit of the HD wallet is that you can make multiple backups and still have your old backups be relevant and useful. With non-HD wallets, a backup will become useless when you use more addresses than what was in the keypool of that backup. With HD wallets, that is no longer the case. Although the keypool might run out at first, you can extend the keypool to be thousands of keys so that an older backup can still be used to restore all of your keys.

Also, Bitcoin Core will soon have the option to upgrade a non-HD wallet to an HD wallet (soon being hopefully 0.16). This will mean that once you upgrade your wallet to be an HD wallet, all new keys will be HD and you will still have your non-HD keys in the wallet so you can continue to use your wallet normally. It does mean that your old coins are not protected by the HD functionality, but your new coins will be, and as you transact and make change, your old coins will transition to the HD keys as well.

If you have a lot of RAM available, you can set -dbcache=<n> where <n> is an amount of RAM in MB that you would like to dedicate to the database cache (note that this is not the only RAM usage by Bitcoin Core). This generally helps sync faster as the database will not need to be flushed to the disk as often so there is less disk IO to slow you down. Blocks will still need to be written to disk and that will likely still be a bottleneck, but the database won't be written as often and that writing is usually the bottleneck because of some things that LevelDB does during flushing.

You don't really need a library for RPC calls; the RPCs follow the JSON-RPC 1.0 specification (and maybe 2.0 too). It's just an HTTP server which you send JSON formatted text to and get JSON formatted text back.

The Ledger Nano S does not communicate with your computer or retrieve any data from it during the setup phase, which includes seed generation. The secure element on the Ledger (an url=http://www.st.com/en/secure-mcus/st31h320.html]STMicroelectronics ST31H320[/url] chip) has its own AIS-31 Class PTG.2 compliant true random number generator (you can look up what the spec for that is). This TRNG has its own entropy source(s) and does not need anything from your computer except power. You should be able to just connect your Ledger Nano S to your computer using a power-only USB cable and it will still work.

None. You can have a basically infinite number of addresses.

No, old addresses are not deleted or replaced. You just keep generating more and more.

The 100 addresses thing is actually a lookahead keypool, mostly useful for backups. Basically, 100 keys are generated, and when want a new receiving address, it gives you one of those 100 keys and generates another one to replace it in the keypool. The one given to you is removed from the keypool and held onto elsewhere as a "used" key. Keys are never deleted or replaced so you can have hundreds or thousands of keys used in your wallet.

Go to the debug console and use the getwalletinfo command. That will tell you how many keys are remaining in your keypool. The keypool is refilled every time you unlock your wallet, so it should be 100 keys (it may be 1000 if you are using Bitcoin Core 0.15+). I don't think there is any way to see how many keys have been used, but that shouldn't be hard to implement.

It looks like too many things are changing for Bitcoin Gold support, so no, probably not.

Any coins you use to fund the channel with and that you receive while the channel is still open will be "locked" to that channel. However you can still pay other people by routing payments through other open payment channels that people have with each other, hence it is called the Lightning Network.

You can have 0 coins and have the other person in the channel fund the channel. This means that they are paying you, and if you have to pay them, you can only do so after they have paid you.

There is a peer discovery mechanism described here: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md

Peer selection is done by IP address and presumably uptime just like how Bitcoin peer selection is done. Physical location does not matter.

Fees are only used for HTLCs for routing payments. IIRC they are negotiated by the nodes participating in the routing of a payment and are set by the nodes themselves

Probably.

The vulnerability required physical access to the device and destruction of the casing, so it would only occur if someone stole your Trezor. The vulnerability has also been patched with a firmware update (for older devices) and a bootloader update (for new devices; the bootloader cannot be updated outside of the factory).

No, where did you hear that? You can restore your recovery seed without any risk or damage to the device. They are designed for people to be able to restore seeds and then wipe them later to allow for people to recover coins from lost devices.

Your coins after the hard fork will be associated with your change addresses. All of your private keys and addresses are managed by your wallet. Because there is a Bitcoin Core based software for each fork, you can take your Bitcoin Core wallet and use it with those software after the fork to retrieve your coins. There is no need to handle raw private keys by yourself or do any sort of importing.

Your coins are in change addresses, not wallets. Addresses and wallets are very different things.

You don't need to see your change addresses; that is not necessary. If you really want to, you can go to the debug console and use the dumpwallet command. This will export all of your addresses and private keys to a plain text file which means that anyone who gets that file will be able to steal your coins regardless of whether your wallet has a password or not. Note that this file IS NOT the wallet.dat file and you SHOULD NOT name the file exported "wallet.dat

Make sure that you have a backup of your wallet from before the fork. Then make another backup of your current wallet file. Now go to the Bitcoin datadir and delete everything inside of it. Copy your wallet backup from before the fork into the datadir. Then start Bitcoin Knots and let it resync the entire blockchain.

Bitcoin Core is not a library, so if you are looking for something to use as a library in a software, then you should not use Bitcoin Core. If your application can work without directly calling things as in a library but rather just use Bitcoin Core's RPC commands, then Bitcoin Core may be better for you. With the RPC commands, you can write your software in whatever language you want.

IIRC Bitcoin Core is far faster and less resource intensive (i.e. less memory usage) than BCoin because of the difference in programming languages (JS, vs C++).

It means exactly what it sounds like, the transaction output has been spent or it has not been spent (unspent). Bitcoin works on transaction outputs, not addresses or balances of addresses. When you spend Bitcoin, you are actually consuming a transaction output. This is known as spending a previous transaction output. The coins that are spent go into new transaction outputs which are then spent by the receiver when they want to spend the coins.

Bitcoin Core only shows the amount that leaves your wallet or enters your wallet. The 1 BTC did not leave nor enter your wallet, but the small transaction fee did, so that is what is displayed.

That's because of change addresses. You should never use a block explorer to check your balance.

Yes.

What are the specs of your machine (CPU, RAM, Disk type, etc.)? With the initial sync, other than the internet connection, the next bottleneck is usually the disk (hard drives are much much slower than SSDs) or the CPU (it does a lot of computation).

If by sub wallet you mean addresses, yes. Each address has its own private key. There is no such thing as a "sub wallet".

There is no need to move any coins before any fork in order to get coins after the fork.

Those APIs are not Bitcoin's APIs but rather specific service APIs. This is a problem for services and something for them to deal with, not the Bitcoin network.

This is not a vulnerability. This is simply btc1 nodes (which will fork off in a few weeks) pretending to not be btc1 nodes because they do not want Bitcoin Core 0.15.0+ nodes to disconnect from them. They fear that they will be disconnected from the network before their fork happens and don't want that to happen.

However not everyone is running Bitcoin Core 0.15.0+ so they will still be able to connect to the network via peers running older versions of Bitcoin Core. Furthermore, this behavior is bad for both networks; following the fork, they are far more likely to find themselves isolated from their network. They will be rejected blocks from their Bitcoin Core nodes because of the fork, but won't have any connections to other btc1 nodes so they can follow the segwit2x chain.

Only altcoins that will fork from Bitcoin in the future. Other altcoins are consensus incompatible with Bitcoin, so they could connect to Bitcoin nodes, but they will experience the same problem that btc1 nodes will face after their fork: they have no connections to nodes that are following their consensus rules.