Oh I see. I didn't notice that. Yep, that's probably it.
Only happens when you're opening the link in a new tab. Refreshing the new tab solves the problem.

---

Broke the merit extension that I'm using too but it's no big deal.

I've been getting a bunch of error 403 when opening the pages in a new tab. I've tried clearing cache and it still persists. Is it a forum-wide issue or is it just me?

Do you read and review the source code?

Don't get me wrong. I also prefer open source codes over closed source ones but its a stretch to assume that just because something is open source that means it's completely safe. That's the same sense of security that phishing attacks has evolved to exploit. Some users were tricked to install fake versions of Electrum that were hosted on github. Some users assume that just because it's hosted on github and having the source code visible (albeit modified with small malicious codes), it is safe.

The point I'm trying to make here is that just because something is open source doesn't mean it is superior over another that is closed source. Ledger has a NDA which means their secure element cannot be open source. Some prefer Ledger and some prefer Trezor but most don't consider the fact that Ledger doesn't have an open source secure element firmware. Hardware wallets are for-profit companies and they have to keep certain proprietary contents secret.

If any hardware wallet stores any sensitive information on SD cards, throw it away. You're paying some hefty sum for a hardware wallet and it shouldn't be that easy to access private keys or seeds. ColdCard is like an airgapped wallet and the SD card is used as a method to transfer PSBT files to and from the device.

That being said, no it stores the seeds and the keys within it's secure element. You can actually build your own Trezor though that'll require some technical expertise. If you're doing that with a Raspberry Pi, I believe airgapped storage would be much more straightforward for you. It doesn't have a secure element anyways so it makes no difference.

---

Open Source does not necessarily determine it's level of security. People can't seem to get it inside their head. There is still some level of trust when you're buying a hardware wallet, be it the personal information stored when purchasing or trusting them to not have intentionally included any backdoors (not very plausible but of course still a possibility). You have to make your own judgement based on the price of the device and/or the track record of the company.

How did you create the BTC wallet in Electrum? Did you use a seed? Did you select 2FA? How does the wallet look like.
If you import your BTC wallet into a BCH wallet, you should be able to see the transaction and thus your funds. You can spend your coins and send the funds to another BCH address. What problems are you encountering?

The mempool is dumped onto the disk at shutdown. It's contained within mempool.dat within the data directory.

CMIIW, the reference client synchronizes first before repopulating the mempool again. It would make sense for them to catch up with the best tip so that any transactions spending the same UTXO within the mempool can be removed more efficiently.

My take on the issue is that discrepancies between mempool size should be a result of the user's configuration more than the nature of the propagation of the transaction. I've previously ran a node and a pruned Bitcoin Core node. When I did arbitrary comparisons, the difference between the two was fairly small, think less than a MB. It's no indication of the bigger picture but I'm inclined to believe that the difference should not be excessively big.

No... That literally the opposite of what he says. Hardware wallet providers should not have access to your keys. They cannot control how you spend your funds. They could possibly push out a firmware update which requires the user's participation to brick the device but your funds will be recoverable from the seeds.

If you are in sole control your seed and by extension the private keys, you are not in control of any companies and/or wallet providers. You can and will be able to import the seeds or private keys into another wallet and use it normally.

Electrum does not have a BCH software. It has a fork that was modified for BCH but that is not from the same author as Electrum.

Bitcoin Cash is a fork of Bitcoin and certain address types are valid for both. It cannot be reversed. Electron Cash is a fork of Electrum. You can export that specific private key and use any wallet that supports Bitcoin Cash to get your funds.

You have to do it in the client. Click the Window Tab and you should see an option called Console.

Try going to Window>Console and type in this:


The warning usually occurs when a block is marked invalid by user inputs. I could be wrong in this case but it would definitely be worth a try.

It worked for another user that I helped previously but I was unable to diagnose the problem. Regardless, could you go further into your debug.log and see if there's anything that states marking this specific block invalid?

