Yes. You need at least another one other seed or master public key.
Not necessarily. Multisig serves as a system to allow the users to specify the conditions for a transaction to be valid, and in this case the number of signatures from unique parties for a transaction to be valid. It doesn't make it more secure if you're going to be signing or exposing the keys to a single point of failure, eg. signing them on the same computer or generating the seeds on the same computer. You're also having a much larger transaction size due to the inclusion of the redeem script and signatures.

You can always implement a flawed RNG during the generation or intentionally make it predictable such that while the seeds are random, it isn't random enough. Given a compromise in the entropy by the manufacturer, it is far easier for a rogue manufacturer to bruteforce them. The manufacturer doesn't necessarily have to know the sequence for which they're generated, just sufficient information to be able to bruteforce them.

I'd just say that this would probably be extremely unlikely to happen. Most people don't have the capacity to identify it at all, so they can always ship one with a compromised pre-loaded firmware and bootloader, but the same goes for literally any other device that you want to have.

There is simply no way that transactions are done entirely on lightning or on layer 2. That is unrealistic and makes Bitcoin completely useless and which is why I've criticized repeatedly on the fallacy of having a limited on-chain capacity and banking on off-chain TXes to sustain the TX volume. We absolutely need a capacity increase in the future to even think of mass adoption. Again, 7TPS is ridiculously small and lightning network isn't (and should not) be the solution to the problem.

Again, the problem we're looking at right here is not to ensure that we maintain the same level of security. The whole point of PoW is to make it more expensive to attack the chain than be honest. If there is a substantial security decrease but we're still looking at a huge discrepancy between the profits from an attack vs profits from mining, then there is no problem.

You don't have to "register" a transfer. The payment request is simply for you to keep track of your transactions and assigning specific addresses for them. As long as the receiving address is still in your wallet (ie. you didn't delete the entire wallet file or the seeds), then it would be totally fine. Bitcoin addresses will never expire.

100 years is a long time, but we're expected to be experiencing the effects far sooner. There is no point arguing from the perspective that we won't be using fiat in the future because it doesn't make sense. No one wants to make a transaction with a fees that takes a large proportion of their transaction value. The argument stays regardless. Rather, I'm more inclined to think that the transaction volume would rise to compensate for it. It is simply impossible for the transaction volume to stay at ~7TPS or else we'll never attain mass adoption. The capacity of the network can and will increase, if we were to still use Bitcoin as a mainstream currency by that time.

No. Directly. ElectrumX depends on Core, but it is a separate server by itself.
If running Bitcoin Core slows your computer down, then you probably have more problems to worry about . VNC would probably be your only option though, so yeah. 
That is correct.
Core needs to be able to be able to obtain a lock on the directory so you cannot possibly run it in the first place.

Just to address this question, the answer is yes. The inputs within a transaction are not dependent on one another. A transaction is valid as long as you can fulfill the requirements being specified by the script (either, P2PKH, P2WPKH, P2SH, etc). They can all be in the same transaction, the execution of each of the stack should not affect each other.

Why wouldn't it be safe? They are just features being added throughout the different versions, there isn't anything wrong if you don't use them and they don't pose any security risks either.

Electrum runs on proprietary servers, so no. I'm talking about those that are able to use Core as a data source, but I don't think that is what you need?
Then I'm not really sure why the lack of GUI is a big deal. There is nothing that can only be done within GUI, other than the fact that it is nicer and more user-friendly. Most of the more advanced commands are mostly done through the console anyways, so no real need for a GUI.

I've never really thought of something like this, or at least I didn't think about this specific scenario being a problem. Are you unable to run a GUI on your own computer as well? If you need the GUI and can only choose between RPi and your own computer (maybe cause of storage constraints?), then I would probably just run it on my own computer.

Sorry. Meant to say that for all intents and purposes, RPC would be enough. If you need, then use the Bitcoin node as a server and connect an SPV wallet to it. I'm sure it isn't very hard to find any GUIs that relies on the RPC.

A little difficult to type on a phone.

