That is correct. Transactions to an address that is in the same wallet shows up as N/A on the address column.
Not forever, likely just unconfirmed.
My guess is that what you've done is that you've spent the outputs of the first transaction in the second transaction. This means that your second transaction cannot be confirmed without the first transaction confirming. This is not an issue however. If you've signaled RBF, you can try to use abandon transaction as mentioned for both transaction and spend it again with a higher fee if it is not in your mempool and it likely is. 

I'm not sure if Bitcoin Core allows the RBF to have different outputs. IIRC, it doesn't so that could be a problem. Should try to create a raw transaction in that case, with care.
Zapwallettxes was removed in 0.21.0, just in case OP tries it.

Then you're just delusional. There is not guarantee that Bitcoin holds its value. Personally, I believe that it could be worth more than the value currently but I'm still classifying it in the smallest proportion of my investments. In case you've forgot, loans generally comes with a certain level of interest.
No. If you don't have the means to repay the loan if all the money that you put into Bitcoin turns into zero the next moment (well, even if you do, how would you feel is you're suddenly in a debt of $20K?) , then you shouldn't do it. Cryptos in general are highly volatile, endangering yourself with higher than necessary risk is not advisable.

It sounds about right.

One thing that I would do differently from steps 9 and 10 (and actually clarified in the notes) would be to not reconnect your computer after you have transferred your wallet.dat over and use the raw transaction method. Note that for partial synchronization to work, you'll have to be sure of the exact timeframe whereby you have received the Bitcoins and to synchronize after that. Any transactions done beyond that synchronization would not be shown and there is a risk that Bitcoin Core accidentally creates an invalid transaction, which is fine just a bit annoying; it wouldn't cause you to lose your funds.

RPi nodes are generally still a net positive to the network. Having more nodes will increase redundancy and bring about a greater decentralization. It doesn't make it slower; block validation or transaction validation are sufficiently fast for RPi. The main bottleneck that they experience is with their own synchronization which is perceived to be fairly slow. With the current relaying system in Bitcoin Core, you don't actually have to do a full validation before sending the blocks provided that both connected nodes are operating in high bandwidth mode.
I want to be able to verify the transactions and the blocks fully and not be in the mercy of people who wield the power to do anything they want. Running a full node doesn't necessarily require you to mine and by definition a full node is not [necessarily] a mining node. 1MB blocks ensures that people doesn't have to trust someone else and can validate everything for themselves.
If you're counting the thousands of miners who are connecting to a pool to mine then sure. I'm not sure about your first statement; there are certainly more than a hundred that has ever mined a block. The whitepaper actually mentions about the game theory behind this, so it's really nothing new.

---

I've interacted with you for quite a few times and I can't help but think that there is some ulterior motives behind the posts and the assertions that you're making.

Both Bitcoin Core and Electrum allows the user to import the master public key, addresses or the private keys and has a feature to sweep them as well. Don't use web wallets for anything, especially Blockchain.info.

Core has quite a few performance optimization, especially in the recent releases. I would recommend you to upgrade Core immediately, older versions tends to have some bugs and are generally incompatible with some of the new changes implemented.

The sole inclusion of headers first synchronization would help with your download progress immensely as it can be parallelized. Back up your wallet.dat and download the latest Bitcoin Core.

You need the wallet.dat to recover the wallet. Did you copy it out before you reset your Window session, which I assume that means the data during your 'session' is deleted?

If you're losing your private key, yes you will reduce the total circulation of Bitcoins but that won't be a provable burn. Unless you actively send it to an OP_return and thereby eliminating that UTXO completely or to a provable burn address, the total market cap of Bitcoin remains the same; there is no way to tell others or for anyone else to prove that your Bitcoins are burned. By definition, the current supply of Bitcoin includes all of Satoshi's Bitcoin as well as those with hard disks sent to dumpster, those who accidentally wiped their own computer. It doesn't necessarily make Bitcoin more valuable.

That's it. When I was running my node on Tor a few weeks ago, it took quite some time for me to get any incoming connections. Tor V3 addresses was recently adopted, together with the address gossiping and this made it such that there are lesser Tor V3 addresses that were able to connect to my node.

If you'd like, I can try to connect to your node to see if it's working. Obviously not a wise choice as this could have some impact on your privacy, or else just wait for a bit.

It is, there is very likely to have a corresponding private key. It's just that the generation method ensures that it is very unlikely for anyone to ever find a private key-public key pair that would lead to that address.
Addresses specified in OP are burn addresses.

Did you specify listen=1?

When operating behind a proxy, Bitcoin Core specifically disables listening to the incoming peers. You'd want to bind the address to 127.0.0.1 by using -bind= or else the client will listen on clearnet as well. Bitcoin Core connections are bidirectional; you are relaying blocks and transactions to and from your peers regardless of connection polarity.

Open port 8333, put listen=1 in your Bitcoin.conf.

Peers has to connect to you for it to be shown as incoming. For my Bitcoin Core, more than half of it are scraping nodes which doesn't do anything except to keep track of the nodes on the network.

