That is not the definition of clean coins. Clean coins or otherwise known as untainted coins are those which were never associated with any illicit activities via transaction linkage or has went to specific addresses. The level of taint on a specific UTXO doesn't necessarily concern the user's privacy nor is that of any concerns here. CoinJoins are the opposite of taint; due to the nature of the transactions, you're more likely to have tainted coins after using CoinJoin.

Coins directly from the block rewards are clean as they've never been associated with anything else. I wouldn't be surprised if some miners starts to use the fees as a way to clean their Bitcoin but taint is really not that much of a concern.

In the long run, both mining in a pool and solo mine will have the same expected revenue, minus the fees However, there is no point doing solo mining unless you're doing lottery mining (mining with the hopes that you would hit a block without expending too much on the cost of running it) or if you're able to withstand the long periods of going without any revenue if your mining farm is very small. Generally, the difference between the two of them is just the ~1-2% additional cost with a pool but with the added benefit of not hassling with setting up and maintaining your own server and improving your payout frequency.

No. There is no difference between a change of that transaction and of a regular transaction. Both of them will be linked or tainted to the inputs used in that transaction. Taint is mostly determined by linking the UTXO through the chain of transaction. Since your change is still linked to your inputs, there will be no difference no matter who you send your Bitcoins too.

The only way to reduce the taint is to say, if you send Bitcoins to a miner and the miner sends one of their UTXO from the block rewards to you in a separate transaction. The coins that you receive would be considered clean.

It shouldn't be blank. It contains the names of the wallet files that you've opened and tells Bitcoin Core to open it on start up.

Try moving the settings.json to another directory or renaming it and launch Bitcoin Core again. It should launch just fine.

Here: https://btc.com/stats/diff.

The difficulty is always dependent on the time between the blocks and that is affected by the hashrate. The hashrate is in turn affected by a ton of factors; Bitcoin Price, Natural Disasters, Government regulations, etc. You cannot predict future difficulty accurately and the difficulty estimation is done with the data from the current epoch and can differ quite significantly by the time the difficulty changes.

They wouldn't.

The whole point of mixers is to eliminate the link between your coins and the coins sent from the service. Most mixers does this extremely well, by sending you funds that are completely unlinked to you. In most cases, the mixer takes your Bitcoins, send it to several addresses to obfuscate the link, consolidate some of them and keeps it for another user. Any competent mixer should not send the funds back to the user in the same session. Different mixers of course will have different procedures and methods to avoid detection.

As with the link mentioned above, the privacy was broken through blockchain analysis and it would be a good read if you want to know the rationale behind it. CoinJoin does not break the link, by the way. It merely obfuscates them but the link is still there.

A six sided dice provides a theoretical entropy of 2.58 per roll and you only need to theoretically roll it a little under a hundred times (99) for 256 bits of entropy for a 24 words (though you can get a 24 words seed with less entropy too). This is done under the assumption that each of the rolls are completely random and you throw it on the same way everytime and the dice is carefully designed to have zero bias, ie. Casino dice, etc. Crypto.getRandomValues() requests the browser for a cryptographically secure entropy and in Chromium's case, references /dev/urandom.

I'd say no. There are various variables affecting your dice roll and potentially lower its entropy below 256bits, even if you don't realize it. Problem with Crypto.getRandomValues() is that the way it gets the entropy can differ across each browser as there is no standardization on this though mostly it does use the system's CSPRNG. If you want to be extra careful, then you can XOR your own sourced entropy with the entropy generated from /dev/urandom and that should be secure enough for most uses. The amount of entropy would be thus the source with the most entropy (of the two).

I assume you're talking about generating your seed off the HW wallet and then using the generated seed on your Trezor by recovering it? You should assume the security of the seed to be that of an airgapped wallet and the hardware wallet only protects you from any compromise during its usage but not during the seed generation.

How do you audit the chips though? It can be open source but there is nothing you can possibly do if you can't verify that the chip follows the schematics exactly, evil maid attacks, etc. You would also lose some parts of the security; reason why most chips aren't open source is because they provide security through obscurity. Whether you can maintain a similar level of security with open source chips would probably be debatable.

No. There is no compensation for running a Bitcoin node. There is however, a very minute amount (depending on how many transactions gets routed) of Bitcoins to be earned if you run a LN node.

Neither of which would probably net sufficient revenue to pay for your dedicated server.

Fair enough. I thought some of the responses did highlight that the state of the mempool differs among the nodes and that it is highly customizable.

You're actually looking to bruteforce about 2^160 instead of 2^256-1, as there are a theoretical 2^96 private keys to the same address due to the address (v1) being encoded in RIPEMD160.

Even if you generate a trillion keys per second, you'll take about 4.6343913e+27 years to hit 10% of that. You can calculate how long it takes at various speeds and you'll find that it'll take quite a while still. If your keys were generated in a non-random manner, then it would be trivial for someone to compromise your address as the entropy is significantly lower.

I know but there is nothing stopping them from mining on your "censorship-free" chain as well and thereby censoring your new fork. As with everything that Bitcoin has done so far, any algorithm shift cannot take place overnight. I really wasn't implying that it would be done on a moments notice. Even a simple soft fork requires miners signaling which can take months, or even a year .

I would think that intentionally excluding blocks mined by specific miners would be far more dangerous. In the first place, identifying the blocks mined by them would be a difficult task if they remove any identification of it in the Coinbase. Reaching a consensus on which of the unidentified block to be excluded from the main chain would also be difficult. Miners orphaning blocks would also result in far lesser network security and possibly have to ensure that everyone waits for a few more confirmations, just like 2015's SPV mining.

