You need to trade at bigger spreads. A spread between your buy and sell price of only 0.1-0.2% will almost always be entirely negated by fees.

Upping your investment 10 or even 100 times isn't going to make any difference to trades like that. You need a 30 day trading volume above $50,000 before the percentage fee you pay on Kraken starts to fall. You can see this here: https://www.kraken.com/features/fee-schedule. So even if you had traded 1 BTC at those prices, you would still only have 1 BTC.

The price definitely does not only fluctuate by small amounts. In the last 24 hours alone there has been a fluctuation of over $400, with regular swings of $50-$100. These are the numbers you need to target, not swings of 10 bucks.

This is essentially correct. The passphrase is intrinsically linked to the addresses you generate, just the same as your seed phrase. You need both to recover the coins in the passphrased wallet. If you lose either the seed phrase or the passphrase, you cannot recover the passphrased wallet.

The PIN is entirely stored on the Ledger and is device specific. The PIN is not used to generate your wallets, only to unlock your Ledger device. If you recover the wallets to a different Ledger device, you do not need to enter your previous PINs, and when you set up new PINs you can either pick the same ones as before or totally different ones.

Steal his coins.

All Trezor devices have an unfixable hardware vulnerability which allows an attacker with physical access to the device to extract the seed phrase in a matter of minutes. It cannot be patched. The only way to mitigate the attack is to use a long and complex passphrase, so when the attacker does gain access to the seed phrase, they still have to bruteforce the passphrase before being able to steal the coins.

See here for more information: https://donjon.ledger.com/Unfixable-Key-Extraction-Attack-on-Trezor
And see here for details on how to use a passphrase, which every Trezor owner should be doing: https://wiki.trezor.io/Passphrase

Genuine question: Does this matter if I make a donation, though? Let's say I deposit exactly 0.128 BTC. I then decide to donate 0.002 BTC and withdraw a 0.064, a 0.032, a 0.016, a 0.08, a 0.04, and a 0.02 chip in a couple of different transactions over the space of a few days. Does it make any difference to my privacy that I've deposited 0.128 BTC as opposed to 0.12745902 BTC?

I'd be quite happy if they didn't. The less they reveal about the amount of money they handle and the amount of profit they take, then the better the privacy for all their users.

This. It would be like putting a bunch of cash in a safe without first checking that the key works, only the safe is completely indestructible.

There is little inherent difference between using a website which you have downloaded and ran offline and using a piece of software which you have downloaded and ran offline. Both are equally capable of being filled with bugs which generate incorrect addresses, and both are equally capable of returning fake or pre-generated addresses to which an attacker has access to the private key.

I think you may have downloaded a fake copy of bitaddress. Can you check the addresses you funded on a block explorer? Are the coins still there, or have they been moved?

Try opening the offline version of bitaddress you have downloaded and paste in one of your private keys. Make note of the compressed and uncompressed addresses. Do they match the addresses you have funded?

