They don't want their nodes to be disconnected from the rest of the Bitcoin network. However this commit really just does them more harm than good.

btc1 implements a preferential peering policy like Bitcoin Core does for segwit. However that policy relies on the service bit, so by disabling the service bit means that they a) won't be disconected by Bitcoin Core 0.15 and b) are less likely to be able to find other btc1 peers so when the fork happens, they are even more vulnerable to being isolated from the network.

This change really is an emotional reaction to Bitcoin Core 0.15's disconnection of their nodes.

Search for wallet.dat. That is your wallet file and it is located in the datadir. When you copy the datadir to a new computer, make sure you do not copy the wallet.dat file.

Bitcoin Core 0.15.0 will disconnect (note disconnection is not the same as banning) any peer which has the segwit2x service bit set. The reason for doing so is to avoid a sudden change in network topology at the time of the fork. It allows Bitcoin Core nodes to ensure that they are connected to other Bitcoin Core nodes and btc1 nodes to ensure that they are connected to other btc1 nodes prior to the fork so that when the fork happens, some nodes (either btc1 or Bitcoin Core) don't find themselves suddenly isolated from the reset of their consensus network. It makes the fork happen more smoothly so that btc1 nodes are not surrounded by only Bitcoin Core nodes (and thus be isolated) and vice versa.

If you are counting all rounds, then it's 192 rounds. The first SHA256 requires 128 rounds (because the header is larger than 512 bits) and the second only requires 64 rounds (because it is hashing the 256 bit hash).

Nothing looks wrong with your node. It is likely that bitnodes' crawler is just unable to connect to your node for some reason so it thinks that you are no longer on the network. However bitnodes is not definitive and it is fine if your node is not listed on their website. You have multiple connections to the network and are clearly in sync, so everything is fine.

The reason your connection count is so low is likely because your node appears to be IPv6 and TOR only. This means that you are very limited to the number of peers that you are able to connect to (not many use IPv6 or TOR).

The first time you started Bitcoin Core, you were prompted to choose a datadir. If you did not choose a custom one and left the default, then it will be in C:\Users\<your username>\AppData\Bitcoin

This topic has been moved to Trashcan.

Duplicate

The software does not care about any abbreviations. Armory will be using BTC for any Bitcoin denominated things. The abbreviations are a human abstraction, the network doesn't care.

The second sha256 hash is only hashing 32 bytes (the result of the first sha256 hash) so there are only 64 rounds for that.

Note that the difficulty IS NOT determined by "number of 0's" but rather that the target must be less than a certain value. This happens to result in the hash having a lot of 0's in front of it, but that is not actually what is being checked.

Also, the hash that is actually produced is the byteswapped version of what we actually see presented to us. I'm not sure if that effects this.

No. Bitcoin is not fiat and is not part of the traditional banking system. You must convert your Bitcoin to your local currency before you can deposit the money into a bank account. You can do that through various online exchanges.

Don't use a bootstrap.dat file. It will still take a very long time. Rather you can just copy and paste an existing datadir (all you need is the blocks folder and the chainstate folder) to the new machine. This is by far the fastest because the blockchain and its state have already been verified and that information stored in the datadir, so your new node will just use that already-done verification.

It does not always work and it only works for a select few addresses. Given a random address, it is unlikely that you would be able to identify the wallet that it belongs to.

For some addresses, you may already know who owns the address because the owner has publicly shared that they control it. From there, you can link addresses together if they are inputs to the same transactions. However this method is not foolproof and is easily fooled by things like CoinJoins.

You cannot identify what wallet an address is part of nor can you identify which wallet software created an address unless you are the creator of the address.

There is no straightforward way to decrypt it because the decryption is not used anywhere (although implemented) in vanitygen. Just don't use the -e option and the private key will be in unencrypted form.

Read the thread, I already explained above.

No, it is held under the '3' address.

Addresses and public-private key pairs are different things. A public-private key pair can be associated with many different addresses, not just one '1' address.

It uses segwit.

Segwit has lower transaction fees.

Trust is not moderated nor does trust have to be related to violating forum rules. Forum rule violations result in bans, not negative trust. Trust is a community thing and anyone can leave positive, negative, or neutral trust for any reason they want.

Use the "Report to moderator" feature to report posts and users to moderation staff.

There already is a standard: the one that we have been using for the past several years. Messages shouldn't really be "signed with an address" or verify to an address since addresses really correspond to a specific output script whereas signed messages (signed anything really) corresponds to a public key. P2PKH and P2WPKH addresses also happen to correspond to a public key so people found it simpler to abstract "signed with public key" to "signed with a public key that corresponds with this address". P2PKH addresses can easily be translated to a P2WPKH. But message signing and verification really shouldn't have anything to do with addresses, rather it is all about key hashes which P2PKH and P2WPKH both use.

That is almost impossible to know. Such information is not part of the transactions nor the blockchain. The only way you would know is if you have logs of everything that happens on your server. (e.g. access logs, all commands that were typed, all programs executed, etc.). Bitcoind may log some of the RPC commands (it might depend on your log level) so you can also check there. Otherwise, no one can know if the coins were sent from your server or from someone stealing your private keys and making the transactions elsewhere.

No.

No, did you not read the posts above yours? The private keys cannot be determined from the public keys, and you need the chaincode with the private keys in order to derive any other private keys in your wallet.