I would argue that for the transaction volume that Bitcoin has, the amount of energy mining consumes is still within the reasonable range. Use of renewable energy is not a redeeming factor for the electrical use; someone could very well be forced to use fossil fuels because the farms are using the energy from renewable source. The argument would be less valid in the context of countries with sufficient and sustained renewable energy. A far greater argument would be the ewaste generated from mining. ASICs cannot be repurposed for anything else, save for some salvageable parts, it is not possible to reuse ASICs. It is a far greater problem than energy usage.

The address with the unique vanity with Counterparty is burned to obtain Counterparty tokens. It's known as proof of burn and those who burn their Bitcoins receives a proportional compensation of Counterparty tokens.

People burn Bitcoins for a variety of reasons, most common having received dust transactions. Some of those transactions are used for deanonymizing attacks and/or spam advertisment. People spend those transactions to the burn address to avoid having to spend that output together with the other outputs and thus revealing the addresses the user owns.

Economically wise, there really isn't a reason for you to burn Bitcoins. Theoractically, it would result in Bitcoin being more scarce but the amount that is being burned is really minuscule which wouldn't make any difference.

That's not a definition I agree with but I don't think that's very relevant here. Pools do not have to be regulated or registered. Anyone can run a pool, public or private and it's very easy to be able to make it hard to detect. Not through Tor or any VPN connection. SSL with stratum on a non-public pool with the shares being submitted to a different server that is used to broadcast the blocks makes it practically impossible to detect.
Yes. But the truth is people still cares. Bitcoin is designed to be censorship resistant in mind; breaking this tenet will inevitably make people lose trust in it. The scenario is not an Apples to Apples comparison. Truth is, there are loads of people that use Bitcoin to protect their privacy, to circumvent payment restrictions. If there are any signs of any government control over Bitcoin, I'm certain that the price would immediately crash and perhaps never return as people search for alternatives.

Weird. Is there any firewall rules that you may have on your router or imposed by your ISP. It's strange that you only have incoming connections and not outgoing, it's usually the opposite. At the Peers tab, can you see if anything is out of the ordinary? Could be the ping being unusually high, synced blocks or block headers being low, etc.

Block headers should be downloaded before the IBD starts isn't it? Or that's from my experience, the client always download all of the headers before commencing.

OP, do you have any peers connected? Go to Window>Information and Console. Check the number of connections.

There can only be a maximum of 2016 blocks in a difficulty period. There are certainly more than 2016 miners. Can you get the IP of this block? 00000000000000000000ce9a189699570401c2503524b690aa92f6fedd9dcf59. Without looking at the information being put in the Coinbase of course. I don't dispute that large mining operations are difficult to uncover, that's pretty obvious.

Certainly hope there isn't any! Having effective legislation is difficult enough, but having similar policies across all the countries worldwide? That is the point, I don't see it being possible for every government in the world to collectively agree on and decide to force miners to do something they want.

No. What do you do after the price crashes when people realizes that miners are actively censoring transactions? You've mentioned that Bitcoin functions on game theory and I agree completely with that. So what happens then?

How? Is it easy to ban all the IPs running P2Pool? It is easy to solomine as well.

---

I maintain that an effective censorship IS a majority attack on the network.

How do you monitor the network? If you use a different address per block and choose not to put any identifying information into the Coinbase, there is no way to track.

Which requires a majority, AKA. 51% attack. Censoring a transaction entails the fact that those transactions will never be confirmed, which means that you'll have to do a block re-org at some point to ensure that you will invalidate blocks from miners which don't have to follow the censorship regulations. It is impossible for the said enacted laws to be enforced worldwide. Certain countries has constitutional rights against censorship which would hold water in court.

How would you repurpose your million dollar ASIC farms after some local regulation forces you to attack Bitcoin. Censorships can be obvious, it's easy to monitor the network and realize that certain transactions with a high fees are not getting mined.  Do you sell your ASIC to someone else? Because your ASICs are certainly no longer profitable, all to comply with some local regulations. Not sure about the legality of the regulations in the first place.

Pools are not the only way to mine. P2Pool for example allows all to host their own pool which cannot be censored because it'll be decentralized. Solomining is still a thing with older hardware. Pools helps to mitigate the huge variations in mining income but it doesn't mean you absolutely have to mine with the pools.

As in the number of unique pools?

---

Deliberate censorship of selected transactions involves a 51% attack which has serious economic repercussion to Bitcoin. Keeping that in mind, for miners who has invested millions of dollars into their own mining farms, will they execute a 51% attack to prevent confirmations of certain transactions to comply with the local regulations? Highly doubt so, by the fact that most of them hold a substantial amount of Bitcoins and their ASICs are worthless once this happens.

You are also measuring the number of unique entities by the number of (known) pools which has possibly thousands of different miners located in geographically diversed locations. Tracking each and every of them will be difficult and you cannot monitor the entire network as well.