It is frankly quite absurd to be so obsessed with what either of them have said. The statistics are there and there is no reason why people would value either of their opinion over the statistics.

Fact is, the economics of mining at that time isn't like what it is now. I'm fairly sure when it was dominated by CPUs or perhaps GPU, the power consumption was far, far lower from how it is now. Your ASIC chips also contain gold and other metals, do you account for them during your estimation of environmental impact? Satoshi also probably didn't expect specialized chips (ASICs) to be produced for this as well. Frankly, we shouldn't really care about the narrative, the facts are out there. Bitcoin, even at its current capacity does what most banking systems and payment systems cannot, being decentralized and resistant to censorship.

Honestly, if you need a legacy wallet, there is simply no reason to choose BIP39 over Electrum seeds. Electrum seeds have obvious advantages over the former and generating it from some other sources raises some security concerns as well.

The story changes with nested Segwit wallet (which I think OP should use over legacy). There's no nested Segwit for Electrum seeds and for which BIP39 would be your only option.

You cannot achieve absolutely privacy with coin control. Doing so allows you to separate the UTXOs and avoid linking addresses together but it does not in anyway helps the user preserve their privacy. Transactions can still be linked, change addresses lowers the degree of confidence in terms of its association but in no way will it improve on privacy. CoinJoin and mixers are your best bet at it but there is always a chance of them compromising your privacy, either intentionally or unintentionally as well. Electrum is notorious for having mediocre privacy features and should not be used if you really care about it.

Having transactions that could be linked together defeats the purpose of having any privacy; any compromise along that chain of transaction will reveal your identity.

Depends on the mempool conditons. There should be a box for you to toggle between Static, ETA and mempool. ETA is the most conservative of them all and almost always guarantees a confirmation within X number of blocks. Mempool reflects the current state and doesn't necessarily guarantee a confirmation; putting it anywhere near 1vMB of the mempool should give you a confirmation within a few blocks, a block would probably shave 1vMB of transactions from the tip.

Fees are quite elevated right now; I would recommend you to just wait a day or two to see if it drops. Alternatively, you can still make a transaction as usual with a lower fee but make sure it is replaceable. Note that doing so would not allow you to lower the fees but would allow you to increase it instead. Be as conservative as you like and keep an eye out for the mempool conditions as well[1].

[1] https://jochen-hoenicke.de/queue/#BTC,24h,weight

There are no limits on how much you can send or receive in any Bitcoin wallets, unless they're custodial.

The limits that you're seeing is enforced by the exchanges as part of their KYC policy and validation should increase that. Keeping your Bitcoins on exchanges is not safe and you should not treat them as wallets.

I know Trezor actually overwrite the related sectors with random bits instead of just marking it as unused, which is acceptable. ColdCard, AFAIK has the seed encrypted in the secure element as well, ontop of the fact that it is prohibitively difficult to extract secrets out of it. Not sure about ColdCard's policy but it doesn't wipe the pin code.

Anyways, I'll really rather just microwave it rather than taking my chances when it comes to people with huge amount of resources at their disposal.

Yes. That is the block rewards, if an UTXO is not created for that, then you're not able to spend it at all. The value can be less than the block rewards + TX fees but can never exceed it.

The coinbase transaction doesn't require any reference to any UTXO, simply because there is nothing you have to reference.
OP_return is a kind of output that isn't stored inside the UTXO set of nodes and it allows the value to be 0. In most of the block generation transaction, the OP_return is mostly used to specify the merkle root of the witness tree.

Not necessarily.
Well, yes. Since you're running it on clearnet, whoever is monitoring your traffic (ISPs) would be aware that you're using Bitcoin. However, this doesn't necessarily leak any privacy as nothing sensitive is transferred over clearnet during IBD. Pruned mode or not, it'll download and verify all the blocks. There is no difference in the time taken. If you absolutely need privacy, I'll rather just run it through Tor.

No. It is far more dangerous for you to specify a preference of nodes for the client to connect. There is no reason why you should trust us, or any website to provide you with a list of non-malicious nodes. DNS seeds are used only when necessary and Bitcoin Core already attempts to diversify the nodes that the client connects to. Bitcoin Core does have countermeasures and should provide sufficient privacy unless you're ONLY connected to malicious nodes which is quite unlikely.

Perhaps that is why he went to such great lengths to attempt to conceal his identity?

Actually his identity matters, kind of. He's potentially in control of a million Bitcoins, imagine if one day we find out that Bitcoin was actually created by the North Korean Government .

Come on. That is called a burn address for a reason, it is practically impossible for someone to have a keypair that corresponds to that address. Not even Satoshi would know, it is mathematically improbable.

