The way BIP39 works is that it relies on a set of word list for the checksum. Newer Electrum seeds are not interchangable with BIP39 seeds due to the checksums being incompatible. If you need to change the standard, then that is a way to go. It is not in the process of being deprecated, I haven't seen any other mnemonic system other than Electrum being used here.

Adding additional language support, other than the mentioned limitation requires the developer implementing more wordlist and computation for the checksum. There is just no point adding so many languages, especially with the given limitation.

It's called virtue signalling. If they really cared about the environment from the start, they would've never endorsed Bitcoin or Dogecoin. The environmental impacts of both is fairly obvious, even if you've only got a superficial understanding of it. The only reason why they even ventured into Bitcoin from the start was to improve on their financial reports. I wouldn't be surprised if there is some insiders trading involved when it comes to this as well  .

Most of the posts assumes that the electrical outage is localized, which isn't the point of this post if I understand correctly.

The answer is not possible. If there is no electricity, then Bitcoin cannot function. The same happens if there is no way to communicate with others as the network cannot transfer information. Even if you were to use something like OpenDime or pre-signed transactions, there is no way to check it as the Blockchain cannot function. Your currency can only be something that doesn't require electricity to function and there would probably be far more serious issues to be concerned about at that point.

Yes. Compact block does basic validations (block headers) which is much faster than a full validation of it before relaying to the peers under high bandwidth mode. Bitcoin Core has compact block support which lowers the relay time quite significantly. Given that my node connects to over 125 peers, it would probably mean that the time that the block takes to reach my block is far lower than most. Since the post was from 2016 and given the optimizations for block propagation/validation, I'll consider the actual time taken to be a lot smaller.

From my previous experience, the deviation between two of my nodes which are considered fairly far in terms of geographical distance was about 1 second. I'd say that the time that it takes for it to have a good propagation is far less than 40 seconds.

I suppose there could be a small amount of delay within the mining pool themselves as well. After constructing the empty block header, it has to be sent to the miner, the ASIC returns the golden nonce, it gets sent back to the server, the server validates and the server starts to propagate. There is no telling of how much delay (if any) that is present within the mining pool. I'll think that pools like Poolin would probably try to avoid mining empty blocks as that'll mean potential loss in revenue for their miners. SPV mining is a different case.

For what it's worth, here's the timestamp I've pulled from my node:


It's not uncommon for the block timestamps to have quite a significant deviation. Taking the relayed time of a well connected node would be far better for this.

It doesn't generate invalid random seeds, quite the opposite; it generates valid non-random seed. Electrum uses randrange which is seeded from the OS's CSPRNG (/dev/urandom) and it thus generates a seed with sufficient entropy and is not prone to issue like this. Unfortunately, there is just way too many developers who overlook certain aspects which are arguably pretty important and putting their user's funds at risk. This isn't the first time something like this has happened.

Are the signatures generated by the wallet deterministic or do they rely on the flawed RNG as well?

Note that if it is a legacy address, it is m/44'/0'/0' or if it is a Segwit address it'll be m/84'/0'/0'. The | is used to demarcate the two standards.

Exodus doesn't generate Nested Segwit AFAIK.

The block before that (683272) was propagated right before this block was propagated. My best guess would be SPV mining where the pool intentionally constructs a block without any transactions while they validate the previous block. Doing so would eliminate the risk of the block being invalid as it has yet to validate the entire block and thus wouldn't know the transactions that were already included in that block. -- Including a transaction that has already been included in a prior block within the same chain makes the entire block invalid, even if it has a valid POW.

Validation time for a proper pool has proven to be quite short. Not all of the pool practices this and thus there can be blocks that are mined within a few seconds of each other yet the transactions are still included.

That's not the point. Here is gmaxwell's opinion on this and I consider him more competent and credible than most: https://bitcointalk.org/index.php?topic=5324030.msg56590276#msg56590276.

I've had little experience with JS, specifically with regards to its security so I can't comment too much. I'll rather something that interfaces directly with the a CSPRNG than to have it ask the browser for entropy and risk the browser potentially not implementing it correctly.

They should be compatible but you need to choose the correct derivation path. Did you import an address or a private keys (Starts with either K or L)?

Try following this guide? https://support.exodus.com/article/159-import-your-bitcoin-wallet-into-electrum

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.