What feeds the miner? There is something that has to build the merkle root and the block headers. Whoever runs the ASIC has to make deliberate decisions to include or exclude transactions.
Exactly. Miners hop to pools that provides the most profits. Pools are not charity, they do not give out money for free and there is always a catch if they are seemingly running it for free. That is also the naive approach, for which no one actually adopts. Luck does matter and miners can pool hop. The profitability is still attributed to the fees being paid out from the blocks, and there is no denying that. If they don't, please point out a pool that doesn't include the highest fees.
They don't but the observation of a lower potential profit is far more obvious in the long run. It doesn't matter what an individual miner perceives. A rational miner always maximizes profit, and empty blocks or intentionally including lower fees isn't one of them. If that is, then pools would be actively doing it.

Concluding note: No free lunch in the world and each miner is paying for their services to provide them in the form of a mining pool. If you collect less fees, then you are receiving less profit, because your fees are pegged in the miner's revenue. Additionally, including low fee transactions or not including transactions doesn't affect stale rate to any noticeable extent.

The transaction malleability wasn't due to the failure of checking for signatures, but it segregated the signature from the actual transaction itself. This prevents the signature from being modified and thus being malleable.

It was anything but smooth. It was totally unnecessary for it to be dragged on for longer than it did. Segwit's activation requires miners to signal support for it as well and it definitely required a super majority of the miners to signal support for it to be activated. In fact, most if not all soft forks work in this manner. USAF was not materialized and it was definitely not activated by user signalling. Any forks should have consensus and majority support.

Difficulty is a representation of the target, and they are not directly interchangeable.

Think of mining as a game of probability. The more narrow the acceptable range, the harder it gets because your range of acceptable value gets smaller. Hence, you would need more tries to be able to hit a number within that range. If it gets harder and you can only guess at the same speed, your rate of getting the number correct gets lesser. Hence, smaller target = higher difficulty.

Note that the hashes are actually displayed as big endian when you're looking at the block explorers but is in actuality little endian when you're looking in the code. Talking about the number of leading zeros would be correct if you look at blockheaders in hexadecimal and in big endian.

Two points of failure: One for generating the seeds and one to convert it into SSS shares.
There is a way to ensure redundancy as well. The real benefit with SSS is that it provides information-theoric security and compromising the shares doesn't reduce security until you reach the threshold. However, it isn't exactly easy for people to understand.

A good way to ensure security and redundancy would be as follows: split the seeds into 10 different cards and remove certain words from each of the cards. If done correctly, it should provide sufficient security to ensure that compromising one share doesn't result in a failure of the security. Though I have to admit, because of the size of our seeds, you're fairly limited in terms of options and the only good way is to include more shares.

Another fairly well known method is to use XOR to combine different shares.

If the "randomness" is deterministic, then there is no need for randomness because it won't be. It would just be a fancy implementation of a HD wallet.

There is actually no added benefits with the schemes that you've mentioned. It would purely be implemented with a centralized server, because you need to have them communicate with one another.

Might be better to just split the seeds in a manner that doesn't allow a central point of failure. Whilst SLIP39 is a good implementation of Shamir's Secret Sharing, I find that manually splitting the seeds into different blocks would be simpler and doesn't require any complex math.

That is not how economics work. Well, it would be logical if you're talking about some ulterior motives that compels miners to only have transactions which has low fees. In a game theory approach, if you have agents that wants to maximize their profits, then they must include transactions with fees. The extent of which should be as much as possible, because people would hop to another pool if they don't.

The block reward isn't negligible income and it is definitely included in the PnL calculations before we invest (ie. we estimate how much of our profits could come from fees). There's a pretty big difference between making money, which is in your case making $160,000 but not making $160,001 when there is little to no cost.

That's not true at all. If a miner were to only include their transactions, they stand to not benefit at all because they are paying their own fees. I think you're talking about empty blocks: Faster propagation, no risk of invalid blocks without validation.

Block validation is in the range of a few milliseconds. Sure, you can send an empty block template but you would never send a block template that has tons of tiny transactions. That only slows down your propagation while receiving virtually no benefits.

Not really. That is the monetary cost, but in economics then we would consider the opportunity cost. Hence, if there is another 5k transactions that has a tx fee of 1sat more, then you would have lost 5k sat by not including those transactions.

Fortunately, same as the prisoner dilemma problem, the collusion is harder to pull on with this much money and unpredictability involved.

Sure, but it is easier said than done. You do trust the blockexplorers, but generally it is used as a secondary form of validation. Think, you wouldn't exactly trust (or should trust) a blockexplorer when it says that someone has sent you Bitcoins. You would check your own wallet.