Use Tor, use mixers, use Bitcoin Core. Important to note that your privacy leak may or may not be related with Bitcoin.



No such thing as anonymity in Bitcoin, even if the users were to be careful with their activities, it would be the best to assume that Bitcoin is pseudonymous at best. There are far too many possible privacy leaks with users even if they were careful enough; potential spy nodes on the network, possible leaks through mixers with their heuristics, etc. Bitcoin was never really designed to provide anonymity from the start and all the current implementation only helps to maintain the privacy of the user.

As mentioned, CoinJoin, mixers all helps with the privacy. Confidential transactions has been proposed as well, which helps with privacy but at the expense of higher resource requirements.

Yes, actually. The position of the nonce is defined in the block header, specifically the last 4 bytes of it. That isn't changed, no matter how the miner decides to change the parameter. Miners have to change the timestamp from time to time, or at least another parameter else the nonce will overflow.

Note that changing a parameter within the block header doesn't make that a nonce. It is just a way for the miner to vary the block header in order to produce a different hash.

There are a lot of variables which can be changed within the block for a completely new block hash. Look at your block header, if you can change anything within that, you're able to hash a completely new string and thus counts as an attempt to get the block header that meets the target.

Other than nonce, timestamp, miners can also choose to rearrange the transactions within the block, changing something within your Coinbase scriptsig, etc. As long as the way you change your block header doesn't invalidate the entire block. Overt ASICBoost uses the versionbit and thus that is why some blocks has a strange version bit, also a way to change the block header but this is an optimization for certain ASICs.

If you count the dice values as it is (base 6), it'll have 2.58 entropy per roll. Using SHA256 ensures that the result will be always 256 bits, regardless of how many dice rolls is used. I assume OP is talking about ColdCard's way of generating it, which is what I've mentioned.

I think using the method I've mentioned requires far less effort.

Actually, you can sign a message using the private key.

Use signmessagewithprivkey and Bitcoin Core will directly sign a message with the private key provided and thus would be a workaround for the problem. The signature validates with Electrum as well as the way it uses the signed message is the same. Note that this is only a workaround and it doesn't mean that Bitcoin Core will validate any signatures from segwit addresses, nested or bc1.

The 100 rolls provides 258 bits of entropy. Anything above 128 bits is secure enough, Bitcoin addresses uses 128bits as well.

It is not that there isn't any point adding more dice rolls. 24 words seed should have 256 bits of entropy but 128 bits is enough as well, a SHA256 hash will stretch it. I'd say anything between 128bits and 256 bits is enough. Hashing using SHA256 will not result in any security over 256 bits for your seeds.

If represented in 1-6, at least 50 for 12 words.

It's not terrible to get more results but Bitcoin keys are only 128bits in security so 256 bits is already quite a lot and there is some leeway for biasness as well. If you're using SHA256 as a hash function for the entropy, keep in mind that the resultant entropy won't be more than 256 bits, even if you roll it 200 times with a perfectly fair dice.

It needs to be perfectly random for the theoretical entropy to be reached. Many cheap dices are biased due to the imbalance in CG or having faces that are not perfectly flat. It is just nitpicking in most cases given it provides 256bits of entropy so there is some redundancy.
It is stated in the BIP actually. The requirement is actually for if you are using the raw entropy to generate a seed, then yeah. If you're using some kind of stretching, ie SHA256, then you don't need it to be in the multiples as the result will always be 256 bits, or 24 words.

Since OP says that he wants to generate a seed, you only actually need to obtain an entropy that is sufficiently random (256bits) once, keep it secure and after which just use it to generate your addresses. This is also known as BIP32 and loads of people actually use dice rolling as a source of entropy. BIP39 is just another way to encode it into a string of mnemonics (quite simple actually) and use it for BIP32 derivation afterwards.

It's important to note that due to the many variables associated with this; the way you throw the dice, the kind of dice, etc. The resultant entropy can very well be under 256bits due to some degree of predictability associated with it. If you're paranoid that the RNG isn't working correctly (perfectly valid, happened before), then this can be a way to guarantee "sufficient" entropy.

CoinJoin? Governments are requesting exchanges and services to blacklist coins that were involved in CoinJoin transactions. CoinJoin mixes your coins by obscurity but it doesn't necessarily break the link between them. Unfortunately, if you want any adoption, you NEED exchanges which are registered. Decentralized exchange unfortunately doesn't always sit well with people; P2P OTC trades are not as secure as it seems. Some would rather give up their privacy than to risk their funds.

They don't need to ban mixers to spy on their citizen. There are tons of ways to do so without and if they're smart, they would bring blockchain analysis into the picture and let the mixers continue running. Centralized mixers can survive, they just need to operate in a jurisdiction which respects their privacy or operate off-shore.