It works for me, Electrum 4.1.4 and ColdCard 4.1.1.

Is your ColdCard on the correct file format? Assuming that you do not hold anything sensitive on your SD card, you can try formatting it. Do backup anything you want on the SD card first. Afterwhich, go to Advance>MicroSD Card>Format Card. This will remove everything from your SD card and use the correct file system.

They aren't. If anyone were to send you an invalid block, your client would just reject it and follow the longest chain. This isn't the case because the block is valid and it is also in the longest chain. That is why you're always stuck at synchronization.

It shouldn't happen at all. This means that Core wasn't able to validate the block when it first saw it, perhaps due to it being unable to validate certain data within the block. But yeah, as I said might be your USB controller which can't be fixed unless you swap it out or use the internal drive.

That is actually the equivalent security only (given similar conditions except blocktime). The math, as with the whitepaper involves the calculation in terms of the number of confirmations, not time. The probability of an attacker catching up from X blocks behind decreases exponentially with an increased X, given a hashrate of <51%. Probability People often approximate it for 1 hour, just because 6 conf = ~1hr.
Orphan blocks are child blocks received by a client that has not yet received the parent block. You are most likely referring to stale blocks instead.
It depends. As said, it is a tradeoff between getting stales and a faster block interval. I don't think faster blocks are necessary, but if you need on-chain capacity right now then a bigger block would be the most direct solution.

Stale block occurs if miners aren't mining on the same chain as a result of them seeing different blocks at the same height due to a delay in propagation, etc. To prevent this, the miners just have to well connected, not a problem, we already know miners were having internal network of sorts and in certain cases SPV mining on one another. Ensuring good connectivity is to their best interest. Validation of blocks takes less than a second for miners and propagation throughout at least 50% of the network takes less than 10 seconds, I know a few research papers referenced the propagation time[1], not sure about the accuracy but I'm compelled to think that it is rather fast. So long as you can propagate the blocks efficiently and ensure that the miners are able to receive information in a timely manner, that shouldn't result in a far greater increase in the stale rates. As long as the majority of your miners are well connected to each other, then the stale rates wouldn't become that big of a factor.

Propagation of blocks or information in the network has improved tremendously throughout the years. Compact block helps with decreasing the delay with the propagation, FIBRE used to do so as well.
I can't find any benchmarks on that. I'm assuming that since hashing the (relatively) few block headers is about the least resource intensive task, a small increase in the time shouldn't affect it too much. Signature and script validation are far more time consuming. Unless you're telling me the CPU hashes at the rate of 1 per second?

[1] https://sites.cs.ucsb.edu/~rich/class/cs293b-cloud/papers/bitcoin-delay says 6.5s for median, but it was quite a few years ago.

If the actual stats is 6.5s, then 6.5/600 is the stale rate would be 1.08%, if 300, then 2.15%, assuming the majority of the miners also sees the block at ~6.5s. It is twice the probability but the pros would still outweigh the cons. Bitcoin's landscape and some of the functions has changed throughout the years, not all assumptions still hold true. Note that the percentage also assumes that the economic majority receives the block around 6.5s. The actual time could be even lower <50% of the sample size.

It shouldn't make that much of a difference. The most algorithms don't actually take far longer than Bitcoin nor does it take the bulk of the time to verify.
IPC has been increasing on year on year basis. It is becoming less of a problem and my validation from scratch takes about 7 hours. The issue here isn't about that though; the whole point about having more bandwidth is such that blocks can be relayed though the network quickly and thus reducing forks. The main concerns with a block interval that is too fast is that if the propagation is too slow, the network would be less secure due to the possibility of different forks on it.

---

It is all about compromise. If you increase the block size to match the current levels of your major payments systems, the block size would be absurd. It is possible to have faster block times and larger block size, other altcoins have done it and are still surviving well right now. Segwit is in effect a block size increase as well.

