Bitcoin isn't backed by any tangible elements and the derived value naturally comes from the demand and supply of its usera. Bitcoin is a speculative assets, because the nature of the traders are fairly speculative and hinges on any favorable policies or endorsement. Because there is no mechanism within Bitcoin to prevent external manipulation, the price is vedy volatile.

It is wrong to assume that Bitcoin isn't susceptible to external influence by the general economy. The general trend of Bitcoin still tracks those of the major stock markets and perhaps are more affected by thoae to a greater extent.

Each nodes enacts their own set of rules and do not influence each other. Having control of the majority of the nodes does not give you any more control than you already have, Sybil attack would probably be on the table given a huge proportion of the nodes being under the control of the miners. Having a huge proportion of the network's hashrate also doesn't allow you to change the protocol rules at all.

Okay, so firstly, miners are dependent on the users that are using Bitcoin, because they are the ones that sustains the market for Bitcoin, agree?

Users do not vote using nodes, I've never mentioned that. If users do not run their own full nodes, then whatever rules that they're enforcing is dependent on the server that they are relying on. Full node always have a say in whatever rules that they want to follow, which can be defined by their user. If there isn't a point in running full nodes, then no one is really validating for themselves and the economic majority would rather just go with whatever rules the miners want to implement.

There is a misconception that miners actually vote to implement any new rules or not. They essentially are signalling support for it, or rather compatibility but do not decide which rules get implemented or not. The full nodes which comprises of the economic majority are directly responsible for the set of rules being implemented. As I have said, again Segwit would've never happened if users have no say, or if there isn't a way for users to implement the rules that they want (which, in Segwit's case was for UASF and Taproot which would've been forced LOT).

Which really brings me to the point that most users should ideally be running full nodes, and actively use it.

What Electrum server are you running?

SSDs have fairly good load distribution and the longevity will be specified by the manufacturer or the specs sheet of the SSD. Generally, I don't find it that big of an issue or at least the proportion of rw load is fairly insignificant compared to the rated endurance by your manufacturer.

I'll probably recommend you to just get a HDD. It's 2X cheaper and speed doesn't really matter for running a node anyways. Your HDD will be fast enough, unless you're consistently synchronizing from scratch or reindexing where speed makes a huge difference.

Would you live in a climate where miner wields a greater power than the actual users and having it their way? I wouldn't. Majority of the miners did not want to adopt Segwit and  were proposing a block size increase. Miners started to signal for Segwit after it became apparent there was a threat for a UASF in the upcoming days. Bitcoin is better than Bitcoin Cash because the economic majority (ie. the users) favors it, which is why miners prefer to mine on Bitcoin rather than Bitcoin Cash.

There are plans for LOT=True, or at least as a contingency if miners want to veto Taproot.

Miners are primarily dependent on the crypto's users. If no one wants to use Bitcoin, then there is no point for them to continue mining Bitcoins. In effect, the users have an influence over the decisions the miners make as well.

Shady. You can't mine anything with your computer nowadays. You're probably paying for it in another form, namely either your personalized data or the browser replacing the ads that you see to their own.

If you really want to mine, use the specific software for it and it will be far more efficient. Installing a shady browser can be quite dangerous for the user.

Do you know the definition of stability? If we were to compare the price of 1BTC against a basket of the currencies of the major economies, the volatility of Bitcoin, by far is greater than the volatility of the latter. Comparing the exact same timeframe eliminates most factors and cryptos or Bitcoin is certainly not something that is very stable.

They relay blocks and transactions as well. You can use blocksonly to not receive any transactions that are not in a block yet. Upload bandwidth isn't limited only to getting peers through addr though so it probably would vary quite a bit depending on what your peers request from you.

Encryption can't really do that much, better but not enough. Quite trivial for it to be defeated by traffic analysis as well. It would be far better to just use Tor if you have any concerns about eavesdropping.

By running a Bitcoin node, you are enforcing your own rules, no matter how the miners want to or have implemented. If your node doesn't agree to the new rules, then your node won't follow them because it isn't compliant with your rules.

There is simply no point about trying to mine. You are only a significant proportion of the miner if you (and those who are in line with your views) are able to mine a block. Even so, being able to mine blocks doesn't entitle you to the rights to amend the rules of the network or otherwise influence it. Full nodes are enforcers of the rules, if you don't want to comply with the economic majority, then you risk mining on the chain that no one follows. The consensus that really matter comes from the economic majority. Miner's signalling only shows that they are compliant with the proposed rules.

If miners really form the bulk of the consensus, then how did we manage to settle the segwit deadlock? There are contingencies for forced activation of rules as well, so I'm not sure how miners really hold that much power if the economic majority are the ones transacting in Bitcoin, not them.

