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.

Not discarded. By BIP39, the seed must have an entropy in multiples of 32 so there is no limit to how many you have to use. After all, the mnemonic is passed through a KDF for the actual seed to be used so the length actually isn't limited. Your addresses only has 128 bits of security so people would probably look to compromise the individual addresses instead of seeds, they're much faster to generate.
Nothing happens. You won't generate any invalid addresses.

As said, it passes through the KDF so the checksum only serves to provide a check for typo.

There really isn't any reason.

Unfortunately, Electrum never supported nested Segwit addresses. A workaround would be to generate a BIP39 seed and import it into Electrum. That introduces too many points of failure and I generally recommend against it. If you want compatibility and also Segwit benefits (to a smaller extent), then you should use another wallet instead of using the workaround.

It is. I would argue that it becomes an altcoin. The foundation of Bitcoin has mostly been left unchanged and it probably should be, barring any vulnerabilities of some sort. The game theoretic model of PoW is basically as good as it gets; giving up resources for the security of the network.

If you're finding another scheme that can secure the network in the same way, then the miners that we have today will be out of the equation. That is not going to sit well with them in the first place. Perhaps we should change PoW, if such a great scheme comes about but the fact that you're never going to get any significant consensus with so much conflict of interest makes it hard for us to agree to a change. I wouldn't bother, PoW is fine as it is. People needs to start attacking actual climate change contributors for it or just go and penalize miners with carbon tax. That's all.

Yes. On your account, it might be $500, as you didn't wiithdraw the $500 in Ether. However, the funds in that deposit address can be 0 still.

The deposit address doesn't belong to you; it is just an address that is associated with your account and any deposits would be credited to your ByBit account. Any exchanges within the site is reflected on the backend and in your account. The funds in that address does not matter to you as it is under their control and they can do whatever they want with it; consolidating it or sending it to another address. What is important is that your deposits are all credited correctly, the balance of your deposit address does not necessary matter as the balance on that is often different from your own account on that site.

Check your transaction history on the site. Has everything been credited correctly?

The thing with most services is that anything done to the account may not necessarily reflect a transaction to or from your address. For example, if I choose to sell Bitcoins on an exchange, the funds in that address may not be moved immediately but it is regarded as sold on the exchange and that my account balance is now in fiat instead of Bitcoins. The balance on the address is not reflective of your current balance in your account.

Thanks. I overlooked this.

Generally forgetfulness, amnesia or just any other thing that can affect your memory, the list goes on.

I definitely wouldn't take the risk and blame myself later on for forgetting a seed phrase. Just having a physical copy of it and keeping it safe would be fine for most.

Side channel attacks shouldn't be your main concern, secp256k1 libraries has mitigations against most of that so you'll be mostly safe. Problem would be with malware or some $5 wrench attack.

Privacy concern would be that it would be obvious which testnet addresses and mainnet addresses belongs to each other, public keys would be the same. I wouldn't do so though, leads to unnecessary confusion as well and perhaps leads to unnecessary risks depending on what you're doing with your testnet. It's really not difficult to use two separate seeds and it's quite dangerous for people to be memorizing seeds.

Rescan, not reindex.

EPS is okay for most uses as it just serves as a data source for Electrum clients, so there really isn't anything to criticize there. If you need your personal server which is easier to setup and has lower resource requirements, then this is it.
ElectrumX is the most common implementation used by Electrum servers.

Voluntarily locking your own coins with time as a parameter doesn't affect security in the slightest. It depends on how you generate and handle the keys for that.

If you want something to lock your coins for a long time, don't use nLockTime or any mechanism like that and pre-generate a transaction. It is not ideal for that as you cannot change anything in the transaction. Instead, use OP_CLTV and include it in a scripthash address. You'll be able to "unlock" and spend the funds after a specified period of time provided that you have the required key to unlock it.