This email is quite old[1] but this was in the middle of the block wars.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Look at the second link[1]. Was the address inside a code tag or not?

Google indexes the topic per page as a whole. The sitemap specifies this.

[1] https://bitcointalk.org/index.php?topic=996318.msg56338980#msg56338980

Yeah. The few directory authority were overloaded and couldn't generate a live consensus, which the client at that time needed for v3 address. v2 should've been deprecated for sometime now, it can become a security/privacy risk[1].
It's getting deprecated anyways, but of course the sooner the better. They are already deprecating the code by the mid of the month. V3 is just better than V2 in every way.

[1] https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html

Correct, we should never do that. There is a very specific reason why it was removed from the code, and any changes would probably take a while for the network to adopt. Unless you know that someone is already doing so, then once you release the client, they release their own chain.

Now to address why it isn't necessary. There is no reason why anyone would do a 51% attack over a few hundred blocks. If you're in for the profits, your total gain must be at least the sum of the block rewards. So if we were to approximate it, over a hundred blocks, it would be currently 19 million dollars. Why would anyone spend 19 million dollars on an attack like this? If you want to make a statement, just orphan blocks as you go. People will panic, price will crash and it is so much cheaper than mining on a separate chain. Checkpoints are not fundamentally useful in nearly any motives for a 51% attack.

If we had a good pre-emptive measure against 51% attacks, it would have been implemented a long time ago.

They will know, we won't. If you're occupying a huge space and you consume a huge amount of electricity, either you're growing marijuana or Bitcoin mining. To confirm which is it, just go and take a look.

Well, perhaps they see it as a threat and they don't want to endorse any part of it. If you were to destroy Bitcoin, another crypto would just rise. This time even higher than Bitcoin, there is no point.

Previously, Bitcoin Core generates the addresses randomly, 100 addresses at a time is maintained. That requires the user to backup their wallet every 100 transactions.

Afterwhich, the hierarchical deterministic mode is introduced and allows the wallet to generate addresses based on a fixed seed. You only need to backup your wallet once, unless you did a password change. There should be a HD symbol at the bottom right to indicate whether it is a hierarchical deterministic wallet or not. Wallet files are backwards compatible.

A slight correction, was just reading through my posts. Core actually generates the address as soon as an address is taken out from the keypool so that the keypool always maintains at least 100 or 1000 (depending on version or your own configuration). The rule of thumb is to have a backup every 100 transactions so even if your data is lost at the 50th transaction, you still can restore your wallet using the wallet.dat as all of the 50 addresses used were in the keypool when you made a backup at the start.. Note that this applies to both sending and receiving(with a new address), Core uses change address which makes for an extra address being used from the keypool. Ideally, I would overlap the wallet.dat, so I'll probably back it up every 90th transaction or so, just in case I forget.

Good thing is, HD wallet still contains a keypool but the addresses are generated from a seed, which as I've highlighted doesn't change unless you were to change the password. In the case of a password change, the keys from the keypool are dumped into the new wallet.dat and new addresses are generated in the keypool from a new seed within the wallet.dat. That is why you have to back up the wallet after a password change.

Probably not such a great idea. V2 addresses are not critically insecure, they're still okay for normal use but their end of life is long overdue. V3 is of course better, but I'd rather stick with Tor than use a VPN.

VPN is okay if you want to obfuscate your traffic from your local ISP. But the VPN provider will be able to see your traffic and do some fingerprinting as well, if you use their proprietary apps. There is still a potential for them to be keeping logs or are corporative with any mass surveillance. Besides, Tor bundles a nice browser with sufficient privacy measures as well.

I remember replying to a thread about this, not sure if you were the OP.

It is a pre-emptive measure against collision attacks, not that it is currently a security risk. P2WSH addresses are all longer than P2WPKH, not limited to multisig.

