No idea I'm afraid - I've never used it on Android. I get the same 403 error on both Tor and Firefox trying those links though.

I would suggest using Tor or Firefox if you can to avoid all things Chromium altogether. Otherwise, Bromite is a Chromium based android browser which gets decent reviews, although I've never used it myself. If your main goal is to receive Google search results with improved privacy then you can use Startpage as your search engine via any web browser. It searches Google on your behalf and returns identical results but without the privacy invasion.

Disagree. By far the most likely way that these coins will be recovered is simply by the owner realizing their paper wallet is missing and accessing a different back up to move the coins. If you move them to a new address, then you completely prevent this from happening.

If you want to move the coins so the owner notices something is wrong, then sending them back to the same address is the best option. Add in an OP_RETURN output as mentioned above if you feel life it.

If easternklaas is unsure about how to do that, then he can simply share the address here and someone else can create the necessary transaction (send all coins back to the same address and add an OP_RETURN output which directs to this thread) which would just require him to sign and broadcast.

In terms of reversing already confirmed transactions, then there's the 51% attack which you've already discussed and there's the possibility of taking advantage of a natural chain split/stale block as I've discussed. There's also the possibility of an attacker with a significant minority of the hashrate getting lucky and being able to mine a longer chain in secret and therefore overturn one or more confirmations. This is essentially a 51% attack but without the 100% guarantee that it could be achieved. There is also a theoretical attack named after user vector76 which essentially creates and takes advantage of a chain split. Note that an attacker must sacrifice a block reward to pull off this attack.

As far as I am aware, a 51% (or even minority alternative chain) attack has never happened, and a chain split has only ever resulted in very rare cases of a transaction with 1 confirmation being double spent. I am unaware of any transaction with 2 or more confirmations ever being double spent in such scenarios.

A 51% attack would cost hundreds of millions of dollars. Taking advantage of a natural chain split could cost nothing, but would require a tremendous amount of luck.

Since you are so concerned about this, then the best thing to do is simply wait for 3 or more confirmations.

I should have been more clear.: When I use the word airgapped, without exception I mean permanently airgapped. A computer without an internet connection temporarily is not airgapped.

I wouldn't make a digital copy. I'd simply copy the private key to a second piece of paper in case something happens to the original.

In that case, I would do nothing. As suchmoon says, the real owner might try to move the coins at any point between now and decades in to the future. You cannot assume the coins are lost just because that paper wallet goes unclaimed.

Looks like he already tried this, unlocking the hardware wallet with the "correct" passphrase and using that to create a brand new Electrum wallet: https://nitter.it/TheVladCostea/status/1553245488748630016#m. As expected, it showed zero balance.

Again, this is all in keeping with him using the wrong BIP39 passphrase. Unlocking the wallet with what he thinks is the right passphrase but isn't will result in an error trying to decrypt the existing Electrum wallet file (which he experienced from his first post), and will result in any new Electrum wallet file generating different addresses with zero balance (which is what he has done here).

He has simply forgotten his passphrase or is is making a mistake when entering it (wrong case, forgetting a symbol, something like that). He probably needs to look in to brute forcing it with btcrecover.

That's not quite right either. The median of the timestamps from all your peers is used to adjust your local time. Here's the code:


Not necessarily, because block timestamps do not need to be in order and can vary within the limits I gave above. The 6th last block might have a timestamp later than the 5th last block, meaning the 5th last block would be the median (if all the other block timestamps were in order).

That's not quite right. A block's timestamp has to fall within a range bounded by the median timestamp of the last 11 blocks (plus one second) in the past, to up to 2 hours in the future based on adjusted network time. If the future limit was median time of the last 11 blocks plus 2 hours, as you stated, then we would frequently run in to the problem of miners having fake timestamps, since on average any time it took more than an hour to find a block we would be outside of that window. Because the future limit is based only on the current time, we will never be in a situation where miners have to "back date" their blocks to ensure they are valid.

It would drop to 25%. It would drop by 75%.

I wouldn't. In doing so you remove the ability of the real owner of the funds to move the funds themselves once they realize what has happened, assuming of course they have another back up of their wallet somewhere they can access. Given that this is probably going to be the most likely scenario in which the real owner is reunited with their money, then by sweeping the coins you make it significantly less likely they will ever get them back.

For starters, I would stop saying any more about what the wallet looks like, where you found it, how it was protected, etc. If the real owner finds this thread, then you need some way of confirming it is them, and that will probably be done by them describing in detail what the wallet looked like and the circumstances in which it was found. If you give away all the details, then it becomes too easy for someone to fake that information.

