Bitcoin-cli requires authentication from the user. To set the username and password, you need to set up a configuration file. To simplify the process, you can use this site[1] to generate the parameters.

While using Bitcoin-cli, you need the following arguments: -rpcuser= - rpcpassword= and -rpcport=.
[1] https://jlopp.github.io/bitcoin-core-config-generator/

In normal circumstances, orphan occurs when block A and B are produced at the same time and that a portion of the network is building on Block A and the other is building on Block B. The miners will compete with each other until either of the sides find a block. This further extends the network and thus one of the forks now have a larger accumulated proof of work. The longer fork will supersede the shorter one. The problem with this is that nodes won't register (AFAIK) block B after they've received block A. Hence, you would need to have a very good connection to the network and a modified client to see all of the orphans that is on the network.
IIRC, the longest fork I've seen was during the 2013 hard fork and that lasted >30 blocks. Normally, the orphans should not go beyond 6 blocks.
The orphan blocks are stored within the Bitcoin database. Parse the database and you should be able to sieve them out.

Multibit is insanely old and discontinued. Multibit classic isn't a HD wallet and thus the wallet generates and manages the private key individually. From the key file, if you open it using any text editor, you should be able to see your address and the private key should be beside it.

Keep the key file and your private key safe. Using Electrum, generate a new wallet and take note of your 12 word seed. Click on the wallet tab at the top left and go to Private Keys > Sweep. Key in your private keys and press sweep. The coins should be automatically transfered to your new wallet. Keep your seed somewhere safe.

It really shouldn't come as a surprise at all. It's a common practice for the various major corporations to share information about your behavior and your activities. It's to their interest to use the identifying information to identify the various high risk individuals and improve their security. Everything is clearly outlined in their privacy policy and it should be assumed that all your personal information is easily accessible.

Unless you're using an OTC exchange which can guarantee your privacy, you should assume that your personal data is getting shared.

The loan has been repaid. For the sake of transparency, here's a SHA256 hash of the TXID of the repayment. I'm not exposing the actual TXID as he has requested for the transactions to be kept confidential.

Hash: f28614f07b16b0ed031e1999e5f043655f57c600cace4c7e3f387654564b71f9.

No. Running it headless means that the Graphical User Interface (GUI) is not used and that it can only be controlled using the command line. The lack of the GUI means that it would take lesser resources to run it. Switching off the screen or unplugging it won't do anything as the GUI would still be running. You have to run it from command line.
The synchronizing and verification process is rather tedious and it isn't uncommon for it to take a few days to synchronize. It's highly dependent on the hardware that you're synchronizing it on. You can try to speed up the process by optimizing the parameters like the dbcache etc.

Yes. The larger block means that there are more transactions to be validated individually. It would naturally be slower.

The block header is hashed to form the block hash and that has a few more variables like timestamp, ver number etc. Transactions do not have to be ordered by their timestamp either.

The proposal that you stated would introduce would be detrimental to the network. Firstly, if the miner were to decide how much to mine, those who has a huge hash power could generate blocks with low reward and thus low difficulty. This effective makes the block interval much much faster and that the others would likely generate a lot more orphans.

The principle of mining is that whoever has the most resources should be able to decide and secure the network. If you were to be able to generate a block with little hashpower, it would be pointless for anyone to wait for 6 confirmations. Block reorgs would happen much more often and that it would be unsafe for people to trust transactions without waiting for thousands of confirmations.

It would also be quite tough to ensure a fixed distribution of the coin. The ability to choose the block reward would result in an uneven distribution of the coins over time.

If the mempool is more than 2MB in size at any given time, you can forget about getting a confirmations for any transactions with a small fees/byte, much less a 0 fee transaction. The propagation of 0 fee transactions should be quite bad, given the fact that most nodes have already stopped accepting it. The only way for it to get accepted is to mine your own block (I doubt any miner would accept a 0 fee transaction from others).

You can try experimenting it and enable opt-in RBF. You can bump the fee any time you want to stop trying.

It's not uncommon for coins to originate from the same place even if they are for different people. I doubt any legitimate gambling sites actively trace the addresses for linkage.

Why would it be? Are you using his account to get the deposit address? Unless you're accessing the gambling site directly from your own computer, the IP address won't be linked. Bitcoin transactions does not have IP addresses linked to them. Using a mixer is really not complicated at all and it's really useful to get rid of tracing.
It's of course better to take the longer route. It probably won't be an issue but its good to be safer.

The whole situation really depends on the interpretation of the gambling website. If you are using the same exact address to deposit to different accounts, it could seem like you're having multiple accounts. If they're reasonable enough, they should be able to tell that you're different people by the IP addresses, withdrawal addresses etc. They still have the rights to assume that you have multiple accounts based on the input address alone.