IMO, no. There was once a discussion about disabling ECDSA dependent keys (actually I think it was about burning Satoshi's coins) to prevent QC attacks in the past and that idea generated significant resistance. I don't expect the community to be more welcoming to ideas like these.

Important to note that such an attack requires the collision to be done beforehand. P2PKH which uses hash160 is not vulnerable** (preimage, instead of collision) ->That still requires 2^160.

** In hindsight, wording was confusing. But the post after this explains why P2PKH/P2PWKH isn't affected.

The code behind it isn't obscure nor that complicated. The concept is what matters, the code really doesn't. If you want to dabble in it, you have to have some degree of technical competency. Even to this day, most people either have zero understanding or some misconceptions about how it works. The fact that it was conceptualized so early basically means it would've been developed with or without Bitcoin, sooner or later. Whether it gets any adoption is an entirely separate issue, considering the cost of implementing it, it probably isn't very great for the companies without all the PR. Cryptocurrencies popularized the idea of it and companies are jumping on the hypechain, that's all.

Obviously, there would be no way to tell whether my statement is true or not.

Read it again. I'm sure you know the reason why. Try living without taking a car or without plastic for a month.
Right. Yet, advocates for Bitcoin mining (and Elon Musk) almost always turns to green energy as a solution for the *environmental impact* of Bitcoin mining. Surprise Surprise, your green power isn't always very clean. Saying Bitcoin mining isn't environmentally friendly, and reversing afterwards by talking about "green" energy is ironic. People tend to tackle this problem from the wrong direction (POS is wrong too).
That is what generates the click. The Bitcoin circlejerk by the media can get quite annoying.

---

Fair disclaimer, I'm not against Bitcoin mining or anything. In case some of you think that I've got something against Bitcoin. It's just that some arguments just doesn't make sense.

Checkpoints wasn't meant to prevent 51% attacks actually. You're either going to have someone babysit Bitcoin by assigning checkpoints or just having a moving checkpoints. Either of which isn't ideal and people seems to think that the checkpoints (often thousands of blocks deep) were meant to prevent 51% attacks. Not true and we've switched it out in favour of assumevalid.

I actually vaguely remember someone (I think Gavin) mentioning something about limiting re-org blocks but that wasn't really developed any further AFAIK. There simply isn't any reason why anyone would want to attack Bitcoin, the total cost of the attack and your ASICs probably cannot be covered by the profits from the attack. It is really not in their best interest to try to attack Bitcoin, too little incentives. Just move elsewhere with your millions of dollars in ASIC investment and continue generating profits.

You probably won't know which are the larger farms, some of them were quite stealth with their operations due to the nature of it.

Your concerns aren't unfounded, motivations goes far beyond monetary. But given the evidence that we've actually been seeing, I highly doubt that would be the case. CCP probably doesn't lose sleep over Bitcoin anyways, any attacks would've happened far earlier.

Not really. The idea was actually born quite a bit earlier, in the late 90s. Just check the references that Satoshi made in the whitepaper. Bitcoin was never really treated as a scam, if you actually read the whitepaper then you'll know what's going on.

Satoshi didn't conceptualize the idea of it, he basically combined the various ideas; b-money, distributed ledgers, etc into Bitcoin AND made it work. I have no doubt that even without Bitcoin, Blockchain would've appeared sooner or later but without all the hype. Blockchain is mostly just a snakeoil. Corporations love to use it with their sentences, makes them sound cool and brings some nice PR.

This isn't accurate. Satoshi consulted several people who conceptualized something similar. Check out B-money.
Come on, check the code from the first iteration first. It is neither complete nor perfect.

Oh boy. This is wrong too.

The divisibility or the denomination of Bitcoin solves the problem; value can be proportional to the fraction of Bitcoins that you own.

The value of Bitcoins divided by the population will definitely be much lower, due to the burned coins, either intentionally or unintentionally. Bitcoin is designed with a decreasing inflationary trend, but by the definition of purchasing power, then we've had quite a bit of inflation in the recent years. Bitcoin isn't affected by possible inflationary problems; because it is infinitely divisible. However, Bitcoin is an entirely new concept, or an experiment of a currency where there are no external mechanisms to regulate the economy. Whether this is feasible in the long term, remains to be seen.

Some currencies like Monero uses a tail emission system, with a constant inflation. This means the block rewards are constant after some point in time; perhaps more than sufficient to complement the lost coins and still provide incentives for the miner. As I've said, the stability of the network after the 2140 deadline (probably far earlier) remains to be seen. Economics theory holds only with ceteris paribus, but obviously that is never the case.

For all of you that thought Satoshi actually analysed the economic impact of that number:

I'd have to say the fault partially lies with Binance. IIRC, binance used to offer legacy address by default, and the user can choose to use bc1 if they want. Not sure if this changed, so do CMIIW. There are no incentives for the user to be changing to bech32 addresses; you don't get any discount by doing so and most of the people who uses binance don't realize the full benefits of using Segwit nor do they really care about doing so. It'll inevitably result in a far greater percentage of users using legacy instead of bc1. The easiest solution to this is just to make bech32 the default, giving people an option for either nested SW or legacy (probably nested SW would do).

There is still a number of users who uses Segwit: c68338dfc5ced3b876de31bacd3227404b88fb49f6a1fb020767f179c29ad946, for example but the ratio is far lower. Binance introduced Segwit really late as well, services like that are part of the problem, and they just won't change. Blockchain.info is another notable example.

Binance is not the worst offender by the way, Bitmex uses P2SH (with 3-of-4 MultiSig with uncompressed PKs). I don't think they have too significant of an impact, or at least I can't really tell without an extended observation. As with every exchange, if they aren't losing money, they're happy to just spend a little more to stick with whatever is working.

I'm almost certain they use Bech32 for deposits.
For Bitcoin withdrawal only.

Proof of some work. Assuming constant profit margin, miners will start purchasing even more ASICs to mine on other PoW chains and only shift the ASICs to your chain as and when it is required. The effective profits of the miners increases, without any actual decrease in the electrical consumption overall. In fact, the chain becomes less secure because the miners are only sacrificing a lower portion of opportunity costs by mining for only an hour on your chain. There is no way miners would ever just let their ASICs sit there.

Proving that you have the hashrate only at a period of time, ie start of the epoch isn't very helpful for PoW. Your security of the chain effectively comes from an hour of mining, and subjected to the interests of the miners as they don't stand anything to lose by supporting a rogue fork afterwards. As for the proof of hashrate, there isn't any mechanism or any that I can think of that can ensure that the miners do not find those hashes that you've mentioned before that hour. There has to be an included secret embedded in those hashes that is only revealed by the hour, which is quite difficult considering how nodes are independent and the lack of consensus on that would make this a difficult task.

Since your inclusion of your low difficulty hashes is in your proofblock, it'll be quite big and difficult to relay through the network. Ideally, the entire network should see each of the 'calculated hashes' to ensure that the proofblock miner isn't biased and specifically excluding certain data. The bandwidth requirement would be quite big in this case. Variance can also be a potential issue, where an hour isn't ideal to eliminate the possible variance from miners being able to find more hashes than others with less resources.


Margin of error is within 2 hours. The entire network has to decide whether to agree or disagree on a block. A slight deviation of the time on each of the nodes could potentially result in some accepting the blocks and some rejecting it.

Yeah I know. But OP didn't mention the file name and Electrum didn't exist in 2010 so I'm assuming that it can't be Electrum. Of course, you could've imported it there but then Electrum has always maintained backwards compatibility.

I agree, it might just be a fake wallet.dat or electrum.dat for that matter.

It was released in 2011, not 2013.

I'm almost certain that it is a wallet.dat. You have to import it into Bitcoin Core and see if it works. If there is any corruption, Core will attempt to salvage it. I believe Bitcoinqt was the only wallet at that point in time.