Secondly, I would verify the private key does indeed lead to the address on the wallet. I would do this on an airgapped computer as mentioned above by Loyce. I would never enter the private key on an internet connected computer due to the risk of theft.

Thirdly, I would make up a back up of the wallet. If it is already damaged as you say, then I wouldn't want to risk being responsible for damaging it further beyond recovery, especially if it is the only way for someone to access their life savings.

Fourthly, I would poke around in the history of the transaction which funded the wallet to see if I could find anything useful which might link the wallet to a person or centralized exchange.

Lastly, I would post the public address here to increase the chance of the owner finding it.

I don't use public Electrum servers and route all Electrum traffic through my own server, so my knowledge of the public server architecture is probably not complete. My understanding, however, is that Electrum will connect to around 8-10 servers in order to download block headers from them all (in order to avoid a single server returning incorrect or malicious data), but only one of these servers will be used to query the addresses within the wallet and to relay transactions. All 10 servers will be able to see your IP address, but the one main server will also be able to see everything you are querying.

Tor can actually make things more risky. Some of the guides for using Tor with Electrum set it up in such a way that you are only connecting to a single server in order to maximize privacy. This obviously means you are downloading the block headers and all your wallet information from only a single source, which increases the risks of being fed incorrect or malicious information.

The most recent case I can find was at block 733,430. A block at this height contained the transaction dd0ada46f59ee9ac962fae10e2e3d63b8898953b4730c74851f344041988aa54. A different block at the same height contained the conflicting transaction 84ce52b6bde454a4b23f2c1cc9e6e67f0c8a28b91e4e170a717d1581d5d556fc. The second block was built upon first, meaning the first transaction was invalidated and no longer exists. Any node which was looking at the first block would have seen the transaction dd0ada46f59ee9ac962fae10e2e3d63b8898953b4730c74851f344041988aa54 go from 1 confirmation to being rejected as invalid.

The block was over 3 months ago, so this is not exactly a common occurrence. I am not aware of any transactions which were reversed after 2 confirmations outside of serious bugs as mentioned by nc50lc above.

Data brokers will pay for all kinds of data. Far more likely though is that these blockchain analysis firms are just running a bunch of their own servers anyway, since the overhead for doing so is tiny and they can collect huge amounts of data through them.

All this achieves is masking your IP address. The server can still link together all your addresses and all your transactions (and potentially even multiple wallets if you open them in close succession over the same Tor circuit). Far better to just run your own server.

I already said all this above:

---

The only one of those five options I would ever use is number 2 - flipping a fair coin 256 times. You should either run statistical tests to ensure your coin is fair first, or you should use something like Von Neumann's debiasing algorithm to remove any bias in the coin.

For 1 and 3 - When you roll dice, the chance for bias is much larger, and the methods for reliably detecting that bias are much more complicated and take much longer. You also have the problem of extracting the necessary randomness from your list of dice rolls, as nullius alluded to above, which is neither a trivial nor a straightforward process and not something that you should just "have a go at" or feed your list of rolls in to SHA256 and assume the output is adequate.

For 4 - If you don't trust an auditable and verifiable open source wallet which is generating your entropy in a cryptographically secure way by using /dev/urandom, then why would you trust a password manager to do any better?

For 5 - Same randomness extraction risk as 1 and 3, with the added flaw being you are starting with entirely non-random data in the form of an image.

I also note you mentioned using Ian Coleman's site to turn entropy in to private keys. I hope you are doing this on a permanently airgapped computer!

franky1 summed it up nicely. McCormack is guilty of saying things which hurt CSW's feelings, so technically CSW won on that count. But since CSW is absolutely full of shit, the judge essentially told him to get lost, and awarded him the minimum possible amount in damages.

I also note this tweet from McCormack:
I wonder what else is still going on. I'm not a lawyer, and certainly no expert on UK law, but I hope it is one of two things: The Judge deciding that CSW should pay McCormack's legal costs for wasting his time and money with what has already been established to be outright lies, or McCormack counter-suing CSW for lying to the court.

A huge delay.

Keeping the average block time close to 10 minutes when the hashrate is constantly changing is done so by changing the target number. The miners must find a solution which is below the current target. The target is recalculated every 2016 blocks, and so the target we are working to at the moment is based on the current hashrate of approximately 200 EH/s.

