You don't have to delete the blocks, doing so would just result in additional bandwidth and time wasted to download all the blocks again. You should run Bitcoin Core with a -reindex flag. It'll rebuild the blocks using the existing data again and will take quite a while.

OP, did the client prompt you to reindex or are you encountering any errors in the client other than the debug.log.

Other than the other two, you can actually improve the speed by making Core assume that blocks are valid up to a certain higher block height. I do not condone this as it means that you're validating your block less and that if whatever data source you're getting the block height from is malicious, you'll have very serious repercussions.

Else, whatever nc50lc said is correct. If you're synchronizing a Bitcoin Core instance for your own usage, you can only increase dbcache to improve the synchronization. In my case, I was synchronizing the testnet client so it wasn't of much risk for me to do so.

You can't get all your transaction information if you don't synchronize it. SPV wallet or not, you're still synchronizing your wallet. It's just that SPV wallets are way faster than Bitcoin Core due to the fact that SPV wallets only download the block headers. You can't use a wallet without synchronization because you'll likely get outdated information which wouldn't allow you to spend your coins.

That's a good point. Make sure that in the payment tab, the excess are sent to the change address which is highlighted in yellow.

---

Sidechannel attacks are troublesome to do and as long as you close the curtains and don't let anyone gain physical access to your cold storage, I think that's sufficient and the difficulty of executing a sidechannel attack is still fairly high.

If you do an analysis on the power consumption of the computer, you could see a tiny spike in the power consumption of the device. That could leak the keys to the attacker. EM wave radiation, cold boot attacks all could pose a problem. I don't think any computer is specifically designed against that and even so, it would be difficult/impossible to remove that as an attack vector. I would be much more concerned about who would have access to the device than a side channel attack. I cited that as an example of how devices that are not specifically designed for such usage could have lesser safeguards (duh).

Tldr; I think if you're not saving too much money in the cold storage, t'll be pretty sufficient. I've relied on my raspberry pi to store my funds for the past few years and it has never failed me. I'll be getting a coldcard though, not because I don't trust my raspberry pi set up but it's just that I'm intrigued by one.

Side channels through the analysis of time delays and CPU spikes when signing could present an issue if someone with plenty of resources is really really interested in your coins.

The main vulnerability would lie with how Electrum is designed, might somehow generate weak keys. It's a possibility but you bet that's one of the few areas (address generation process) we look at when inspecting the code. Besides with RFC6979, you don't have to worry about address reuse. And this could happen with hardware wallets with a faulty firmware as well.

Aside from the lack of physical protection, I think it's a decent set up for a moderate amount of coins. I have a similar set up to yours and I've felt pretty safe with it.

Not that I really would recommend it but it does seem to be something out of the ordinary. Would you consider using coinb.in to script a transaction and sign it using your client to send it to another wallet that you know you control? You'll need a little technical knowledge to do that though, could be slightly risky so you could experiment spending a tiny amount first.

I don't think I have experienced/seen Bitcoin Core not showing the balance, especially when it sees the transaction. I consider that one of the last resort if you still can't access it after following Loyce's advice.

Go to Windows>Console and type the following, skip the first one if your wallet is unencrypted, replacing the password accordingly:

And


Try again if it works. If not, what does the console say?

Hmm good point, marginal utility usually decreases. Unfortunately I don't have a computer science degree so I won't be an expert in that area. I would love to see what's the optimum amount.

But the crux is that if you're not running a full node, you can't validate the info that you received and that is thus not ideal. I don't think that there would be an optimum number of nodes to have, having more nodes on the network doesn't decrease the experience for everyone else but it'll improve redundancy. You can have 100 nodes for the network to work but the degree of redundancy would be low. Since they aren't compensated, there shouldn't be any cost borne by anyone else?

Transactions are never encrypted but yes, Electrum does have some privacy concerns. If you do want to protect your privacy, you'll probably be looking at Wasabi Wallet, Samourai Wallet etc. Their built in privacy functions is probably more useful for a user who wants impenetrable privacy.

