That's a valid point but there is no provable ways to accurately tell where the hashrates are, what the hashrate is or the distribution of it. Bitcoin is designed to be transparent, but unfortunately the pseudonymous nature also means that it is difficult to ascertain certain things beyond a reasonable degree. I don't think it is easy to do so, or if you have a feasible idea to do it, then we can hear from you as well. If not, then I believe that should be the end of that discussion.

POW or basically any mechanism favours those with the most resources, because it functions by game theory and the assumption that you stand to lose the most if you are dishonest. I have no doubt that financial institutions or governments have a hand in mining. But, what can they do? Attack the chain? That would probably achieve nothing, beyond a minor inconvenience while costing them tens of millions of dollars, and even more in terms of opportunity cost. I don't foresee any governments being willing to attack Bitcoin for practically no benefits.

That is wrong. The value of Bitcoin doesn't come from miners, but it comes from the community and the users actively transacting with it. Even if the miners were to adopt it, if the community doesn't support it or people don't use it, then Bitcoin becomes useless. It is to their best interests to support the sentiments of the majority given their billions of dollars in investment.

Most people understand basic economics regardless, so the supply cap probably won't gain any traction.

That's an irrelevant analogy. I am purely wearing pants for my own modesty. I'd mind my own business about how others dress, perhaps not for you.

I'm perfectly fine using an SPV node, or with the alternatives which doesn't benefit the network. Yet, I am choosing to run a pruned full node while someone on the internet is chiding me for being restricted by resources and telling me that I should run a full archival node when I don't have the capabilities to. Don't fool yourself; running a full archival node is a good to have but I am not forcing it on others to do so.

Basic concept of positive externalities, which is what this phenomenon is.   
Ridiculous. I am not going to force others to run a full archival node because I believe they should. I would encourage people to run a full archival node, but not belittle others for not being capable or not being willing to run one. Of course, if everyone prunes, then it would be terrible. But so long as people are willing to do whatever they can within their capabilities, I don't see how it would be a problem.

Sure, hard disk space is cheap. But I'm not going around to tell others that they suck because they are not running a full archival node. I was able to purchase and used a dedicated drive in my desktop for an unpruned node, but that wouldn't be the same for all.

Sure, I don't see how anyone has toot their own horn for running a pruned node here. Sure, it is good to run an archival node but don't expect people to care nor thank you for it.

No one is virtue signalling here; I'm not running a pruned node to feel good or brag about it. Heck, I'm not even being compensated for running a full archival node. Getting shamed or attacked for running a pruned node instead of a full node is disgusting and unwarranted. If I can only run a pruned node, then you bet I wouldn't buy another disk just to run a Bitcoin node.

If I'm not getting compensated for running a node, I don't think anyone should lecture me on what I should be doing to my node. After all, it's not like my pruned node is a negative to the network and is still in fact providing blocks to my peers, validating transactions before relaying it, etc.

Conventionally, the community has always agreed that full nodes are the opposite of SPV clients and that full nodes are just nodes that validate each block and transactions. Sounds like you’ve blown the issue out of proportion. Just look at the historical usage of the term.

What do you consider full nodes which stores the entire blockchain but has bandwidth limits which disallows the peers to request more blocks? The only key difference in function is the unavailability of certain blocks in the past. In fact, they are still doing validation the same way as other full nodes.

Not all peers would be required to serve all of the blocks in the blockchain and it is possible for Bitcoin Core to requests for blocks selectively. If you’ve taken issue with the usage of the term, you should look at the historical usage of it on the forum.

Please do not modify codes that you are unfamiliar with, especially if you do not understand the codes fully. Note that it would be more resource intensive than your vanilla vanity search and it would take a lot longer and likely you would only have one address with the vanity that you are looking for; the more vanity addresses in the same seed would require exponentially (or quadratic complexity?) larger search space. It would be unwise to vary the derivation path or index beyond the standard.

