Wallets do not assign recipient addresses for you.

You do not select a miner address to send a fee to. The fee in a bitcoin transaction is simply the difference between the inputs and the outputs. Any output address you see in a transaction is an address belonging to someone else, not to a miner.

It sounds like TheArchaeologist is correct here - your wallet has been compromised, your deposits are being stolen by a third party, and you are mistakenly believing that they are being sent to a miner to cover the fees.

If the wallet was generated from a seed phrase, then no, he wouldn't need to make a new back up. He would not be able to save any additional information to the wallet, such as invoices, address labels, or which UTXOs were frozen, but the wallet file contains the seed phrase and would still generate all the necessary addresses. If he uses the first 20 addresses, then Electrum will automatically scan beyond that up to the gap limit. Obviously if the wallet was made up from imported private keys, then he would have to make a new back up if he ever imported a new private key.

But regardless, they way to do this is either encrypt the entire USB stick or create an encrypted folder on the USB stick, and then add the back up to it. Once the stick/folder is decrypted, you can save to it freely before encrypting it again.

I don't use Google, but uBlock Origin blocks these ads. It is by far the best ad blocker out there.

PGP or GTFO.

Was the computer permanently airgapped when you did it? Did you delete the temporary files and over write the relevant sectors of your hard disk, or destroy the hard drive?

Why is it on your phone at all? Do you ever decrypt it on your phone? Can you vouch for every single app, download, piece of software, etc., on your phone that none of them have any malicious code in them whatsoever?

Maybe. But keeping a digital back up secure is exponentially harder than keeping a paper back up secure. The number of people who have thought their digital back was secure and ended up being compromised and having all their coins stolen is orders of magnitudes higher than people who have had a paper back up compromised and had all their coins stolen.

When there are two options of achieving the same outcome (backing up your seed phrase), why would you ever choose the riskier of the two?

I'll preface this reply by saying I am most definitely not a lawyer.

In my opinion, centralized services which hold on to users' coins on their behalf have got away with far too much scammy behavior for far too long. I include web wallets such as blockchain.com in this, but also most centralized exchanges. Sure, there are plenty of users of blockchain.com web wallet who only have themselves to blame, after not writing down their seed phrase or forgetting their account details, but the number of users reporting issues where they have had coins or entire addresses disappear from their wallet, seed phrases recovering an entirely different set of addresses, transaction being sent to addresses which no longer exist, etc., are too many to ignore. Add in the fact we know that they have previously had critical vulnerabilities go unnoticed in their system as I explained above, and coupled with the fact the blockchain.com's customer support is legendarily useless and provides absolutely zero support to these users, often leading to people like us on forums such as this one trying to help these users recover their coins, then I would love to see these cowboys actually be held responsible for some of their behavior.

But not impossible. Bitcoin which have simply not moved in a long time are not provably lost. The difference in your analogy is these bitcoin are already accounted for in the max supply. Capturing an asteroid filled with gold will inflate the supply of gold significantly.

No, all others cannot.

The block rewards from block 91,722 and 91,812 were overwritten by the block rewards from blocks 91,880 and 91,842 respectively, due to a bug which was fixed in BIP 30. Those 100 BTC are irretrievable.

There have been numerous blocks which have failed to claim the full block reward they were allowed to. These unclaimed coins are also irretrievable. Notable examples include block 501,726 which destroyed 12.5 BTC and block 526,591 which destroyed 6.25 BTC, but there are hundreds of other blocks totaling several dozen more permanently lost BTC.

By my calculations, you were still off by around nine hundred and ninety nine million nanoseconds. It only looks good because of rounding errors.

And yet, we cannot for a minute say that the other 50 BTC outputs which haven't been moved since they were mined are lost, since we have absolutely no evidence to support that claim.

That was the main one I was referring to, yes.

It is less than that for a number of reasons. There are coins which have been provably burnt due to sending to unspendable outputs. There have been times miners have not claimed the full block reward, and those coins will be lost forever. There have also been a couple of bugs which have resulted in coins being lost forever. The total number of coins provably lost isn't huge, somewhere in the range of a few thousand. But just because a coin has not been moved in a long time does not mean it lost, and certainly not provably lost.

But we have absolutely no way to quantify the number of coins lost in this way, nor do we have any way to confirm that the owner really has lost access like they say they have, nor do we have any way to confirm that access will not be recovered in the future. Therefore, those coins can and should be considered part of the supply.

That could happen at any time that Satoshi or some other early miner with a large stack of dormant coins decides they wants to spend their coins. Assuming that coins which have not moved in 5 or 10 years are permanently lost is incorrect, as we regularly see coins like this move, or occasionally even sign messages.

It will be decades before we have a quantum computer powerful enough to reverse the ECDLP. It will be significantly longer than that until we have one which can solve it in <1 hour, or even <10 minutes. I suspect we will move to a quantum resistant algorithm before the former of those two events happen, which will be long before the latter is even within the realms of possibilities.

You cannot obtain a public key from knowledge of just the address. Further, quantum computers do not provide a significant advantage over conventional computers when trying to reverse a hash, and so even with quantum computers it will still remain impossible to obtain a public key from an address.

However, whenever you make a transaction in bitcoin, you must include the public key of whichever address the coins you are spending are stored on. This public key is then stored as part of your transaction data on the blockchain, and therefore is public knowledge which anyone can look up. Quantum computers provide an exponential speed up over conventional computers when attempting to reverse the ECDLP, which would potentially allow an attacker in the future to obtain a private key from knowledge of the public key.

