You send Bitcoin to Coinbase as you would sending Bitcoin to any other person or service. Get an address from coinbase and send to that address.

You probably have to use their software to create the spending transaction. An input that spends any coins sent to that address would be of the form

Returned to where?

The change goes back to your wallet so you can still spend it. There is no need for you to send the change to the address(es) you are spending from. You will not always be spending from the same addresses or from just one address so the wallet will make a new one to send the change to.

Unless you had 320 BTC (which I highly doubt), your transaction would not have been able to have been made as you would not have sufficient funds. Your wallet is probably using the wrong units. Check your Exodus wallet. Any Bitcoin that wasn't sent to Electrum should still be there.

What are the transaction ids of your transactions?

Probably not. Your coins were never safe with blockchain.info anyways since they continuously have security and usability issues anyways. If a chain split happens, you won't be able to decide on which chain you want to transact on, blockchain.info will choose that for you.

I have already answered that question. Read the thread.

Try using https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4. I believe it was fixed in this build.

IMO there will almost definitely be a chain fork of some sort. If BIP 91 activates, it could very well activate with less than 80% hash rate and that can cause a chain fork. Even with 80% there could still be chain forks. If BIP 91 does not activate, then BIP 148 will activate and Bitmain's UAHF will also activate and that will result in chain forks too. I think that there will be chain forks, just that they may not necessarily be persistent and result in two blockchains.

That is expected behavior. Bitcoin Core will generate new private keys (and a new master HD key if HD is enabled) after you turn on encryption since the unencrypted private keys could have been exposed. The new keys will always be encrypted. Your previously used private keys will still be available so you can still spend any coins you had, but any keys generated after enabling encryption will be new to your wallet.

Yes. You can make transactions that send coins back to yourself. This is recommended as if the taint attempt fails, you still control the coins on both chains.

If the chains have cleanly split and there is no risk of one chain wiping out the other chain, then 1 confirmation is enough. However, I recommend that you wait for 6 or more confirmations before continuing.

Yes. You will need to have multiple wallets, one for each chain.

Yes.

If you do not care about your privacy, you can and should send all of the coins in your wallet. It does not matter where you send them, but I recommend that you just send the coins to another address in your wallet. Such transactions are allowed. There is no need to make an entirely new wallet for this.

Yes, Electrum will allow you to choose the chain that you want to use. You can do this by choosing the Electrum server which you connect to.

Yes. You will need two separate wallets and instances of your wallet software.

Running a full node is extremely simple; just download, install, and run Bitcoin Core.

Yes.

I will be writing up detailed instructions for that and either adding it to the Bitcoin.org alert or making a post here with those instructions. I have written the basic idea of the tainting method here: https://bitcointalk.org/index.php?topic=2012799.msg20104865#msg20104865. This method is also automatically done by Bitcoin Core since it will include a locktime of the most recent block when a transaction is created (with some randomness that allows for a locktime to be chosen that is up to 100 block behind). So long as the minority fork is more than 100 blocks behind and the transaction pays a high enough transaction fee, then this method with locktimes will work.

Bitcoin Core is not designed for you to be able to add and remove wallets at will. It is not designed for you to use wallets that are not in the Bitcoin Core datadir.

Besides the fact that Trezor and Ledgers do not work with Bitcoin Core, they also do not do anything with wallet files. Rather a wallet has to support the Trezor and Ledger hardware interaction APIs and send the device whatever data via those APIs.

Move the wallet.dat file from Bitcoin Core's datadir to your USB drive. When you want to use it, move it back to the datadir. Alternatively you can move the entire datadir to the USB drive but this will require your USB drive to have over 120 GB of free space and it will make Bitcoin Core perform much slower.

Blockchain.info used to have some way to export your private keys, but I don't think they have that capability anymore. Either way, if you want to be able to use your Bitcoin on all forks after a chain split, then you need to control your private keys and control which chain you are using. Using a web wallet like blockchain.info will not provide you this capability. The easiest thing to do would be to just get a desktop wallet (preferably a full node wallet like Bitcoin Core) and send your Bitcoin to an address in the desktop wallet. Then you will have full control of your private keys and be able to choose the chain(s) you wish to follow.

You control your private keys. Which chain you want to spend on only depends on the wallet software you use to interact with your hardware wallet. The hardware wallet itself does not know about nor does it care about the blockchain it is signing transactions for.

There is actually an amazingly simple way to "taint" your coins that I have only recently heard about. This method requires using transaction locktimes and may require a bit of advanced skill (most taint methods require that anyways).

To taint your coins, you need to make one transaction that is valid on one chain and invalid on the other. Since a chain split will likely result in one chain with a majority of the hash rate and one chain with a minority of the hash rate. The chain with the minority hash rate will produce blocks at a slower rate so it will be at a lower block height. Thus you can make a transaction which has a locktime of the most recent block on the chain with the majority hash rate. This means that the transaction will be valid and can be mined on the majority hash rate chain, but is invalid on the minority hash rate chain until it's most recent block height matches the locktime that you set. Once your locktimed transaction confirms on the majority hash rate chain, you immediately make a transaction which spends the same inputs but does not have the locktime and get that confirmed on the other chain. This second transaction will be invalid on the majority hash rate chain because it conflicts with one that has already confirmed, and if the transaction confirms on the minority hash rate chain, then your coins will be successfully split. You can then spend from those transactions on their respective chains without any risk of transaction replay as any transactions that spend from those will be invalid on the other chain.

Then that is a problem with their service and users here cannot help you. If their support does not answer you or does not do anything to rectify the problem, there is nothing that users here can help you.

You can most certainly make a large number of transactions with a small amount of Bitcoin. Testnet does not have very high transaction fees and Bitcoin is extremely divisible, so just make a lot of small transactions.

You can also use the Regtest network which is just a private test network. You can mine your own coins on it from the very beginning of the regtest blockchain so you will get 50 regtest coins for each block.

Coins at rest means that the coins are not being transacted. This could be in coins in cold storage or just that you are not making or receiving any transactions. Any coins that are from a transaction that was confirmed before the fork or are sent in a transaction that was confirmed before the fork are fine. However any coins in an unconfirmed transaction during and after the fork may not be.

Likewise if your fees are too small then players won't come to your site since they won't get their money withdrawn quickly.

Do not use fixed fees. That will likely result in your transactions remaining unconfirmed for a long time. When that happens, you will likely also end up spending from those unconfirmed transactions and make long chains of unconfirmed transactions. When that happens, you will end up making it impossible for anyone to actually get their money off of your service since it is all tied up in long chains of unconfirmed transactions.

If you really do not want to use a dynamic fee rate which will almost always has you pay a sufficient fee for your transactions to actually confirm, you can set a fixed fee rate using the settxfee RPC command. This command allows you to set a fee rate in BTC/kB and your transactions will use that fee rate.

Also, to avoid paying a lot in fees and making a lot of transactions spamming up the network, you should batch your transactions. That means that instead of making one transaction for each withdrawal that a person makes, you instead periodically, say, once an hour, make one large transaction with all of the withdrawals that have been made since the last batch transaction. This allows you to reduce the number of long unconfirmed transaction chains, reduce the number of small change outputs that you need to make, and ultimately reduce the transaction fees that you are paying.

No. They aren't even safe to use normally.

There are two lines that you want to change: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L100 and the line after it (101). Change those two lines so that the time is just 0 and that will disable segwit for your build.

Edit: Do this at your own risk. There may be unintended consequences of doing so as 0.13.1+ was designed without any segwit disabling capabilities in mind. You may end up partitioning yourself from nodes that will give you blocks in the non-segwit format.