... Check your blockchain.com wallet against your account?

---

---

There's no restriction on what address you display on Bitcointalk. In fact, I doubt many people actually use the address on their profile as their main address. If you're talking about whether you can change your staking address, just stake a new address and I don't think anyone would really care about it.

Wallet.dat can be modified to show fake addresses to show to the user without the actual private keys being inside. Sending someone your wallet.dat, encrypted or not is never a good idea. It is very much possible for someone to be able to copy your private keys and sipon the funds from your addresses in the future. Whilst there is currently no known vulnerabilities that allows for code execution within the wallet.dat file, I wouldn't trust it too much.

But Bitmain is mainly an ASIC manufacturing company. It would be way more worthwhile for them to continue to improve on their ASICs and continue selling them. If they were to attack Bitcoin, it would just be like shooting themselves in the foot; investors won't be happy and the whole ASIC business would probably go down the drain as any new cryptos would then make their coins ASIC resistant their priority.

They would probably face some lawsuit from the people that they stole the Bitcoins from.

The theory is valid for the things that has a finite supply and the supply cannot be increased immediately. While the market capital is capped at 21 million Bitcoins, the denomination of Bitcoin is fairly big and there is no intermediate danger of it running out or else there would be a lot more billionaires in the world. Even if it does, somehow run out one day, a simple code change would allow the network to be forked and have an even smaller denomination.

IIRC, there were some noise about how deprecation of bloom filter could be detrimental to the SPV wallets. I concur with their statement that given the current node distribution, there should still be sufficient nodes available for SPV client for now. I believe that bloom filter have some fundamental privacy issues that can't exactly be solved. Efforts has been made to introduce new standards such as BIP157 and 158. I think it's still a good direction in forcing SPV wallets to be receptive in changing out bloom filter for something better.

The only thing a larger hashrate does is to deter individuals without a significant resource to execute an attack. The graph indirectly portrays how much resources in monetary terms is needed to execute an attack. Given how some of the cryptos uses novel algorithm, it would be tougher for a malicious entity to acquire enough resources to be able to execute an attack. In contrast, given how ASICs are prevalent in SHA256 coins, it would be easier for attacks to be executed with it, no matter the cost.

It also doesn't consider the fact that for some, there may be different motivations for an execution of an attack and monetary cost might not matter.

No. Back up nodes are also hard-coded into the source code. In the event that the DNS fails, the client would then try to connect to the reliable nodes that are listed within the code itself. If all else fails, the client has to manually add the IPs himself using the command-line option which is not difficult.

The client would try to establish more nodes to connect to by the getaddr message sent to it's peers and build a peers.dat which includes some nodes which it has succesfully contacted previously.

Seems more of a hassle and a marketing gimmick to me than anything else. The whole concept relies on the fact that a intermediary is required for the transaction to happen and all this does is to make a request to them to transfer the funds internally between their systems. It doesn't involve the Bitcoin blockchain at all and in a way, it's just like how fiat transfer can be done by SMS too.

IMO, this is quite pointless and isn't something worth talking about.

Bloom filter is a feature introduced in BIP37 which focuses on allowing SPV clients or lightclients to be able to obtain the transactions relating to their addresses without a lot of bandwidth usage. It is not an evil implementation at all but it's just that at that point in time, it was the most suitable way for lightweight clients to obtain their information.

When the reference client obtains a set of bloom filters, it would try to scour through the blockchain to find transactions relating to the address and/or UTXO and send it back to the light client. While this is not exactly resource intensive, it would be a potential attack vector for DOS attacks. To help to phase out BIP37 to pave the way for better implementations, the developers has made it an option for users to disable it to reduce their resource usage and they predict the current SPV clients can still function with the current number of nodes with bloom filter.

Peers connecting to you for bloom filters are not necessarily bad but they do not contribute to the network as any other full node would. You would still be helping SPV clients if you choose to allow peers to submit bloom filters.

There's a list of DNS seeds[1] within the code itself. The DNS seeds are domains that ONLY give out a list of well connected seed nodes. The seed nodes are the ones which has a high reliability and a good connection. After a connection to the seed node, the client can then obtain more peers information by querying the seed nodes.

If all else fails, there is a hardcoded bunch of seed nodes within the client itself.

[1] https://github.com/bitcoin/bitcoin/blob/b83565625e32b22395e28c1965b2e42fc17f04d7/src/chainparams.cpp#L116

