My plan had been to wait until 10 minutes before the deadline to make my prediction so I had as much information as possible about the next difficulty adjustment, however...

The internet tells me that current CEST (Central European Summer Time) is 11:30, but also it isn't summer in the northern hemisphere and so current Berlin time is 10:30.

What is this foul play!?

I don't trust PayPal in the slightest, so I would never suggest either buying from PayPal nor using PayPal to buy from a third party.

The best way to trade bitcoin is via a good decentralized exchange which has a built in trustless escrow such as Bisq, using a fiat method which is not easy for one party to reverse. No, such a platform did not exist at the time, but that doesn't mean that OP didn't mess up by accepting a raw private key and apparently at no point checking that it was actually valid or contained the coins he thought it did.

I'm not going to argue about it here since it is off topic, but you can do a web search for "paypal misinformation" or similar and see that everyone from lawyers to senators to the former president of PayPal agree with what is being said in that thread about this pro-censorship policy.

Youtube: Nadia Heninger - 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62

As outlined in the video, the string "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6" is common to the x coordinate of G*inv2 of all secp-k1 curves. I think it is very likely that 48ce563f89a0ed9414f5aa28ad0d96d6795f9c62 (with perhaps the first and last character (4 bits) changed) was/is generated by hashing some input, and then that was used as the basis for arriving at G.

It would be interesting to know what the original input to the hash function was, and the rationale behind the changed/added bits.

You cannot extract addresses or public keys from a password protected Electrum wallet without knowing the password. The entire wallet file and all the data it contains is encrypted, which you can see if you open the wallet file with a text editor. If the wallet did not have a password, then all the data is stored in plain text and this is easily possible, but that doesn't help you here.

This is not how btcrecover works. You should not be renaming Electrum files to .dat files. Simply make a copy of the Electrum wallet file and specify its location to btcrecover in the command line using --wallet PATH.

Bruteforcing from scratch with absolutely no knowledge of your password will almost certainly be unsuccessful unless you used a very weak password. You will need to have some idea of what the password could be to create a tokenfile for btcrecover to work from.

You can. Just use a single seed phrase, and generate three different master private keys at three different derivation paths, and use those to create a 2-of-3 multi-sig (for example).

This is partly how 2FA Electrum wallets work. When you set one up, you create a 2-of-3 wallet between yourself and TrustedCoin. Your wallet holds one key, and TrustedCoin holds another, allowing for 2FA spends. However, you can also restore this wallet and bypass the 2FA by entering a single seed phrase. This is because Electrum derives two sets of keys from this single phrase, one at m/0' and another at m/1', and imports them both in to your recovered wallet, allowing you to spend without the need for TrustedCoin's key.

I would note that doing this negates a large part of the benefit of a multi-sig wallet, in that the compromise of a single back up will compromise your entire wallet, rather than requiring the compromise of 2 or more back ups in a traditional multi-sig set up.

The easy solution here is that you include back ups of the other shares' master public keys alongside each of your seed phrase back ups. For example, on one piece of paper you would back up Seed Phrase A, xpub B, and xpub C.

A slightly more complicated (but better) solution is as follows. If an attacker was to find one of your back ups as above (containing 1 seed phrase and all other xpubs), although they could not steal your coins, they could recover your addresses and be able to see how many coins you are holding. To avoid this, you can create a back up system which does not store every xpub on every back up, but still means that any two back ups (in a 2-of-3 wallet) are enough to fully recover your wallet. Your three back ups would look like this:

1 - Seed A, xpub B
2 - Seed B, xpub C
3 - Seed C, xpub A

If an attacker finds one of your back ups, they can learn nothing about your wallet or your coins. Any two back ups gives you two seed phrases and the third xpub in order to restore your coins. The same system can be expanded to cover 3-of-5 or other multi-sig combinations, if you choose.

Once again, this is an internal accounting feature of Electrum only, and is completely irrelevant to the issue at hand. It does not matter at all if the address "expires". You will receive your bitcoin once the service sends them, regardless of whether your address has expired or not.