Incoming connection doesn't mean that you don't have to request data from other nodes. That option merely means that nodes cannot connect to you, but you will still transfer information to your peers, be it addr, inv, blocks, etc. Connections are bidirectional, so you will still relay blocks, txes to your peers (those that you've initiated a connection to) and your peers can still relay information to you. It is simply impossible for your node to function without any upload activity.

You aren't invisible just by not allowing connections to you.

Archival nodes are needed for bootstrapping and that is about it, pruned nodes can do everything except to serve those pruned block data. It is only important, in the event that we're hitting a point where we are at the risk of losing those data completely. So, IMO the requirement for that can be quite overblown, especially given that we're not in shortage of those.

I do believe that the importance of archival nodes is overblown to a huge extent, where we have no shortage of those for now and in the near future. If anything, we should be exploring ways to either preserve the history, or employ some scheme to truncate the size.

Popularity=/ Adoption. Those are very different terms.

Bitcoin is popular because it is seen as a good asset to hold and a risky yet rewarding investment. It is, however not widely adopted, or at least most don't see the need to. Bitcoin TX fee is expensive, LN usage is low. Requiring additional resources and time to adopt something that probably have minimal usage doesn't really make sense. So you're going to have fairly low adoption until it gets feasible enough for day-to-day normal transactions or at least becomes more attractive than it is now.

Well, we've experienced quite a few bouts of elevated fees nowadays and probably is discouraging adoption as well. Not as far as you think.
Not really. LN is more suitable for microtransactions due to the liquidity of the channels and you will at some point require on-chain transactions. It's simply impossible for us to function solely on LN, or at least without a fairly huge dependency on it. LN is really not the panacea to the problems that we're facing right now. Yes, it will help to alleviate the issue but it really doesn't do that much. If we want any significant adoption, then a block size increase is the most straightforward method.

There are a few threads, off the top of my head that I've discussed about LN and the need for on-chain transactions as well. I think that would be a better starting point.

No miners would intentionally re-org blocks, that is quite stupid. With your proposals, certain miners can influence the size of the blocks for the next epoch for whatever reason they'd like. But the point of my post is more about why should we use a dynamic block size instead of a fixed block size increment? It doesn't necessarily bring any benefits either as using a larger sample size only serves to delay the block size change... It would be quite possible that the larger block size wouldn't be required after the block size changes.

Quite bad from my personal experience.

You can introduce some form of scarcity, but only up to a point. Afterwhich, the benefits start to taper off and you're better off increasing the block size to increase both the capacity of the network as well as to help the miners increase their income. Being on ~4vMB blocks for the near future is absolutely not okay and it should not be an option at all. You do need on-chain transactions for second-layer solution. It is impossible to support them without having on-chain transactions, for opening/closing channels for example.

No. You aren't supposed to provide them with any of your private information (possibly other than KYC) so a simple hidden camera can capture your identity. Most Bitcoin ATMs do not require any cards but only require your Bitcoin address so there is nothing to steal from except your money. It is okay for small purchases, which isn't so viable nowadays. Otherwise, it is a good first point of exposure for most people but terrible if you want to seriously use Bitcoin.

It will but whether it is worth it for the additional strain on CPU is a whole other question.

Actually every little bit helps. I personally don't think Bitcoin benefits substantially from having nodes within datacenters because that creates some centralization within the network as the node operators don't really have any control over it. I run a node within a datacenter because I have other uses for the server as well and I'm using the node for analytics. I would prefer for a network that comprises of regular users running nodes (albeit sporadically) than to have them distributed around the DCs.

Realistically, most users don't want to spend so much just for running a node. Bootstrapping on Raspberry Pi takes a week or so, and assuming the HDD doesn't crash. That is about how much most users would spend to run a node. It is terribly slow but there really isn't a choice.

On-chain capacity probably will have to be increased some point in the future. So it will become an issue sooner or later, provided that we don't do anything about it. Moore's law is more or less done for in the near future anyways.

Increasing the on-chain capacity will result in an exponential increase in the block size over a given period of time. Going by the general usage of it's user, it is very likely that as the database size gets bigger, we'll see fewer users running full nodes. Reason being, no one wants to synchronize for hours or days to use Bitcoin, adding another hour of synchronization every time they open their client.

The problem isn't really about how expensive the storage is. Yes, it is getting cheaper but no one would realistically get a new HDD every now and then solely for Bitcoin when there is a far more convenient alternative available. I can see it being a problem if bootstrap synchronization is still the modus operandi in the future and thus discouraging the general userbase to be running Bitcoin nodes.

It is possible for certain compression to be used on block data or transaction size. Problem being that there is also a certain degree of tradeoff for your CPU as well.

Total fee that a transaction pays is dependent on the size, so it doesn't make sense to peg it to the avg TX fees. You would probably be looking to peg it to the fee rates, but that is assuming that it doesn't get manipulated by miners intentionally including smaller fee TXes or vice versa.

I don't think a dynamic block size really matters. It would be far more prudent to increase the current block size than have to add additional mechanisms to regulate the block size. We're talking about block limits, so if there isn't enough transactions to include, then there is no need for the blocks to at their limits.