Blockexplorers are good for indexing transactions, especially others. It is very resource intensive for most to do so, you need to index the transactions in addition to the blocks. This is regardless of pruning.

If the threshold is met and you still generate blocks that are not conforming to the new rules, then your old nodes will accept it while upgraded nodes will reject it. Fun fact, intentional hard forks are by and large only happening with splits that wants to fork a Bitcoin with different rules. We generally use soft-fork most of the time save for extraordinary circumstances (twice, 2013 chainsplit and unexploited inflation bug). Hard fork simply means that old nodes cannot accept it, regardless of what happens.

Hard fork is very complicated and lots of things can go wrong, you simply have to weight the risk and reward.

Your wallet will either not allow you to have repeated keys for your multisig or sign the transaction wrongly. So it isn't too good to do that as well.

Either have two entity hold different keys, or use that setup above. I believe there was a conversation in one of the topics that ive created previously talking about this specific method. It is standard.

The opportunity cost of including these transactions would be those that could have been included to give the miners a higher profit. That would make sense if there is a collusion among the miners to artificially inflate the fees but generally game theory negates all of these collusion and would result in a far lower profit than expected.

Besides, the fact that most wallets are biased towards mempool size rather than historical block data as a fee estimation makes this less likely to influence the fees to a large extent.

I'm not really sure what is the emphasis on being tagged. Traffic analysis is possible even if you wrap it within a VPN connection, and if your government is willing to tag a Tor connection, then you should assume that they don't care about the false positives as well. You should assume that you are being watched regardless.

Bridges should only be used to evade but not hide your connections. That is futile against governments with tons of resources to track you down. In that case, then running a private bridge wouldn't be the most cost effective idea.

Blockchain.com wasn't the one who built the first blockexplorer. By the way, they were known as Blockchain.info prior to that. You are right; no one actually needed to see the balance of someone else's address and most of the information that you see on the blockexplorers are not essential to most.

The first blockexplorer was actually created by theymos: https://bitcointalk.org/index.php?topic=1727.0. This was before blockexplorer.com and it led to the creation of that which was a lot more polished and with more detailed information.

Might be under different circumstances though. Using uncompressed keys with Segwit would yield non-standard transactions and thus it would be quite difficult to spend it. In that case where creating something that results in non-standard transactions being generated, that is fine. However, using multiple of the same public keys to generate a Multisig would be fine and should still yield standard transactions.

Nothing in the protocol rule would prevent that, you just need to fulfill the number of keys but there is no requirements on whether it has to be distinct or not.

Electrum just doesn't allow it because it is probably just pointless and a waste of space.

The certification is quite expensive and time consuming. IIRC, EAL4 already costs >$200k (possibly a lot higher) and a year. Going any further than that, it would probably cost more and takes longer. From the business standpoint, it isn't very practical.

I would prefer if HW manufacturers don't release a new HW wallet that often; most are secure enough and it isn't IPhone where obsolesce is a big concern.

It is possible. There are no such restrictions that checks for the public keys used in a multisig to be different. If it is a 3 of 4 Multisig and you have two of the same public keys, you just need the transaction to be signed using the private key. However, from a security and usability standpoint, it is entirely useless.

There is no reason to do that though.

Unfortunately not a causation. The increase always coincides with a rise in the popularity of Bitcoin and the effects of the halving are often either negligible or difficult to measure. I have my doubts that the halving would actually cause a significant rise in the value of Bitcoin, if any.

Everyone validates transaction, and there is no actual puzzles being solved. The issue is when the cost for an adversary to execute an attack becomes too low.

Innocent until proven guilty. Are you doing something illegal? If you are, then there is no point hiding anything so long as you can protect your privacy properly using Tor. They cannot legally prosecute you without sufficient information, and if done correctly, landing on their watchlist does nothing to you.

On the contrary, there are many ways that you can land on their watchlist and using Tor is probably an insignificant part of it. If they want to monitor you, they would pounce at every chance that they can get. Using a VPN in this case provides you with a false sense of security.

If you are confident that you can ensure that your VPN isn't already a honeypot, and you can effectively prevent any leakage of information, then go ahead. It would still be possible to conduct traffic analysis to come to the conclusion that you're still running Tor.

At the end of the day, you can certainly do so with marginal improvement on your privacy. That is assuming you know how to prevent any VPN leakage and configure Tor to work properly before considering the even slower synchronization.

It is allowed, and there are websites facilitating it though the popularity of them has dwindled through the years. Governments are tightening their grips on currency exchange, to manage capital outflows, terrorist financing, money laundering, etc. Legalized exchange between currencies would only become more and more difficult with more hurdles to jump through.

Your local OTC (a lot of exchanges are P2P but not OTC) transactions are likely to be less regulated but more sketchy.