If you are conversant with how BIP39 generation works, you can build a simple python script which generates valid combinations of your BIP39 seeds and checks the prefix for any matches. Of course, keeping in mind your security concerns, ie. data leakage, entropy generation etc.

Then what is the difference between an archival full node and a pruned full node? Remember, you seemed to have taken issue with labelling pruned nodes as full nodes, while retaining that term exclusively for full nodes which stores the entire blockchain. So what gives? Don't both of them act in a similar manner?

Certain things in the whitepaper is quite abstract and can be quite difficult to understand if you aren't very conversant with the public key cryptography. I'd explain it simply and hopefully I'd be able to link it to whatever you've seen.

In each of the transaction, there are quite a few key components and I'll omit those that aren't discussed here. Namely, it would be the previous transaction (as denoted by the transaction ID), the public key that contains the amount of Bitcoins, public key that corresponds to the recipient and the amount that is supposed to be sent to that. In a normal transaction, you would need to prove that you are allowed to spend the coins that you have. Hence, that is the signature that is generated by the spender's public key.

Think of a transaction like this:

Public Key A -> Public Key B
                       Public Key C

Number 1 would be the transaction ID of the previous transaction.
Number 2 would be the public key of the intended recipient (B and C) (as well as the amount).
Number 3 and 4 would involve using the private key of the of the corresponding public key of the previous transaction to sign the entire transaction, thereby producing a signature.

Number 5: On a network level, others want to know if your transaction is indeed valid. Part of the checks would be using the signature to check if the corresponding private key of public key A has signed the transaction. To do so, we need to check if the Public Key A and the signature checks out.

Pruned nodes do validate all of the blocks during synchronization. Definition wise, not sure what's the fuss with it. If you can't provide the full blockchain history to your peers, you are already signalling that to others in your network flag.
Full node has traditionally been used to describe nodes who validates all of the blocks and transactions, and thus by the convention that we have always adopted, it would be considered a full node. Node operators are not compensated for the operation of their nodes, and I wouldn't go as far as to assume that everyone is willing to spend so much of their disk space just to run a full archival node.

It would probably create too many forks, each node has a different range of acceptable time when considering the network adjusted time. Each node would also see a different set of valid blocks.

That seems to be pushing the point a little bit too much. You shouldn't be forced to make multiple backups, and if they are made, then it should be for redundancy only. Disk drives are prone to corruption and degradation in general, it would be difficult to tell if there is a manufacturing defect or degradation that has occurred to your disk drive before it is too late. In comparison, backups on paper are far, far safer and verifiable.

Again, cost benefit analysis. I'm not going to guard against infeasible and unrealistic attack vectors when there are more things to be worried about. If your seeds can be cracked, I don't see how there are more things to be worried about; your seed isn't any less secure than your private keys. If you are able to crack any of the seeds, then it would be reasonable to be assuming that all of your private keys, and by extension Bitcoin is broken and insecure.
 
It is not a security compromise if there is zero security benefits. It provides virtually zero extra security, especially if you realize that wallet.dat are by default, Hierarchical Deterministic as well; all of them can also sprawned from a single seed. If there are any security benefits, even marginal, you would think that the community would have ditched HD wallets in favour of individual generation. Truth is, we have evaluated the security tradeoffs and there would be no reason why the industry standard would be HD wallets if we thought that the security tradeoffs matters.

Your preference of using wallet.dat (HD or not) or mnemonic seed phrases should not be based on unfounded FUD.

1) That point would be unfounded. Given that an attacker would require unrealistic amount of resources to be able to bruteforce your seed, it makes no sense to prefer one over the other. If both of them are, in theory infeasible to be bruteforced, then it isnt a concern.

2) It doesn’t lower your security. User error or negligence wouldn’t concern the security of the seed. However, the security is again sufficient at 12 words and anything beyond provides insignificant amount of additional security.

The time stated is the timestamp of the block and not the received time. As you have identified, the block timestamp doesn’t have to be sequential. Hence, it would be perfectly fine for the timestamp of a future block to come before the timestamp of an earlier block so long as it fulfils the Median Past Time.

