Look at Burden Of Proof. The only real evidence is that it is both time and resource consuming but it doesn't mean someone with decent resources won't crack it or if someone uses weaker than usual passphrase.

Brainwallet schemes are by no means sophisticated. You can probably replicate the entire scheme easily, because you're just essentially using Scrypt to generate a key. All you need to do is to determine the algorithm and the parameters. They are generally quite well-studied so you probably won't have any bugs.

You can use those private keys, if your funds are in there.

You cannot get your mnemonic from your private key. Your mnemonic goes through a one-way function to generate the keys. You cannot reverse the private keys to get your master private keys, your seeds or your mnemonic.
It has to be in the same order, but you can unscramble it. If you have 24 words and you've jumbled them up, then there are only 24! number of possible permutations and lesser after you factor in the checksum. There are ways to unscramble and get the entire mnemonic in the correct order so long as you know at least one of the address.

Don't think the checksum actually narrows it down too much, so yeah. It can be done, but it probably won't be possible.

After the initial brainflayer fiasco, the original brainwallet was shut down. There were variations of it such as brainwallet.io and warpwallet which both uses Scrypt and salt to enhance the security. It wouldn't go as far as to say that they are uncrackable; given sufficient resources and common enough phrases and passphrase it can be crackable. The most infallible method is really to just use BIP39 or similar mnemonic systems.

There are ways to crack them and tools to do so. Just that they are significantly slower (and more expensive) than single round SHA256.

That is wishful thinking. Bitcoin isn't designed to provide privacy, though the nature of it does provide some privacy.

The reality is that majority of the Bitcoin users actually doesn't care about privacy. Even if you do, there is nothing much you can actually do. Regulations, as it stands currently is sufficient and palatable for most Bitcoin users because there is no such thing as going dark or leave no actual digital trace in the internet. This is moreso with Bitcoin, perhaps you can get more privacy with privacy coins, but that is it. People who cares about privacy wouldn't really be using Bitcoin when there are alternatives.

These policies (AML/KYC) as it stands act as a relatively okay deterrent against illegal activities provided that sufficient screening is done. I'm all for a suitable compromise with government policies and this "intrusion" of privacy, because after all, if you're using an exchange then you probably don't care about privacy. I'd very much rather have the government reaching this compromise and the middle ground rather than clamping down hard on crypto because they cannot fulfill the basic social obligations and these illicit activities start running rampant.

Not exactly. Adding a salt is not enough if your algorithm is naturally fast and weak; reaching your specific permutation would likely just be a matter of time (albeit longer, but still easier than other algorithms because hashing SHA256 is not really that difficult). Regardless, that is not what I'm advocating for and while it does make for a difference in the difficulty, it does not, by any means make it expensive or impossible to crack.

Instead, what I'm advocating for is to use Brainwallet with a resource intensive KDF and salted. Doing this gives you the best chances; it is far, far slower to crack if it is memory-hard and it makes more sense to go through dictionary or known wordlists in that case with common salt permutations. When compared to the original brainwallet, the choice would be a no-brainer.

I think that it is still important to acknowledge that the brainwallet implementation was inherently flawed with a fairly weak KDF that resulted in an extremely fast bruteforce and balance checking which resulted in very efficient and effective implementations like Brainflyer to exist. Which accounts for this impression that brainwallet simply doesn't work.

However, more recent implementations uses a far slower and intensive algorithm which limits the effectiveness of the bruteforce as it would require either high memory intensity or resources. In addition, salt is mandatory in most implementations which makes for an additional round of protection. Fact is, while such algorithms cannot beat the entropy of your OS, you'll still have a fairly decent security as any attempts would be far more than a generic bruteforce but they would also have to take into account the salt, which is personalized and unique. Caveat being both your phrases as well as your salt has to be unique and sophisticated enough.

No. Humans are naturally not good at creating complex and secure passphrase. More often than not, you end up creating addresses with poor entropy. If you need an easy way to remember the passphrase, then you can just use a wallet with a mnemonic. The generation of mnemonic is secure with a good entropy.

Interesting to note that there is a caveat tied to this, when mining pools directly reward the miners using the coinbase transactions. These transactions have a threshold of 100 confirmations, so you can only spend the inputs from these transactions after the 100 confirmation, which is actually fairly long. A more direct method would be to send it to their own address before distributing it afterwards. The good thing is that they can include their own transaction in a subsequent block that they mine.

That is also why most exchanges don't recognize these deposits automatically. Most mining pools credits their miners after 6 confirmations and uses the older "generation transaction" to payout instead of having their miners wait for additional 100 confirmations.

It will. The password will work so long as the file is uncorrupted, no matter where you decrypt it.

I would be more comfortable with using the seed as a backup method. It would definitely work and there is no reason why backing up the file would be better than it, unless you need the labels and stuff like that. I would probably avoid exposing the seed so much as well.

If you're looking for a method, just make sure the wallet file is unencrypted (with the encrypted keys) then extract the encrypted seeds. Afterwards, just use OpenSSL or similar utility and decrypt it with AES-256-CBC.

That would be an inefficient market allocation. In a logical and perfect scenario, each miner mines at the optimum MPB/MPC and that is the market equilibrium.

