Use Armory 0.96.3

You have the backup phrase. Restore your wallet from that backup phrase. That's what the backup phrase is for.

Just because you don't know what you are doing does not mean that all is lost. Just because you don't know what you are doing does not mean that no one else knows what they are doing.

You will get addresses when you get a wallet. The wallet software will handle all of that for you.

It sounds like you sent USDT to a Bitcoin address. USDT is not Bitcoin and is incompatible with Bitcoin (although apparently it uses the same address format). It is possible to recover your coins, but that is very difficult and requires handling private keys and installing a USDT wallet. However it seems like you sent USDT to Coinbase, and it is likely that they are not able to do this. Besides the fact that it requires a lot of work, their private keys may not necessarily be accessible to be imported into a USDT wallet. Your coins are probably lost, and there certainly is no transaction that is stuck.

You paired in the wrong direction. If you scanned a QR code or entered the backup phrase from your computer onto your phone, then that is wrong. You should have entered a backup phrase from your phone onto your computer.

No, that is not how unspent outputs works. The final balance would only not be the same as amount received if you have spent any Bitcoin.

Some other mining pools may also offer acceleration services. I don't remember. However any mining pool operator can accelerate transactions for you.

You don't have to, but I recommend that you do.

It depends on your hardware and network connection. It can take anywhere from a few hours to a few days.