Wouldn't that just make it a remote desktop? As in the GUI has to be run on the Pi but what this merely does is just to relay the graphical interface between Windows and Pi so you're not really running the GUI on Windows, but still on Pi.

Anyways, I don't think there is a way to do so. Unless you're talking about sharing data directory, for which only one of the two instances can access it at any one time. I think it's more convenient to use a RPC connect another wallet to your node.

It is actually quite important to state that this only applies if you are sure that Ledger isn't intentionally trying to compromise your security, but rather only acts as a safeguard against a wrongly implemented CSPRNG. If Ledger wants to actually compromise your seeds, they won't limit themselves to just compromising the RNG, that would be fairly covert but to intentionally include loopholes within the device itself. There are far more avenues for Ledger to compromise your device, and most people don't have the technical expertise or ability to check it as well.

It all boils down to; do you trust that someone else would be actively checking for any loopholes, do you trust that they won't turn rogue and do you trust that their external audits are transparent and done in a comprehensive manner.

Probably not. An overwhelming majority of Binance transactions are still legacy. Their hot wallet is here: 1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s. You can see that a huge bulk of consolidations all originate from v1 Bitcoin addresses. Default, CMIIW is still legacy addresses and you can toggle between those and which most people probably won't because it doesn't benefit them. I'll probably assume that Binance has nothing to do with this but rather because of the drop in TX volume recently, then you're seeing lesser of the groups of people who are not concerned about using Segwit.

There is simply no one that would threaten the dominance of their own currency by allowing an alternative currency to take root within their society. This is mostly a bipartisan issue, where none of the parties in the state would willingly tarnish their economy just for the sake of a few groups of people who are pro-Bitcoin. First of all, you won't get elected and second of all, any bills that actively pushes for Bitcoin to legitimately be recognized and endorsed as a legal tender will face oppositions from both sides of the senate or the house for that matter.

No. Okay, politics aside, there isn't any reason why Bitcoin would do so.

Bitcoin is fundamentally a PoW coin and there is no immediate downsides that would affect the security or the integrity of the chain. As the saying goes, if it ain't broken, don't fix it. A sudden shift to PoS, especially when the specific industry is so established will cause an extended period of instability within Bitcoin, be it concerning the security or the economics. I'd rather not have to go through this phase and overcomplicate anything. You don't really have to care what the developers say, just what the community consensus on the issue is. The answer is no, it isn't going to happen.

Yes. Ledger uses multiple sources of entropy to generate it. IIRC, you can see the functions within their github firmware source code.

It depends on your threat model. If you're at the stage where you aren't confident of eliminating your threat surface or have proper security habits, then it would be far better to be using a hardware wallet. They are dummy proof and designed to eliminate the attack vectors for the regular Joe.

A Raspberry Pi can definitely be compromised, more so if the user cannot maintain an airgap between the device and the internet.

You're not using Tor. Bitcoin Core cannot connect to the Tor instance, are you running Tor at all?

You have to use -onlynet=onion and -bind=127.0.0.1 to force Bitcoin Core to only connect to onion nodes and for incoming connections to go through Tor. If done correctly, bitcoin-cli getnetworkinfo should return reachable for onion and have a network score.

When a proxy is enabled, Core automatically sets listen=0 unless specified otherwise.

I suspect that it might be due to the partitions being allocated wrongly. You might've to resize the volumes to the correct sizes.

As in symmetric cryptography isn't in the equation because there isn't any algorithms to effectively break them, so AES is just one of them. The problem we're looking at with QC is asymmetric cryptography, which hasn't been sufficiently developed as an alternative or some of them involves more tradeoffs.

It sounds like snakeoil to me. Your radioactive decay, which can be measured with a Geiger counter has an uncertainty which serves to be sufficiently secure as a source of randomness. Radioactivity is already a function of quantum mechanics, so not sure why it would be a big deal.

df -h would return the output with the free space, could you try that? Are you pointing Core to the correct directory? Can you navigate to your data directory and run ls -l? It should show the permissions for the file and whether you can write to it.