So, if we suddenly lose 99% of the hashrate, for example, then the 1% which remains will be stuck with the current target until the next recalculation, which will be at most 2016 blocks away. Since the target will be based on 200 EH/s, and we would only be mining with 2 EH/s, then blocks will take significantly longer. Once we do recalculate, then the target would drop by a factor of four (which is the limit of how much the target can change at once), meaning the next 2016 blocks would be faster, but still nowhere near a 10 minute average. This would repeat until things balanced out again.

In your example of leaving only a single CPU miner running, then the discrepancy between hashrate and target would be so ridiculously large that either nothing would happen until other miners came back online, or bitcoin would need to fork to readjust the target or mining algorithm.

Not about COPA, but known scammer CSW doesn't deserve another thread about him, so I'll just add this in here.

Here is the ruling for the case between Peter McCormack and CSW: https://www.judiciary.uk/wp-content/uploads/2022/08/Wright-v-McCormack-Judgment.pdf
The case is CSW suing McCormarck for libel after McCormack repeatedly tweeted that CSW is not Satoshi. (Because we all know that suing people who say things you don't like is exactly the kind of thing we would expect the real Satoshi to do ).

Turns out CSW lies. Like, a lot.

I'll stop quoting at that point because it goes on and on for several more pages documenting all his lies. The judge summarizes with these two paragraphs though:

So another waste of everybody's time and money to reach the conclusion that we've all known for years: CSW is full of shit.

Sorry, my math was wrong - used 1 instead of 100 as the numerator. Fixed the posted above.

The miner in question had a 1 in 25,000,000 chance of solving a block. So given 144 blocks a day and assuming a constant hashrate, he would have to mine for 476 years on average to find a block. Turns out he just got super lucky.

He had 9 of the devices running at once, along with additional hardware to power them and cool them, so his set up was probably at least ~$5,000, rather than $300. Further, you have to add in electricity costs, as well as the fact that the devices do not have an indefinite life expectancy and would need replacing. And of course he could have ran this whole thing for decades and not mined a block and therefore not earned a single satoshi.

As I mentioned above, solo mining is playing the lottery. A couple of individuals will spend a small amount of money and win big, but everyone else will collectively spend a lot of money and win nothing.

Oh good. Another wallet using a non-standard derivation path, but it won't tell you what it is. I look forward to future posts on this forum of people with seed phrases generated by this wallet who are recovering empty wallets and cannot find their coins. And no option to pay using bitcoin. Nothing says "pioneer of ... the digital economy" quite like not actually accepting any digital currencies.

Or not even knowing how they are spelt.

This screams of Verizon trying to make some easy money. At $200 it's way overpriced as well.

Essentially, yes. In the same way that there are many different private keys which will all lead to the same address and therefore be able to spend the same bitcoin, there are many different inputs to SHA256 which will all give the same output. However, the chances of ever finding such a collision are so small as to be negligible to the average user. It is exponentially more likely that someone would guess all your credit card information by just punching in random numbers than they would find a collision with one of your private keys.

Quantum computers are not some magical device that can solve any and every problem. Quantum computers will be relatively ineffective against hash functions, and it is highly unlikely anyone would use them to try to find a hash collision in order to steal someone's bitcoins. Rather, their main threat against bitcoin would be solving the ECDLP, which would allow the reversal of a known public key in to its paired private key.

Your own hardware. That's it. That's the only place you can ever be sure that your account won't be inactivated or your data won't be deleted without your consent. Any online service, be it free or paid, be it some tiny provider no one has heard of or some global giant like Google or Amazon, be it cloud storage or an email account, can close your account or lose or delete your data at any time for any reason and without warning, not to mention the massive risk of theft or hacks you take by using any online storage.

It seems that no matter how many times you are told this you are absolutely dead set on risking everything by storing your seed phrase or other sensitive data on the cloud. Why?

Slight pet peeve, but I think it's better not to use the word passphrase when discussing the hardware wallet's local unlock mechanism, and keep the word passphrase for reference to the seed phrase extension. Some of the issues that newbies have similar to this one is because they don't understand what a seed phrase passphrase is or does and confuse it with a PIN/password for unlocking their device.

It isn't a recipe for destruction at all. As you point out, the Electrum wallet is simply a watch only wallet. It is encrypted with the hardware wallet only for privacy reasons and to stop other people viewing your addresses, not for any security purposes and not because it contains any critical information. Even if you completely lose the Electrum wallet file, then you can just create a new one with the same addresses by using the same hardware wallet with the same passphrase enabled.