Think of it like adding some notes to a contact on your phone. It helps you keep track of some information (in this case, how soon you wanted the payment), but it makes no difference whatsoever to the other party calling you. The other party does not even know it exists.

When you open Electrum, you should see a green circle at the bottom right. This means it is connected and fulled synced with the network. If you see this green circle, then your wallet is fully up to date and if you don't see any coins it means they haven't been sent.

Correct. You can use the same address again, even if Electrum says it has expired.

You don't need to convince me that OP messed up here. Obviously he should have imported the key, checked it worked, and then moved any coins to a new address under a key he controls. But he didn't do that, so he is left with the situation he is in.

You can read the rest of the thread I linked for details. Anything that some unknown entity at PayPal deems as "false, inaccurate or misleading" is classed as a restricted activity and can be fined. Pure censorship.

On average, I don't think there has.

The difficulty is always the same (for this difficulty period). The difficulty does not change based on the previous block's hash. It does not matter if every miner is building on top of the same block (as usually happens), but it also does not matter if literally every miner in the world was trying to build on top of a block unique to them. The previous block hash makes absolutely no difference to the difficulty. It will (on average) require the exact same number of hashes and the exact same amount of energy to find the next block, regardless of the presence of a chain split.

Now when the next block is found, you could say that all the energy spent mining on top of the now stale block was not needed. But you could equally say that all the energy spent mining by the pools which did not find the next block was not needed.

If someone knows enough about your set up to make you a target for such an attack, can gain access to your airgapped computer, bypassing all physical and all electronic protections you have in place in order to install the necessary malware to start transmitting your private keys via modulating electrical signals in various internal components, as well as bugging your house with the necessary hardware in order to pick up and transmit those signals, then every single wallet you own is at risk (not to mention literally everything that you own). Such attacks are almost entirely theoretical.

I will never trust a software airgap (i.e. a phone with airplane mode turned on or WiFi turned off) as much as I will trust a hardware airgap (i.e. a computer with no WiFi card). It is almost trivial to open up a computer and remove the WiFi card, ethernet card, etc., while it is almost impossible to remove the antenna, WiFi, Bluetooth, NFC, RFID, etc. from your average smart phone without breaking it in the process. And how does the average person verify that airplane mode is doing what you want it to be doing. Even the NSA have admitted they can still track phones which are in airplane mode, so your phone must still be sending and receiving some data.

I have never known of a site to send money to another service first before sending it to you, but I suppose it could be possible. All seems very shady to me though.

Once the bitcoin is actually sent, it should show up (albeit as "unconfirmed") in your Electrum wallet instantly. You'll see it on the "History" tab.

It's completely irrelevant. The expiry is an internal function of Electrum to help you keep track of payment requests you have made. It makes absolutely no difference to you receiving payments and it does not matter if it expires. You can ignore it.

There is nothing else you can do at the moment except wait 5 days and see if they actually make the transaction or if they are scammers.

You can use any old computer as an airgapped device to either run a digital cold wallet, or to securely generate paper wallets. An old desktop or laptop works well. I always suggest opening up the device in question and physically removing any connectivity hardware, such as ethernet cards, WiFi cards, Bluetooth chips, etc. That way you can be certain you will never accidentally connect to a network and risk your data or your coins. Once you've done that, you should format the device and install a good open source Linux distro of your choosing.

Once you have a permanently airgapped device, then you can install software such as Bitcoin Core or Electrum to generate and run an airgapped wallet. You would create a complementary watch only wallet which contains only your public keys or addresses on your internet connected computer in order to watch your addresses for incoming transactions and so on. You can then use this watch only wallet to create unsigned transactions, move the unsigned transaction to your airgapped device via either QR codes or a USB drive to be signed, and then move the signed transactions back again to be broadcast to the network.

Alternatively, you can use your airgapped device to generate paper wallets. For paper wallets, I much prefer using a seed phrase to generate an entire wallet rather than a single key pair for a variety of reasons. It means I can have multiple addresses rather than just one, which is better for privacy. I can create my paper wallet by writing down a seed phrase accurately by hand. Writing down a key pair is prone to errors, and printing a key pair adds additional risk in that the printer may be WiFi capable or have internal storage and so on. Importing a seed phrase also avoids the risk of importing a private key to some software which will send your change to an address you do not have saved anywhere and will therefore be lost. To spend from the paper wallet it should only ever be imported back on to your airgapped device and spent from in the same way I described above for a digital cold wallet.