Now go to the bitaddress github (https://github.com/pointbiz/bitaddress.org), download, and run offline. Paste in the private key. Do the addresses generated match the ones you just generated in the previous step?

You cannot check individual private keys with iancoleman. OP can either use bitaddress.org, click on "Wallet Details", and paste the private key in there, or could use https://brainwalletx.github.io/, click on "Private Key", then "Toggle Key", and paste the private key in there. Since bitaddress only generates legacy addresses, then either should work. Note that of course you should never paste a private key in to a live website, as you are highly likely to have your coins stolen. If using either of these sites, make sure you download them from the GitHub and run in an airgapped environment.

I tried simply saving the bitaddress.org page, and it still generated keys correctly for me. The most likely culprit here is OP's wallet is generating a P2SH or P2WPKH address instead of a P2PKH, or he has used the wrong one of the compressed/uncompressed key.

No it doesn't. The whole point of hardware wallets is that you can connect them to any computer or device, even one filled with malware, and your seed phrase/private keys/coins remain completely safe. It is entirely possible to use a trusted friend's or family member's computer to use an exchange account and deposit coins to it from your hardware wallet. The main risk is with there being malware which could steal your exchange account login details, not which could access your seed phrase.

Even if you have no idea what it is, every Trezor device has the word Trezor embossed on it. Type Trezor in to Google and the first result will tell you what it is.

I'm not so sure. Bitcoin adoption is a direct threat to PayPal. Online stores accepting bitcoin allows them to accept payments more cheaply and with less risk than PayPal. If bitcoin becomes widespread, it will take away a good chunk of PayPal's business. Given that, I don't think PayPal are going to want to aid that until it is already inevitable. Doing what they are doing at the moment is an easy way for them to take some profit via trading fees without actually allowing people to spend or use bitcoin and affecting their own share of the market. Only if bitcoin is already eating away at their market is there any real incentive for them to start supporting sending and receiving.

No. If the average block time for the last 2016 blocks was 9 minutes, then the difficulty will readjust so as to try to make the average block time for the next 2016 blocks be 10 minutes. It does not try to over compensate for previous blocks being quicker by making subsequent ones slower. It is targeting an average of 10 minutes for those specific 2016 blocks, not an average of 10 minutes for the entire blockchain.

Difficulty doesn't only increase. It can and does decrease as well, for example immediately after the halving.

From the comments above, it seems like they won't even do that. If you want to spend your bitcoin tracker which PayPal is holding for you, you'll have to manually sell it yourself back in to fiat and then spend the fiat.

Impossible to know either way, and actually, it probably doesn't matter. Regardless of whether they do or do not buy the relevant amount of bitcoin, it will never be yours, you will never own it, you cannot withdraw or spend it, and you are at the complete mercy of PayPal allowing you to access it and not freezing your account for any reason.

What bug is this?

The only bug I am aware of skews things in the other direction. Although the retargetting period is every 2016 blocks, it only considers the time taken to mine the previous 2015 blocks, which would result in an average block time of 2 weeks/2015 = 600.3 seconds.

We don't really though. All PayPal are actually offering here is exposure to the bitcoin price through their platform. They are not implementing bitcoin support in any meaningful way. As TryNinja says, I can neither deposit nor withdraw bitcoin to or from PayPal. And so, if I did want to use my bitcoin to pay for stuff online, I can't just send it to my PayPal account (not least because I don't have one, ha) and spend it from there. The only bitcoin I can effectively spend via PayPal are bitcoin which I have bought via PayPal.

This may change over time, and PayPal may implement the ability to send and receive bitcoin, but for the time being all you can essentially buy and sell via PayPal is a bitcoin price tracker, not bitcoin itself.

OP was fortunate in this case that the attacker did not know what he was looking at. There exists a vulnerability with Trezor devices in which a knowledgeable attacker, given physical access to the device, can extract the seed phrase within 15 minutes. The attacker could have extracted the seed phrase and left the device behind to make OP think he is safe, and then moved all the coins a little later.

There is also the possibility that an attacker sees a hardware device, knows what it is, and so comes back at a later time when OP is around in an attempt to coerce him to give up his coins. If you aren't already using passphrases to give yourself plausible deniability for such a scenario, then you should consider doing so. Links below.

https://wiki.trezor.io/Passphrase
https://support.ledger.com/hc/en-us/articles/115005214529-Advanced-passphrase-security

Not enough people use it, in my opinion. It's a powerful tool which can increase your security (in that if your seed phrase is compromised you don't immediately lose all your coins, and it is the only real way to have plausible deniability with a hardware wallet), and it can also improve your privacy (by allowing you to create entirely separate wallets for different purposes and therefore avoid the risk of mixing UTXOs together and linking different addresses/bitcoin). Using passphrases can also help to protect against some vulnerabilities, such as the recently disclosed one regarding sending bitcoin transactions when interacting with an altcoin wallet on Ledger devices (now patched). If the altcoin wallet was behind its own passphrase, then the vulnerability was impossible to exploit.

So yes, not only do I use passphrases, but I use multiple different passphrases to create multiple different wallets from the same seed phrase.

Practically speaking, this is largely correct, but I can think of a few hypothetical scenarios which would bring the next halving significantly closer.

As odolvlobo points out, since hash rate can increase in real time, but the target can only decrease every 2016 blocks, then if hash rate continues to increase then blocks will be mined quicker than every 10 minutes on average.

More broadly, the target can only adjust by a factor of 4 at any given retargetting, and so if the hash rate started increasing exponentially then the target could not keep up and the halving would come much sooner. The only ways I could see this happening is if a vulnerability was discovered in the hashing process (unlikely), or there was some massive breakthrough in ASIC design.

The email certainly looks legit. The links contained also look legit, but make sure they don't actually direct you to other URLs and that there are no holograph attacks.

BittrexGlobal is an official branch of Bittrex, and the Twitter account of the same name is also an official one.

To me, this seems like a genuine request for information. If, as you say, your account has been disabled in the meantime, then it has almost certainly come from Bittrex and not spam or a hack.

If you are in any doubt, then contact them directly to confirm.

So lets say some criminals do manage to break in a bank vault in which you own a safety deposit box, and do break in to your safety deposit box which contains half your seed. A very unlikely scenario to start with, but not impossible. How long is it going to take for you to be notified of this? It will be all over the news and the bank is going to be pretty quick to contact the affected customers. You will presumably immediately move all your funds to a new address when you do find out.

So, the criminals have a very limited window in which to break in to another bank (which just so happens to be the correct bank), break in to the safety deposit boxes (and just so happen to find your one), and combine your seed phrase, all while being actively hunted by the police and while bank security has probably been ramped up following the first attack.

How likely do you think such an attack is? As HCP says, you are going down an endless rabbit hole of "What if?" scenarios.

Once someone has downloaded your encrypted database to their own local machine, then can attempt to bruteforce it at a rate of potentially millions of possible passwords per second. It's only going to be hard if your password is long and random.

No. I store absolutely zero sensitive information on the cloud or email servers, even in encrypted formats. There are far too many unknown variables as I mentioned above, and you are placing complete trust in the third party provider.

I've asked this a couple of times over the years in threads regarding EHRs and blockchain, and I've never been able to get a good answer:

EHRs are massive. Patients generate massive amount of data. Not just text entries from every doctor or other health professional they come in to contact with, but details about visits, insurance, prescriptions, test results, referrals, communications, etc. and crucially, scans - US, CT, MRI, PET, etc. Scans in particular take up massive amounts of data. The average patient will generate around 80 MB of data per year. Even a small hospital which serves a population of only 50,000 is going to generate on average 4 terabytes of data in a single year. Try scaling that up to a large hospital with several million patients and the numbers become ridiculous. How is that supposed to be stored on a blockchain?

The only potential solution I can see is to store it all on a centralized database as it currently is, and use blockchain to manage access policies to this centralized database. Sure, this is possible, but it is also completely pointless and holds no benefit over the current system.

This is a meaningless question. It's like asking if anyone has driven without a seatbelt but is still alive to tell the tale. Just because an individual's method has not been compromised yet does not make it a safe method.

There are 100 possible things that could go wrong with that method, from accounts being hacked, passwords being bruteforced, employees of the cloud hosting company accessing files, uploads being intercepted, vulnerabilities in the storage, vulnerabilities in the encryption, seed phrase being leaked before being encrypted, the list goes on. None of these vulnerabilities are even possible with a seed phrase being written down on paper.