This makes it such that a smaller change actually makes it more rational for a miner to either scrap and sell it or to turn it off. The phenomenon which the miner actually finds it more efficient to mine at a specific point in time would then be a market failure due to the time lag or lack of perfect information. Hence, in essence the market logic would still apply, but it gets more skewed in the real world.

Isn't that what a zero sum game means. The fact that we have numerous different players in the mining market, you have a scenario where certain miners profit more than the others. It isn't about if a proportion of miner profits or if miners profit from others, but rather if the total utility in the economic system actually changes with any impact on the system; think of it this way, with someone purchasing more ASICs, that person profits more but the others will profit even lesser but the entire system doesn't change. Since this entire effect is contained in the mining economy, mining is a zero sum game.

Precisely. Bitcoin addresses are a representation of an ECDSA public key and there is a corresponding ECDSA private key. The method that you're doing (SHA256 hashing) converts the seed phrase into an ECDSA private key. You might want to read up more on how Bitcoin addresses and transactions work.

SHA256 is only used as a checksum in WIF. While you can still generate a WIF without the checksum, you cannot import it in any wallets because they do a check of the checksum and it would otherwise be invalid.

How are you generating the WIF? Are you using the SHA256(Phrase) and SHA256(SHA256(Phrase)) to generate the ECDSA private key and then converting it to WIF?

If so, then it would make perfect sense because if they're using brainwallet, then they would use the default implementation which is a single SHA256 and if they use a double SHA256 then they would be knowledgeable enough to know that it isn't secure.

For starters, not everyone would have access to the chips. US has a huge list of sanctions and restrictions to certain areas which wouldn't allow the chips to be exported there at all.

It wouldn't be clear if Intel would be interested to market them to the retail market or to provide them directly to the companies which would reduce the cost and complexity for them as well. The continual improvement in ASICs efficiency is a common theme throughout the lifetime of Bitcoin mining. It is well known that for an increase in the supply of efficient ASICs, the rest of the network would be stuck with their own equipment and would earn less, at a worse efficiency.

Of course you can, but that wouldn't be a fair scenario to consider. I can easily say that mathematically, the chances of it happening is 100% assuming that I replace urandom with a fixed entropy for every address generated within a single OS. Introducing and manipulating variables that would affect and skew the results wouldn't be very fair and is not what is supposed to happen under normal circumstances.

Not really sure how is the first scenario relates to address collision?

Sure. The number of possible Bitcoin addresses is practically in-exhaustable.

In comparison, you have a very limited number of T-Shirts. If you were to have a billion t-shirts and you wear a new t-shirt everyday, then would you feel the same as having 100 and wearing a new t-shirt everyday? There is a negligible impact on the number of addresses that has yet to be generated. I'm not sure why you're making an issue out of nothing.
Both. Not really a question, since you already know that it is mathematically almost 0.

You can use the RPC in Bitcoin Core to do so: https://developer.bitcoin.org/reference/rpc/.

You will need to have a tunnelling or VPN because the RPC connections are not encrypted.

It is a legitimate concern. You have the fee market, which functions on simple economics and that spam attack gets more expensive as time goes by. It doesn't mean that is hasn't happened before: https://bitcointalk.org/index.php?topic=1098263.0. It was at the peak of the block war where fees were consistently high and it basically rendered Bitcoin unusable without paying high fees. It would depend a lot on the attacker's funds and what they're trying to achieve. Practically, it does quite a bit of inconvenience but the costs is fairly high. Mining pools also have the option of selective censorship but it would be quite counterintuitive.

There is actually a cheaper way to do DDOS, not by the transaction size alone. You can also create transactions with high SIGOPs to get miners to mine them and leave the rest of the transactions with lesser SIGOPs. This isn't very effective IIRC, since they changed the SIGOPs limits and those higher than the limits would be non-standard.

All in all, it is very possible to have a DDOS on Bitcoin, simply because there is a limit to how many transactions can be in a block. It just gets expensive and pointless.

No. You shouldn't consider the timestamp to be anywhere near accurate, because it is not meant to be. Bitcoin follows the chain with the longest proof of work (POW). This means that all of the nodes automatically follows the chain with the longest POW, when they receive it. Hence, you have a double spend, or more specifically a 51% attack when an attacker is able to generate a longer chain with more POW, and by including the transaction which spends to another address.

Bitcoin uses the timestamp to determine the validity of certain transactions (nlocktime) and the difficulty increment. Otherwise, every block has its own block height which increases sequentially. In the block creation process, each individual block does not consider the timestamp of the previous block so long as it doesn't deviate too far from the MTP. There is quite a lax tolerance on the time deviation because it isn't possible for every node to be synchronized to the exact same time at the current state.

You don't really need to open the data directory to get to your wallet.dat, you might have a custom datadir anyways. You can simply go to File>Back Up wallet and use it to place a backup to make a wallet.dat to any location that you'd like. Make sure you're currently in the correct wallet.

A few things to take note:
1) If you're running it in Hierarchical Deterministic mode, you can just make a backup at the start. If you're in the HD mode, you should have a HD symbol at the bottom right corner.
2) If you're not running it in HD mode, you have to back up the wallet.dat every 100 or 1000 transaction. Generally, newer clients are HD by default.
3) You have to make a new backup for everytime your passphrase is changed, be it setting a new passphrase or just changing the passphrase.