They don't. You actually don't need to specifically run Bitcoin Core to operate a mining pool. You can use a derivative of that and function just as well, providing that the transactions and the blocks conform to the rules that are implemented.
The only real way to mitigate your concerns is to learn C++ and start reading the codes. If you can't, there is no way around your concerns.

It is true that you have to trust others if you cannot validate the code in it's entirety. However, each release is signed by several developers within the community[1]. Anyone can create their own gitian signature so the best way is to build a well established PGP WOT to be sure that you can trust the people signing the release and that nothing malicious is added.

[1] https://github.com/bitcoin-core/gitian.sigs

You can compare with each RCs and you'll have way lesser codes to deal with. Normal users shouldn't be running RCs anyways but it'll give you some time before the stable release and have lesser codes to review from the final RC to the actual release.

I think dumpwallet would suffice, doesn't need to be synchronized and shows all the keys.

OP, if you choose to not synchronize but can put up with importing loads of addresses, you can go to Windows>Console and type in the following.

Replacing the directory with whichever directory you'd like.

No. Quantum computers can be good at factoring which would result in the private keys to be derived from the public keys in about 128^3 operations as compared to the 2^128 in classical computers.
Most people cannot accurately determine the sheer range of addresses there is. Even if you consider the birthday paradox, your chances are still very low, 1 in 2^80, to be exact. The cost and the time wouldn't be worth it, earth would probably not exist by the time you find a funded address.

I removed the remainder of the quote because it's literally the same exact point. 60% of the miners are within the geographical boundaries of China. This means that the government can potentially seize and control 60% of the network's hashrate.

You only need 51% to be able to have a 51% attack. Bitcoin isn't centralized but the concentration of miners makes it less than ideal.

It's possible, but not straight forward.

Bitcoin Core doesn't have native support within the client for HW wallet but you can use a python program as a bridge between your hardware wallet and the client. The program only relays information to and from Bitcoin Core and your Core client becomes a watch-only wallet.

There's a guide here: https://github.com/bitcoin-core/HWI/blob/master/docs/bitcoin-core-usage.md
Repo for the "plugin": https://github.com/bitcoin-core/HWI

Why would they want to control Bitcoin? In the grand scheme of things, Bitcoin doesn't really affect them, if at all. Attacking Bitcoin doesn't really benefit them and would just be a waste of time.

They also need a huge land space and loads of people transporting and setting up the miners. That is if they acquire ASICs that makes up 51% of the network hashrate.

We fork Bitcoin to another algorithm. CCP continues mining SHA256d coins only and we can easily shift to another algorithm. CCP doesn't have any advantage over another mining algorithm and life continues.

---

One things for sure, they won't gain any tangible benefits from that. It's much more likely for pool owners to collude than the CCP intervening.

As of Bitcoin Core 0.20.0, the client does not automatically import bootstrap files. In fact, as of 0.10.0 it can actually be slower than synchronizing directly most of the time; downloading the blocks in parallel and verifying at the same time will reduce your synchronization time exponentially. Downloading bootstrap.dat still means your client will spend some time to verify the blocks.

If you want to continue, you have to specify -loadblocks=bootstrap.dat as an argument at startup.

Electrum supports BIP39. Confusion stems from the fact that they didn't implement it a long time ago and instead used their own format.


You can use scripts to convert your seed phrases to BIP32 xpub or xpriv. I wouldn't recommend you to use any scripts unless you know exactly what you're doing. Using a BIP39 compatible wallet and sweeping the funds to a new wallet would be a way better idea.

You might want to see if this[1] fork will be better, it's far more active than the previous repository. As with your chances, it would probably be not worth your time unless you have some vague idea of the password. AES-256-CBC is not particularly weak.

[1] https://github.com/3rdIteration/btcrecover

Download the blockchain again. That's the only way you'll be sure that you get all the funds within the wallet.

If you're sure your last transaction was made about 2012-2013, you can synchronize till the blocks in that timeframe. It should show you the relevant transactions during that period of time.
Seems like a Multibit Classic wallet file. If you've exported an unencrypted backup, you can restore it by opening it with a text editor/notepad and the private keys should be organized neatly with the corresponding addresses.