Pools would usually try to broadcast the block immediately, or with minimal delay and propagation should he under a minute as well.

Investors != Miners. If they are investors, they may not necessary be the ones mining at the pool either. The thing about these pools is that they are NOT exclusively tailored for a small number of miners, but they are tailored to accommodate for a large number of miners with their own farms. That alone should tell you how decentralized Bitcoin mining is.

The FUD that is put forth in this thread is largely unwarranted. The key factor that you're ignoring is with the game theory that the miners are involved in when they invest their resources into mining. The key question would lie with whether they gain more when they act maliciously, or honestly. It would be obvious that the answer is to be honest. Selfish mining is largely only a concern among pools, because they are able to gain an unfair advantage than the rest of the pools. It poses much less of a security threat than you think.

Sanity check in Computer Science terms is a bit different from what sanity literally means.

As I have already answered previously, you do not require an internet connection to generate private keys, public keys or their addresses. Again, so long as your OS has the required dependencies or the softwares (Electrum comes preinstalled in Tails), you can generate ECDSA private keypairs and your addresses. You can even do so using a pen and paper.

The security that your setup provides would be limited by your exposure of the keys to the internet. Generating your keys offline before transferring it to another device connected to the internet provides no additional security whatsoever. The same applies if your computer is connected to the internet before or after the generation of the keys.

It is possible, but just a hassle as compared to downloading Bitcoin Core and generating it yourself. Assuming that your OS ships with OpenSSL, you can use OpenSSL to generate an ECDSA keypair, then convert it into a Bitcoin address with a WIF private key. However, this would require you to understand exactly what you are doing with your terminal, or risk losing your funds.

Bitcoin Core or any other wallets does this for you in an elegant UI, with appropriate sanity checking to ensure that your Bitcoin addresses are properly generated. Given that, would you still insist to generate them manually using OpenSSL?

You don't need an internet connection to use any Desktop Wallet (Bitcoin Core, Electrum etc). You would be able to install and use the different clients normally, as you would on a normal computer. The process to generate an address using the clients differs, and it would be helpful if you could specify which wallet are you intending to use.


I personally don't recommend using any Javascript wallet, especially one that isn't in active development.

No. You are a full node even if your node is pruned. Regardless, to use txindex with a pruned node, you would require a reindex as well. Hence, you would need to verify and rebuild your database again after executing it.

Hence, for a pruned node, you would be asked to reindex when enabling txindex. To check the progress of the txindex, or how far the txindex has progressed, you can execute getindexinfo. It should tell you about the progress of the txindex.

If your node isn’t pruned, then a reindex isn’t required. The txindex will be built in the background.

You don't need to query for data of a block, in fact, Bitcoin Core also doesn't look at the earlier blocks after the initial synchronization. That is other than the startup which checks for the last XXX blocks, can't remember how many off the top of my head.

The reason for IBD is to ensure that the chainstate is built correctly, hence all of the unspent outputs are correctly indicated. It would then be impossible for a rogue node to falsify transactions with inputs that doesn't exist. Risk is relatively low, but it doesn't mean that it is impossible. If you are unable to conduct IBD for your Bitcoin Core node, I would recommend using an SPV wallet instead.

Generally, all of those are components of a single RAT. RATs usually has the ability to replace or copy content on the clipboard if enabled, and in certain cases are able to function as a ransomware as well. If you're infected with any of them, you would probably be infected with all of them.

Unless the malware is well obfuscated, most of the antivirus does behavioral analysis as well. In essence, if it does something that is out of the ordinary, it gets flagged. You can of course, evade this with a very good crypter but I don't think any of them lasts very long even with it.

It depends on the kind of updates. We've had quite a few updates for important software that didn't disclose about the fixed vulnerabilities to give their users time to perform the necessary update. Remember WannaCry? Reluctance to update was the main reason for its severity.