Use your own account system. Use an external database to handle your accounts and what each person's balance is. Don't try to make each address belong to certain accounts (the Bitcoin Core accounts system doesn't really work like that anyways). Or you can use the multi-wallet feature and have each wallet be an "account". However Bitcoin Core may not be able to handle hundreds or thousands of wallets with multi-wallet. It really is not designed for that use case.

Yes. The accounts system (and thus the move command) is slated to be removed soon.

Yes.

If you have not received any coins after the time that your wallet is synced up to, then no.

No. BCH is an altcoin and anything that happens on BTC has no effect on BCH and vice versa.

You need to get a BCH client that can read your wallet file or you can import your private keys into. You can use the Bitcoin Core analogous software for BCH which is Bitcoin ABC.

No.

Node policy has changed since 0.8 which makes some transactions that 0.8 may produce (just due to randomness) to be non-standard and thus not likely to propagate well. Furthermore, fee estimation has changed to be much better, and priority has been removed which will also effect how your client sets a transaction fee so you may end up paying too low of a fee for your transaction to confirm quickly. I highly suggest that you upgrade to Bitcoin Core 0.15 and let it fully sync. You can use pruned mode so that it takes up only a few GB of space instead of 140+ GB.

Those two services are owned by mining pools. They can choose the transactions that they want to include in a block. Usually these are chosen by transaction fee rates, but they have custom changes (or are using Bitcoin Core's prioritisetransaction command) which allows them to make a transaction be more likely to be chosen by their transaction selector so it will confirm sooner by being included in one of their blocks.

move is a deprecated command that only effects Bitcoin Core's internal accounts system. The accounts system is deprecated. All that move does is that it changes some entries in the internal accounts system. No transactions are actually made.

Loads fine for me.

This thread is attracting a lot of spam and very little thoughtful discussion (besides the fact that the idea is complete nonsense). Therefore it will be locked.

This thread is attracting a lot of spam and very very little thoughtful discussion, so it will be locked.

Not necessarily. A lot of exchanges have not said whether or not they are supporting Segwit2x and what they are going to do about it. I don't think many exchanges will list Segwit2x as Bitcoin as many people have threatened to sue them, and at the very least, it will be some very bad PR for them.

First of all, it is not a 2 MB fork, it is an 8 MB fork. Calling it 2 MB is disingenuous.

Why should Core do something that we believe is harmful to the network? Sure, it might avoid a split now, but it can have huge negative consequences in the future that we want to avoid.

No. Miners do not control Bitcoin. Just because the hash rate moves does not mean that Bitcoin is redefined to whatever the hash rate wants. The hash rate will follow whatever makes them the most money (unless they are insane). If few users are using Segwit2x-coin and few exchanges list segwit2x-coin, then miners won't mine it for long as there is no money to be made there. Even if they did go to Segwit2x-coin and stuck with it, Bitcoin Core could do a counter hard fork which both implements a Proof of Work change and implements a lot of features on the Bitcoin hard fork wish list which Segwit2x has thus far refused to do.

This is just not true. Please stop spreading FUD.

Blockstream does not control Bitcoin Core; out of the five people who have commit access, only one person is a Blockstream employee (and founder). The others either work for their own companies that they founded or are part of the MIT DCI. In all contributions this year (since Jan 1 2017), there have been 41 contributors. Of those, I count 8 Blockstream employees or contractors related to Blockstream (of which at least 3 are founders of the company, and 2 don't really seem to work for Blockstream but are listed on their website), 2 that work for the MIT DCI, 6 Chaincode Labs employees (one person overlaps with Blockstream) and 22 people who work for other companies (only one or two per company), work for their own companies that they created, or are independent contributors contributing whenever they feel like. Many of the Blockstream contributors contribute rarely and also do so when they feel like; they are not paid to work exclusively on Bitcoin Core.

Blockstream does not need to influence or change Bitcoin in order to have products. They already have the Liquid sidechain which is a product for exchanges and it does not need Segwit or other changes to Bitcoin's consensus rules. This sidechain was already in use before Segwit activated.

Do you not think that maybe he has spent those coins? Maybe he speculated in the early days and lost money in the number of scams and exchange collapses (e.g. MtGox) which leaves him with little to no Bitcoin today. Luke has a family (a rather large one too) which he has to support; do you not think that perhaps he has used many or all of his Bitcoin to help support his family and do other things which require money?

Luke is not a full time employee of Blockstream; he is an independent contractor. I don't think he is paid much for doing that considering that he has not done much for Blockstream and is not being paid by Blockstream to work on Core (according to some conversations I have had with Blockstream employees).

As I said earlier, that is not true at all. Blockstream is not the only company paying people to work on Bitcoin Core and they do not control Bitcoin Core.

Source? IIRC the only "okay" increase was up to 4 MB, which is what Segwit does.

The fact that it is being done by an agreement made by a bunch of corporate executives and miners in a backroom deal without consulting the community or the technical community (which includes much more than just Bitcoin Core developers).

It is not the storage requirement that is the problem, it is the bandwidth and computing requirements. Clearly you do not understand the nuance and other consequences of a block size increase. It not only requires more disk space (which is trivial) but it also requires full nodes to consume even more bandwidth and data and may not be able to support larger blocks. So we would see a decrease in full nodes from a number that is already pretty low, less than 10000 full nodes. A full node consumes somewhere around 300-500 GB of data per month, and that is with 1 MB blocks. With segwit, that size will be even larger, and with 2X, potentially more than double. In the worst case, it would be 8 times that amount. In the US, some ISPs (like Comcast) are instituting data caps at ~1 TB of data per month. Bitcoin nodes are likely to be consuming nearly all of that data (thus restricting the amount of data that home node operators can use for other things) or even exceed the data cap if Segwit2x were to pass. This will cause the entire network to lose nodes as users turn them off so that they have enough data to do other things that consume a lot of data, but not as much (e.g. watch 4K Netflix).

Furthermore, larger blocks can require more computation to validate and thus a malicious block that takes several seconds (which is ages in computer time) to validate now would be even worse if the block size were to be increased even more.

Lastly, there are many other considerations that you need to look at when increasing the block size. Things like UTXO set growth, initial sync time, hardware requirements, etc.

Yes.

Yes, in theory. It has not happened yet.

Not necessarily.

Yes.

The vast majority of altcoins use ECDSA. Any coin that is based off of Bitcoin Core will likely use ECDSA. Litecoin certainly uses ECDSA.

I don't know. Digital Bitbox themselves do not really offer a wallet to use. So it depends on all of the other wallet developers to support it.

There is no pool of 2^160 public keys. It is a pool of 2^160 addresses, not public keys. There are 2^256 private keys and each private key has exactly one public key, so 2^256 public keys. Each public key can be represented in two ways, in uncompressed form and in compressed form, so there are 2^257 representations of all public keys. Each representation of a public key corresponds to exactly one address because it is a hash of a representation of a public key. Because of the pigeonhole principle, more than one public key can correspond to the same address (and thus an address can have more than one corresponding private key).