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.

That is the actual value that goes into the nlocktime field of the transaction. As such, you can either specify a block height or the Unix time, depending on the value.

nLocktime takes either the block height or the time in Unix format. Electrum allows their user to specify the date and time using a standardized ISO8601 format, and converts it to unix in the background. If the nlocktime field is <500,000,000 , then the block height will be used. If any other value is indicated, then the block height unix time is considered.

You can't possibly 'waste' addresses. You can re-use them if you want to, though there really isn't a need or a very good reason to.

It is for a fact that we cannot possibly exhaust them no matter how many you use. There are people generating millions and millions of addresses to generate vanity addresses anyways, they still won't finish the entire key space. If the world manages to exhaust the keyspace (or even just generate 2^80 addresses), then we would have a security issue and that is not happening.

It is not that difficult to have a 51% attack. Foundary, AntPool, F2Pool and Poolin controls more than 51% of the network hashrate. How difficult would it be for an adversary to pay them a huge sum of money, or worse, an insider to attack the network? Difficult, but easier than purchasing or renting all those equipment yourself.

However, how much damage can it really make. Major governments are not really interested in attacking Bitcoin beyond just implementing stringent regulations against it. The reason is fairly simple; 51% is a known attack and it doesn't really come as much to the wider Crypto community. Such attacks are usually shortlived and unnecessarily expensive. A simple change of algorithm renders all of the mining oligopoly useless. There is that.

The other problem is possible vulnerabilities within Bitcoin, which has happened several times. Most of them were unexploited and patched early on and for the one time it was exploited, it didn't really amount to anything as the community recognizes those coins as illegitimate.

Not how it works. You won't be able to lobby a single miner because you can't do anything with your ASICs on a pure POS Crypto. I'm sure there would be tons of resistance to this and it is not an issue that we have to solve at all. Ethereum has had plans to shift to POS since years ago and there were tons of delay through the entire process.

You would definitely face a lot more pushback from Bitcoin community, primarily because the mining industry is far bigger than most crypto and that the community isn't particularly fond nor did they endorse POS.

The serialization of the raw transaction generated by Coinb.in isn't compatible with Electrum for quite sometime. The compatibility issue would likely remain as Electrum decided not to fix it in favour of PSBT and coinb.in doesn't support PSBT and hasn't changed their raw TX serialization.

The previous reply is correct. You need to update your cold storage if you want to maintain compatibility with the format generated by the newer versions.

Have you made a police report yet?

The problem with tracing Bitcoin transactions is that there is no obvious link and that the point where the funds were deposited into the exchange can very well be after the keys/Bitcoins have been sufficiently washed and passed around. There wouldn't be any incriminating evidence to freeze those funds. Exchanges are not known to be very cooperative with divulging their customer's identity without sufficient evidence to the authorities.

If you're aware that it has gone to an exchange, then you can provide it to the authorities and that is about it. No tracing services would be able to do much more than that.

CPFP is actually a very inefficient way of 'accelerating' a transaction. The user have to either intentionally make a transaction with a higher fee or do so in a subsequent transaction, provided that the next user doesn't care about the unconfirmed output. Mempool seems to accumulate over time and it would be far more expensive to do a CPFP later than to have an RBF now. I'd very much prefer having the flexibility of doing so without incurring additional costs or time. If I'm the merchant, I'm definitely not looking to wait for a transaction to be confirmed in a day or two.

For starters, credit card settlements and Bitcoin transaction finality are completely different and they cannot be equated to be the same. The former has some accountability on both the user and the merchants and there is a case to be contested for most cases, not the main point anyways.

Customers won't be there to defraud you for a cup of coffee or for lunch and it really depends on the risk tolerance. It's either LN or you pay and I make your food, by the time I serve you, the TX should probably be confirmed. I'm not sure if the customers would be willing to do a transaction without RBF, knowing that there is a possibility of the funds being stuck for a while. I won't be comfortable with that and I don't really think it is a good way to manage the risk or neither is it a good trade off, but that might just be me.

---

Any attacker having more hashrate than the rest of the honest network will always be able to mine any number of blocks more than the rest of the network, given time. The 6 confirmation rule is based on game theory and is not a strictly mathematical concept. 6 confirmations can be enough for any other altcoin, so long as you think the amount being transacted is very much less than the cost of the hashrate for 51% of that network.

I don't recommend people accepting unconfirmed transactions, because you are creating potential problems for yourself and your customer. If it remains unconfirmed for an extended period of time, you won't be able to spend it and neither will the customer be able to spend their change. The latter is more than fine, because you should be accepting confirmed transactions. The volatility of the fees in recent times hasn't been very kind and there is still a good enough possibility for the customer to be able to push it directly to a mining pool, RBF or not. Which is what my point on this "false sense of security" about.

If you absolutely have to accept unconfirmed near instant TXes, do so via lightning network. Though 10 minutes for a confirmation isn't always undesirable.

Not necessary. Disabling RBF does nothing other than preventing another miner from potentially mining a competing transaction by chance. If there is any ill-intent present, then there is no point asking them to disable RBF because they would have gone a little further to try to get their transaction to get double spent. There's this misconception that disabling RBF prevents any easy double spending but that is false; the primary purpose of RBF is to allow users to replace their transaction with another that spends a higher fee and disabling defeats that purpose especially in instances where fees spike were to occur.

The one and only way to be certain is to wait for 3 or more confirmations (if you are that paranoid). Otherwise, there is little to no security benefits. Anyways, stale block candidates are easily detectable with a well-connected node. It isn't a big problem.
Record is about 6 in a very specific scenario, IIRC. Otherwise, normal circumstances would be about 1.

The definitions defined in the claims are incorrect. Bitcoin is decentralized, can you shut down all of the nodes and erase Bitcoin? It is far easier to do so for the banking systems, and the point about lifesavings isn't really about how secure it is. If you cannot be trusted to manage something as simple as this, then you would be a great target for other SE or scamming attempt. The point with volatility is perfectly valid, but I see it as an inherent problem in the people's mindset and not with cryptocurrencies in general. They should address the root cause of the problem, by educating them and eradicating this fallacy.

Point 4 and 5 are not even worth discussing.