I think you missed my 1 CPU 1 Vote argument. In the older days, mining requires a full node due to the pools being practically non-existent then and the profitability of a CPU was fairly decent. People are compelled to run a full node to mine because SPV wallets aren't really suitable for mining. Proliferation of ASICs and pools has also resulted in miners joining pools to have less earning varience as well as a higher reliability; they don't have to run full nodes to mine anymore. (Joining a pool would probably distort the 1 CPU 1 Vote ideology anyways, probably would have to run their own nodes)

Ideally, as many nodes as possible is the main goal. I haven't really found many businesses actually running their own full node. It's way easier to have a ready-made integration than to have to build the backend to handle transactions yourself. I'm not talking about those who are primarily dealing with Bitcoin transactions, but those merchants who see Bitcoin as an alternative form of payment and are likely not concerned about the disproportionate cost-benefit that having a full node would bring.

I understand that running a full node isn't all that bad but for a newbie who wants to use Bitcoin immediately and businesses who just wants to accept Bitcoin, is a getting a full node really their first choice?

Nope. I just tested it out myself. If you don't specify --android-pin, it'll automatically try to bruteforce using the passwords. Of course, if you have even the slightest idea of the passwords, you can try using tokenlist or passwordlist argument to greatly speed up the process. You'll have to test it out yourself though, I couldn't find my old android backup so I had to create a new one myself.

HD wallet didn't exist that far back and it was only adopted in the (relatively) more recent versions of Bitcoin Core. You'll want to try to see this [1]. There's a section specific to the Bitcoin Android wallet.


[1] https://github.com/3rdIteration/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

I definitely hope they are. Is 372 nodes enough? In the theoretical scenario of 1 CPU 1 Vote, the number of nodes would've be in the tens of thousands. Businesses don't usually run their own node, at least from what I've observed, most are using either coinpayments.net and bitpay. It's way easier to have a service do the payment for you.
 
IMO, disk space and internet bandwidth is scarce for the average joe. When alternatives like Electrum and other SPV wallets exists with little to no synchronization needed, most would choose them over a full node.

When alternatives that are better than running a full node exists, the average user won't run a full node. The tangible benefits is just too little.

How many businesses uses their own full node and not a third party payment processor? How many exchanges are there? I don't think the count would be anywhere near the thousands.

If you're talking about the cost of having a full node, you can't simply estimate it based on the cost of the computer alone. You need to be able to have a interface that can be used to connect to your full node.

SPV clients and pooled mining has diminished the need for a full node.

You've given us too little information. What version are you using, did you modify your Bitcoin Core in any way?

It's usually due to a corrupted block file and would require a reindex. I assume you're asking as the next line says failed to read block?

Lot #1 - 0.001BTC

0.01BTC

Of course it's good news. The scheme is stopped and the funds aren't going to the scammers anymore.

I guess this implies that the government control 1% of the Bitcoin's total supply. But remember, the amount that they potentially seized is just a tiny fraction of their GDP. It is honestly just pocket change for them and they're probably going to just auction it off or hold onto it, which is great no matter how you look at it.

Is that an issue with the government or is that an issue with Bitcoin? Anonymity doesn't present any issues that would interfere with the basic human rights. It's their own rights to their privacy and governments shouldn't have the liberty to track the activities of their citizens. Using methods to conceal their identity shouldn't be illegal or cause any concerns at all. If governments starts to ban Bitcoin on the grounds of anonymity, then I think Bitcoin is fulfilling it's primary purpose.

Shutting down the exchanges will hinder the adoption of Bitcoin but isn't the main reason why Bitcoin is created specifically to promote freedom and circumvent the flaws of the fiat system?

I'm looking for 1x GPU in the ball park of 300USD or so. I can definitely go higher depending on the model, condition of the GPU etc. PM me your offers.

So you haven't synchronized your client yet? The error usually only appears when you're out of sync.

You shouldn't send transactions till the Core synchronizes completely due to the potential lack of information. Just wait till it synchronizes and your fee estimation will work.