You can. Trezor is BIP39 compliant which means you can easily import your seeds to another wallet which would allow you to spend the funds with the same addresses that was in your Trezor HD wallet.
Can't dispute this. I would mitigate it by using Electrum instead of their servers though.

Depending on your server's hardware and specs, synchronizing and parsing the blockchain could be much faster than you think. I would say it would be a better idea to host your own server; the uptime of your local server would still be relatively reliable and you won't have to trust a third party to supply you with the correct information.

I wouldn't say hardware wallets are good for anything requiring frequent access to the coins. Sure, it is possible to just function with the xpub exposed but automating it would be a hassle and using a client with RPC function would be much more viable.

And at the same time, before the transfer gets confirmed, your 1 billion USD worth of Bitcoins could suddenly become a few hundred million less. While it's true that Bitcoin has quite a few upsides, you can't deny that there are some intrinsic advantages to fiat that Bitcoin can't match. I'm not dissing Bitcoin or anything but when the market isn't regulated and backed by anyone, Bitcoin would remain this volatile for a very long time.

Even for my 2 year old laptop, the synchronization could take quite a few days even if the dbcache is set to 1GB and the computer is just left running (barring any crashes). I haven't been able to test it on the RPI 4 but I imagine that it would be a lot worse. IMO, the most efficient way would be to pre-sychronize the blockchain on another more powerful computer before loading it onto an SSD and starting it on a lower power computer.

Whilst generating a paper wallet on an offline air-gapped computer is certainly one of the safest ways to store your BTCs, there's no way that it could be 100% secure without you inspecting the code yourself. For paper wallets, they use the entropy using your browser. While I haven't seen it happening from the javascript address generators itself, it has happened to quite a few wallet implementation resulting in the funds being stolen.

Doubt it would be a significant issue given the audits that the community does on the major paper wallet generator.

Given the Bitcoin's goal of being an asset with the fixed total market cap, it would make more sense to have a lowering inflation than an increasing inflation. The increase in inflation makes Bitcoin less scarce as time goes by and whilst it doesn't favour the early adopters, it doesn't favor anyone at all.

The cost of mining does play a part in this; the steady decrease of the increase in supply helps the miners to cushion the impact on their loss in mining. Whilst the decrease in supply does result in an increase in price, ceteris paribus, it doesn't work in the real world. The mechanism to help the miner earn a profit is actually the difficulty. If the miners doesn't earn enough profits, some of the miners would shut off, difficulty would drop and those who are still in the game would earn more. It would achieve and equilibrium such that only those who produce a profit would be able to mine. The price isn't the only factor affecitng the miners.

For withdrawals, the user will generate/provide their own addresses for the funds to be sent. Many sites uses a system called hot wallet whereby the funds are stored in a few addresses that the site controls. The funds will be sent from the individual addresses to the hot wallet and the site would also send the funds from the hot wallet to the withdrawal addresses provided by the user. Depends on how your site functions, you can either give the user the full control of their coins (ie. like they own the whole address) or less control (the owner controls the Bitcoins). This would then be the determining factor as to whether the transactions should be crafted and signed client side or on the server side.

You'll need a database to keep track of the user's addresses and the Bitcoins in each of the addresses. Ensuring the security and managing the Bitcoins for users is no easy feat and it generally isn't recommended for anyone to develop wallets from scratch.
To craft a transaction, you don't need a full node or any client for that matter. All you need is to write a code which manages the scripts and signs the transaction using the private key. It isn't very hard and there are quite a few libraries[1] that you can use.
DNS seeds fetches the IP addresses of a few nodes that are always online on the Bitcoin network. The seeds are not nodes by themselves and you cannot request any usable information about Bitcoin blockchain from there. You can only query and send information over to the Bitcoin node but you can't connect to them to create transactions.

I won't recommend you to only retrieve information without further verification. Operating a payment server without operating a full node is dangerous given the attack vectors.
[1] https://github.com/1200wd/bitcoinlib

The power in my area supplies 230V power. I've been looking around recently but I couldn't find anyone selling Antminer R4 or else that would be a pretty nice machine to have.

I'm looking for cheap and quiet ASIC miners to keep as a hobby in my apartment. They must be relatively quiet, the hash rate doesn't really matter all that much.