If you never reuse an address, then this will not be a concern of yours ever. If you do reuse addresses, then you need to think about stopping doing that in maybe 20 years' time.

An uncompressed bitcoin public key is 65 bytes long, made up of "04", followed by the 32 byte x coordinate and then the 32 byte y coordinate.
A compressed public key is 33 bytes long, made up of either "02" or "03" depending on if the y coordinate is positive or negative, and then the 32 byte x coordinate.

An address is not simply a public key in Base58Check. To convert a public key to an address, you must first SHA-256 hash it, then RIPEMD-160 hash it, then add a 0x00 network byte to the start, SHA-256 hash it twice, take the first four bytes of this hash as a checksum and append it to the end, and then convert the whole thing to Base58Check. If you want to work backwards from an address, you can only strip the checksum and network byte to arrive at the RIPEMD-160 hash output. You can't go back any further to find the public key.

Have you personally reviewed the code of 7zip to ensure there are no flaws in its encryption algorithms?
Did you take steps to mitigate against known vulnerabilities such as this one: https://twitter.com/3lbios/status/1087848040583626753?
Did you make sure to build the app yourself from the source code you reviewed to ensure you haven't downloaded a fake or malicious one?
Did you make sure to delete all the temporary files it creates in the archiving process, and then write over those sections of your phone's memory with junk data?
Did you make sure to delete the unencrypted text file you would have first loaded on to your phone before encrypting it, and then write over that section of your phone's memory with junk data?
Do you never unencrypt it unless your phone is offline, and then again delete and over write the temporary files it creates?

There is a reason that everyone tells you to write down your seed phrase on paper and keep it offline.

Most likely. Another possibility is that he pulled a random address from his blockchain.com wallet for the transfer he is talking about and not one of his brainwallet imported addresses, and has since lost access to the blockchain.com wallet.

The largest transaction ever made was for 550,000 BTC in 2011: https://blockchair.com/bitcoin/transaction/29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf
The largest transaction around July 30th, 2015 (depending on your timezone) was for 8,999 BTC: https://blockchair.com/bitcoin/transaction/6fc2e2faa284f4d145e9a0c7d07166d17fa575dfd5d9206a82013d97d1dd5819
And the largest around July 30th, 2016 was for 29,900 BTC: https://blockchair.com/bitcoin/transaction/a5272593ea3c9f7a6bd03eb61857f4e3f787a49b80bf4824cdc6132ea1467c89

You seem to be very confused. Are you sure you are even talking about bitcoin here and not some altcoin?

That's correct. I know this command works in the GUI console - I've not tested it personally in python (and I'm not at a machine in which I could test it personally for the time being), but I see no reason it wouldn't behave in the same way.

I'm not 100% sure about this, but try the following:

So you have a private key which recovers an address, which is the same address you generated from it in the past. That all seems fine.

However, in your first post you give three different addresses. You also think you received a transaction to another address. Where did these addresses come from? Were they somehow derived from the same private key too? Or did you create more than one private key? Alternatively, did they come from your blockchain.com wallet?

This should do what you are looking for. You can prefix your private key with the usual Electrum prefixes (p2pkh:, p2wpkh-p2sh:, p2wpkh:) to generate a specific address type if needed. Private keys should be in WIF.

I agree with Loyce - it is not clear what you think is going on.

The address you gave above has made exactly two transactions. In both cases, the full balance of that address was sent to one other address, and you paid a higher fee than needed. Do you mean the balance of that address is emptied as a fee? Or is being sent to the wrong address entirely? Or do you mean funds from another address in your wallet are also being moved at the the same time?

I have used Schildbach wallet many times and have never experienced something similar to what you are describing.

Is this not exactly what happens with people holding tokenized bitcoin, wrapped bitcoin, bitcoin on Ethereum, on Tron, on Binance Chain, or any of the other "not actually bitcoin" bitcoin tokens? Someone, often anonymous, promises to pay you real bitcoin in return for your fake bitcoin.

If you actually hold the bitcoin yourself, sure, but if it is tied up in layers of DeFi nonsense or something similar, wrapped up in altcoins, stuck in smart contracts, held by third parties, etc., then all that goes out the window. As I said above, the only way to avoid fractional reserve altogether would be for everyone to hold their own coins, but we both know that's never going to happen.

How can this possibly be enforced though?

We can encourage decentralized platforms and "Not your keys, not your coins" as much as a we want. But even after all the centralized exchange hacks, leaks, losses, scams, privacy invasion, KYC requirements, spying, surveillance, fractional reserve, accounts being locked, transactions being frozen, coins being seized and on and on, the number of people using such centralized services continues to grow. There will always be people who don't care about the decentralized nature of bitcoin and are just here to try to make profit, and will use any centralized platform which promises them unsustainable growth or returns. And there will always be people who despite the tens of thousands of users who have lost funds because of centralized platforms, will continue to use them to store their coins.

The only possible way to stop people using centralized platforms altogether would be to outright ban them, and regardless of whether or not you think such an outcome would be a good thing, we absolutely shouldn't be looking for more government regulation or laws regarding the bitcoin ecosystem.

Without sharing the actual private key, can you explain what it looks like? Does it have 51 characters and start with a 5? Does it have 52 characters and start with a K or a L? Does it have 64 characters using 0-9 and A-F? Is it something else entirely?

When you tried to import it in to blockchain.com, did it show you the same address as the one you had saved? If it was a different address, which character did it start with?

Have you tried importing the private key in a proper wallet like Electrum (make sure you verify it first) and generating all three address types?