Yes, a ColdCard is an airgapped hardware wallet.

I would agree with this. Every time you have to go and get your paper wallet out of its secure storage location and import it in to a digital device in order to make a transaction from it, there are risks involved. The fewer times you do this, the less risk.

Waste from the point of view of a mining pool is very different to waste from the point of view of the network. I'm sure mining pools probably do see stale blocks as waste. Every hash which does not earn a mining pool money is waste, regardless if it is because of a stale block or just the 99.999...% of hashes which are unsuccessful. But those hashes are not wasted from the network's point of view.

And as garlonicon pointed out, this is different again when considering miners instead of mining pools, since miners earn money for unsuccessful hashes too.

The difficulty between both chains is the same, not different. And the combined hash rate across both chains for that difficulty will still mean the next block is found in 10 minutes (give or take the usual caveats).

tromp has put this very well I think. Despite the split at height H, all the hash rate on both sides of the split is working on the block at height H+1, just as it would be if there was no split.

In the situation you give in point 1), then yes, if a miner is attempting to mine on a chain which is not the main chain (as they would if they were not aware of the latest block), then that work is wasted. But in a chain split as being discussed here, we don't know which chain is the main chain yet, and so the work of both chains contributes to the security of the network.

It's worth pointing out that neither CZ nor Binance actually had to front any money to do so. The said we were hacked, but no one will lose any coins and we will reimburse everything, and that was it. Everyone still left their coins on Binance. Very few people actually withdrew their coins, and certainly not enough to test Binance's reserves. If Binance were running at a 10% fractional reserve, and were hacked and lost half of the reserve, but no one actually withdrew anything, then they can say what they like and business will continue uninterrupted. Perhaps during a previous hack Binance have been temporarily insolvent, but we never knew because people just blindly trusted them with their coins.

Sounds ridiculous, until you realize the exact same thing has happened to other exchanges, which have been insolvent for weeks or even months behind the scenes, all while continuing to operate, to advertise, to launch new services, and to promise that everything is just fine.

If it was hard to create your own wallet or key pairs from scratch, then it was probably even harder to find software which would let you import a raw private key to access coins you had supposedly bought.

I would suggest you just shouldn't use PayPal at all, since they introduced a clause in their Terms which allows them to fine you thousands of dollars if you say things online that they don't like.

A possibility, although a raw private key encoded in these systems would be 44 characters, rather than the 51 OP has.

That's not how seed phrases work. The process of using a seed phrase to generate key pairs is a one way process via various hash functions. You cannot start with a private key and derive a seed phrase which produces that private key, unless you are doing something very non-standard which I absolutely would not recommend.

I would say the main benefits of a hardware wallet over a paper wallet is that they are much easier to set up and configure for the average person, and they are also much easier to spend from in the future. Paper wallets are a poor choice for the majority of crypto users, as they do not have the ability to set them up in a safe and secure fashion without doing something wrong, relying on third party software, leaking information online, etc., and will also tend to import them in to a hot wallet when they want to spend from them. Paper wallets can be very safe, but only if you really know what you are doing with them. You should be using a permanently airgapped device (i.e. not just one which is temporarily offline) to create them, and they should only ever be imported back on to this permanently airgapped device to sign airgapped transaction when you want to spend from them. I would also suggest using verified and open source wallet software such as Bitcoin Core or Electrum to generate your entropy/key pairs/seed phrase.

Easily done with Electrum on Android.

Create a new wallet, give it the name you want, select "Standard wallet" and then "Use a master key". From there you can either paste in a master public key or scan a QR code of the master public key.

Alternatively, to watch individual addresses, create a new wallet and select "Import Bitcoin addresses or private keys". From here you can again paste in individual addresses or scan the QR codes of individual addresses.