A paper wallet has quite a broad definition and I would think that storing the important information which gives you access to the private keys or a set of private keys would be considered a paper wallet as well. If you're using a BIP39 compliant wallet (or any other wallet which provides a mnemonic), then there is really no reason for you to be using an electronic medium to be storing the wallet files or the seeds, unless you're looking to store the stuff that isn't covered by the seed (labels, request invoices, etc). The data loss on a paper would be far more obvious than on a USB drive, for which you won't know until you open it.

Storing a backup of the wallet on a USB flash drive doesn't necessarily make it a "flash drive wallet" or rather I've never really seen anyone calling it that.

So, we'll be more concerned about the security and the storage medium doesn't really matter as long as it is stored securely and has multiple redundancies. You'll be more concerned about generating the keys securely, which is needed no matter how you backup your wallet. You can do so by making your USB drive into a bootable USB, boot into it and use it to generate a wallet. The benefit of doing so is that you're able to achieve a somewhat of an "airgapped" setup though the environment may not always be as sanitized as you would like it to be. You can, however sign the transactions on it and is arguably more important than trying to determine what kind of terms should you use to describe a backup.

-- I personally don't necessarily consider a paper backup as a wallet. It serves its purpose as a backup but it doesn't function like a normal Bitcoin wallet with all the features but the terminology has more or less been ingrained and there is little point in changing it. Could see an argument if you define a wallet as something that store your private keys, then the terminology isn't wrong.

Also, paper "wallets" may not necessarily be better than your normal wallets. It all boils down to how you generate it.

This is too dangerous to be executed so the former is probably the only thing that should happen. I'd assume a change from SHA256D to something else, there isn't anything preventing them from mining on the new chain either.

Most block explorers do not classify the blocks mined by Marathon pool yet. You would have to look at the hashrate of those in the unknown instead. The problem with having a small amount of hashrate is that you're subjected to far more variance than others and you have to wait quite a while for it to be considered accurate at all.

They're also still in the process of deploying, AFAIK.

Right, I think there were several mining pools with specific preferences for transactions and this is a similar case as well but with a far worse motives. This is more of a concern than what it appears to be.

With MARA's compliance to government rules, it also means that other mining pools within their respective jurisdiction could possibly be forced to comply with their own set of rules as well and that is not limited to censorship. If there isn't any repercussions to their actions, then we could possibly see more mining pools adopting such measures or worse still, having the farms come after such regulations as well. Once 51% of the network comes under said regulations, something needs to be done urgently. Hopefully, that doesn't happen but it is still a possibility.

2FA is only secure if the initial setup was done in a secure environment. Most TOTP requires the secret during the activation of the 2FA to be secure. Coinbase vault is only secure if you are able to keep all of the accounts involved in the authentication secure. I don't think the funds are insured if it gets compromised due to the user's incompetency either, CMIIW.

Of course, this also means that you'll inevitably lose a lot of privacy when you're relying on a third party for the security of your funds. Hardware wallets or any airgapped wallets would be far more secure than trusting a third party, insured or not. Being in the sole control of your own funds would be a far better idea either way. I find HW wallets easy enough to use unless you're absolutely illiterate when it comes to computers. I also find the 48 hours waiting period quite ridiculous.

Nothing new. The miners have always been able to do so and perhaps covertly by outright excluding certain types of transactions or certain transactions associated with nefarious activity.

If anything it proves that some pools are able to actively censor transactions at will. It will unlikely achieve anything beyond delaying confirmations by a block at most, given their fairly small network hashrate. Miners would probably not want to mine in a pools with censorship measures anyways, unless they support it too.

Yeah. I get your point, even from the first analogy. There would definitely be a certain degree of collateral damage. Just to provide a more thorough discussion; I'm only as qualified to give my own opinions but nothing that technical or something that evaluates all of the variables. Here's a discussion that I once participated (closely followed rather) and pretty much conveys my take on this issue: https://bitcointalk.org/index.php?topic=1469099.0.

I don't think the scale of that would be to the tune of 2 million Bitcoins. Of course you should not remotely brick any device, that is absurd and absolutely immoral. I also don't think the million(?) Bitcoins that Satoshi holds (and presumably never be circulated again) would be in any hardware wallets or generated by it. It is safe to assume that most users do still have access to their hardware wallets and that is up to them to move their own coins, so I agree on the HW wallet scenario with you. I find the QC issue something that is more complex than this and no change (CMIIW) would save ECDSA keys from being vulnerable. My idea would be to have the network switch to a new algorithm and plan a fairly long road map to completely deprecate those ECDSA bound keys. Something like this could be planned when QCs capable of doing this feasibly (and also cost effectively) is on the horizon (probably 10-20 years before), well of course in the meantime convince people to switch to QC resistant signatures by discouraging them from using ECDSA keys.

Of course, violating that very rule of Bitcoin sounds completely absurd, I'll be very honest with you. I maintain that burning them is still a possibility as the impact could possibly hurt Bitcoin economically and IMO both of them have valid points.


You do. I respect both sides of the camp, that is why I believe that it is a moral dilemma.

For the record: https://www.reddit.com/r/Bitcoin/comments/4isxjr/petition_to_protect_satoshis_coins/d30we6f/.

It is definitely an unpopular opinion and I rest my case.

You can't create coins out of thin air.
They run different algorithms. Altcoins are worth nothing at the start and they are usually not very well known or used so there is really nothing to gain by attacking the coin with a 51% attack to reverse transactions. The attacker would however be wasting their time trying to do so and would rather just mine a profitable or well-known coin or just mine legitimately.