Sending the coins to another address before sending it to the gambling site does not break the linking chain at all. Your coins can still be traced back to the origin address. If you want to remove any linkage to the original address, you can use a mixer like the one in my signature. It makes tracing the origin of the coin much more difficult and nearly impossible.

Given the amount of exposure that emails could get even without it being compromised, I don't believe that having leaked email is that big of a deal. Sure, it does infringe on your privacy and makes you a target for spear-phishing. But I treat an email address the same as my physical house address and assume that it is already exposed and take extra precautions when looking at possible phishing email. It's more dangerous with leaked passwords but as long as you don't use the same password across all your accounts then you're less vulnerable.

Its a whole different story if your identity information got leaked.

The command should be correct. Were you facing the same problem with your initial initialization of the client?

There were some instances whereby the client would refuse to connect to the peers due to a corruption in the loading of the database. Try backing up your wallet.dat and clear your data directory and try to synchronize the client again.

I've been using Gemini for some time. The fees on the exchange can be rather steep, at roughly 2%, assuming you are purchasing at larger volumes. The exchange has a comparably lower volume as compared to the other exchanges. The design is easy enough to navigate around but I wouldn't recommend using it as an exchange if you're a frequent trader.

What client are you using? For certain wallets, they tend to spend all the UTXO at the same time to enhance privacy. It helps to reduce the number of UTXOs that the wallet would have to handle and consolidate all the unused coins into a single UTXO. Electrum does this and it can be changed in the settings.

Otherwise, for Bitcoin Core, you can manually choose the UTXOs to spend.

Check your anti-virus and firewall if they are blocking connections. The client can't seem to even connect to the fallback nodes and it seems like something is blocking it.

Have you tried manually adding the nodes? Choose the IPs from bitnodes.earn.com and go to Window>Console and type in addnode (IP HERE) add. Replace the (IP HERE) accordingly.

Yes. Running Bitcoin Core would take a significant amount of ram, if you decide to have more peers.
The newest RPi offers significant improvement over the previous versions in terms of ethernet speed, CPU and memory speed/space. The similar pricing would just make it a no-brainer to go for the newer version.
Passive cooling would be enough, if you choose to run it without much load. The heat sinks are relatively cheap and it wouldn't be a bad idea to get one if you plan to run it for long periods of time.
That's up to you. A plastic one would do, just make sure it is compatible with your heat sink.
256GB would be an overkill. I wouldn't recommend storing the blockchain on an SD card since the size would only increase from now unless you plan to prune it. Even if thats a non-factor, the heavy read/write cycles could potentially shorten the lifespan of your card.
IIRC, it is possible to use a thumbdrive to boot but a simple 16GB sd card would be enough. I would recommend you to get an old HDD to store the data directory in. It would be much cheaper than a huge sd/thumbdrive and it would last a lot longer. You might need to get external power to it though.

---

---

You should pre-sync the blockchain on a desktop computer first. The synchronization time for an under-powered device like the raspberry pi would be insanely long. It would be better for you to just copy the data directory from an already synchronized full node to your raspberry pi storage.

The main problem is that China has a significantly cheaper labour cost and electrical cost due to their proximity to renewable energy sources. The fact that the biggest ASIC companies are all based in China also help to cut down their expense significantly. Given the cost of shipping the ASICs overseas with the effort required to find another suitable place, I doubt that the network would recover that well.

But realistically, China wouldn't ban Bitcoin mining. It does still contribute to the economy in general and their stance is just to avoid dealing with Bitcoin as a commodity.

When you receive a transaction, the transaction will appear in your wallet instantaneously (without any confirmations). By default, you can only spend the inputs after one confirmation and that isn't changeable. You can only change it with a change to the source code and building it yourself (AFAIK). After one confirmation, your wallet will be able to choose that input to be used.

It shouldn't be that much of a problem since a confirmation is relatively safe from double spending and there is no problem with you spending a transaction that has only one confirmation. You can always choose to select the inputs to be spent using the coin choose feature in the wallet.

Yes. Bitcoin Core's recommended fee is derived from your client's perception of the network's condition (ie. Having a more busy network would naturally require a larger fee per size since miners prioritise the higher fees.)

One confirmations is more than enough for most transactions. The more confirmation there is, the harder it is to reverse the transaction.

You don't have to use and external site to calculate your fees. When you want to send Bitcoins, just use the floating fee feature available in the client. You should be able to get a fairly accurate estimate of the current network conditions and be able to get your coins confirmed in a reasonable period of time.