On your desktop wallet, you can find the QR code for your master public key as OmegaStarScream has explained above, or you can right click on an individual address, click details, and then click on the QR button to get a QR code for that individual address.

This is true if it is external hash power coming from elsewhere and attempting to 51% attack the main chain, for example. But (and I could well be wrong) I don't think it is true if it is hash power which is already mining the main chain that temporarily breaks off to attempt to mine a fork before rejoining the main chain.

In my previous example where the hash rate splits evenly in two, then it doesn't matter that both halves are attempting to build on top of a different block. The total hash rate hasn't changed, and so the next block will still arrive in 10 minutes on average. If half of the network's work was truly wasted, then the next block would take 20 minutes to arrive. But because we haven't pre-determined which fork will win, then the work of both forks is contributing to the security of the network.

But it did provide security. If the work on the stale chain had found a successful hash first, then it would be the main chain. Just as if the work on any of the failed candidate blocks had found a successful hash first, then that candidate block would be on the main chain. If we look at a pool like BTC.com for example - they have an estimated 3% of the hashrate, but haven't found a block in almost 100 blocks. Does that mean all their work on their now invalid candidate blocks was wasted?

I think the confusion here is stemming from our frame of reference. If you look at the chain in retrospect, then all the work that didn't find a block can be called "wasted". But looking forward, all the work which attempts to find a block, regardless of whether or not that block is accepted, is contributing to the difficulty of finding a block and therefore the security of the network.

The transaction which paid 50 BTC to that address did not pay that address at all. Rather, it paid the public key associated with that address, as Charles-Tim has pointed out. Most wallets and block explorers will therefore not show the transaction or not show it correctly, although some do.

The private key 5KGLRScL6BqRkWnB8kTtoJmj21GT2W4KHpHJ2AA6vewuqM3tFVM gives the following uncompressed public key:

That uncompressed public key gives the address you have shared.

Let's look up the transaction which looks like it pays that address 50 BTC: https://mempool.space/tx/4ff149267a5b1e55e3d90a5a5b451dd6d3c2c82b26b96a599dda0ed5585f1f3d

If you click on "Details", you'll see that the locking script is simply OP_PUSHBYTES_65 PublicKey OP_CHECKSIG, and the transaction type is P2PK (pay to public key).

And so, because this is a P2PK transaction paying a public key, and not a P2PKH transaction paying an address, Electrum will not display it. It will however show up on some block explorers, for example here: https://blockchair.com/bitcoin/address/1NChfewU45oy7Dgn51HwkBFSixaTnyakfj

This is different, though.

Let's take fingerprints as an example. When you register your fingerprint with a device, the device is pinpointing various minutiae on your fingerprint, such as where a ridge ends, or where a ridge splits in to two, or joins another ridge, or a small ridge island, and so on. It creates a map of those minutiae points, and stores that in memory. When you scan a fingerprint in the future, it compares the minutiae points to the ones on file and decides whether they are similar enough. Their orientation and the distance between them won't be exactly the same, due to the rotation of your finger, or the angle of your finger, or how hard you press, or how cold/warm your skin is, etc., but if they are close enough then you will get a match.

Now consider trying to restore a private key from a fingerprint. The scan isn't exactly the same, because it never is, and so you generate a completely different private key. Perhaps it measured the distance between two minutiae points to be 49 microns, instead of 50. Or perhaps the angle between two points to be 24.4 degrees instead of 24.5. But with nothing to compare to, where do you go next? You have no way of knowing what part of the process is giving you a different reading, and even if you did, nothing you can realistically do to fix it. Do you just endlessly scan your finger over and over and over and hope that eventually you get an identical picture to the first time?

This would be true only if the block being built upon is invalid. That would indeed be wasted work, as it is impossible for that work to find the next block and therefore it isn't contributing to the security of the network. But the stale block from such a chain split is not invalid. It is perfectly valid, and could indeed have been the accepted block if a different miner had found the next block. All the work built on top of it is still contributing to the security of the network.

It might be wasted in the sense that it was later decided that this hash power was mining on top of a stale block, but it is not wasted in the sense that at the time it wasn't contributing to the security of the network.