None of the replies actually answered your question.

Estimates puts it at after 2030, there could be a quantum computer that is capable to break an asymmetric cryptography, which is the ECDSA that Bitcoin uses. These are just purely estimate and currently, the highest known qubit count of a quantum computer is less than 100 (or somewhere thereof). You need more than 1200 qubits to be able to factorize it within a reasonable period of time and even that comes both in the huge cost of building one as well as running it. Bitcoin won't be the first to be attacked, it is just not profitable.

Should be done through Tor with some privacy precautions being done at least. It is possible to be tracked when submitting the transaction.

I would normally recommend doing this as it's far more reliable than using your client but you do need to give up quite a bit of privacy when doing so. Would recommend to just troubleshoot Bitcoin Core and see what's going on. This usually shouldn't happen with Bitcoin Core.

Your denominations. 1mBTC = 0.001BTC. You're sending less Bitcoins than the dust value which is about 546 Satoshis.

Go to your preferences and you can change it to BTC for a better clarity.

They are finding a suitable hash that meets the current target. PoW as the term describes, requires the miners to provide a hash of the block header that is less than or equal to the current target. As the occurance of a hash is rare when the difficult gets higher, miners are essentially going through many iterations of the block headers by changing specific components, most commonly the nonce or the extra nonce to try to find a valid block which meets the target requirement.

Block headers consist of the merkle root, timestamp, nonce, last block hash, etc. They are hashed twice to produce a result and is only valid at the current target if the value of the hash is below the current target.

It is not accurate to call it a puzzle we they're not exactly given a problem to solve.

No. You're supposed to replace the string with the raw transaction that you've copied to the clipboard. If you followed the steps that I've described, you should have copied the raw transaction to the clipboard already. Pasting the string after sendrawtransaction should suffice.

This will make your client rebroadcast your transaction to your peers. Since you're using Tails, I doubt you want to give up any part of your privacy or else, simply pasting the string into blockchair.com/broadcast works as well.

Focus is on the motivation section, not the security. People think that you're decreasing the entropy by implementing a version byte at the start. You can get more entropy with BIP39 if you want, 24 words provides you with more entropy. Electrum only has 12 words with that amount of entropy. Not a deal breaker for anyone at all.

Point taken. Can't blame Electrum for wanting to address the shortcomings of a system like this. There really isn't any confusion between Electrum seed and BIP39s, especially when their checksum aren't compatible with one another (implemented recently). Importing an Electrum seed is unambiguous, telling you the kind of seed it is. Importing BIP39 seed leaves you questioning what kind of seed, what kind of derivation path it is. If anything, Electrum is doing people a favour by addressing the shortcomings. Perhaps more wallets should stop ignoring the obvious failure of BIP39 and be like Bitcoin Core!

BIP39, as the BIP says is "Unanimously Discourage for implementation". It is the "industry standard" solely because it is made into a BIP and no one really bothers about it as long as it is secure.

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

An air-gapped method is the only way to avoid your funds being stolen, there are plenty of guides around. Electrum is the easiest way to do so; get a LiveUSB, boot it load your private key in Electrum. I don't believe that you wouldn't be able to follow a few guides on this and it is really far from being a rocket science.

If you're unwilling to do so, then you have no other choice but to sweep it on an online computer and risk getting it compromised. Using a paper wallet should basically mean that you're going to have to use an air-gapped setup at some point in time.

No.
Yes. It should work. Do you get any thing after running the commands as I've said?

You can't exactly make sure your computer doesn't have malware and virus, it can just be undetectable and storing it offline is the only way for non-physical attacks to be prevented.



Storing your seeds in any digital medium will open up a whole range of attack vectors, malware, password compromise, encrypted data leak from the password manager. If you're storing your seeds on the cloud, I consider that as good as giving someone else your password. Most password manager encrypts your data locally but that doesn't mean an attacker can't get your encrypted string and start bruteforcing it. While it is unlikely that people can crack your encrypted strings unless you're using a weak password, why would you even take the risk?

It has been enabled by default for years and transactions are sent with the RBF flag. I don't think there were any changes to this behavior recently, 4.x.x but it was changed in 3.3.0, from the changelog.

Newbies don't have to know the technical stuff behind RBF or CPFP, or anything to that extent. They just need to know how to remedy something like this, which the links in the first reply has covered together with pictorial illustrations.

Electrum only support Bitcoin, forks of that may support certain altcoins but they're neither supported not endorsed by the developers.

Are you guarding against MITM attacks specifically? IMO Sybil or Eclipse attacks are not cheap nor that great of a concern. It should be better to make Bitcoin Core use Tor instead of complicating things by chaining multiple nodes and probably incur much more costs as well. If it is a targeted attack, then you're just reducing the probability of the attacker influencing the nodes which Bitcoin Core should connect to. The attacker has to figure out your onion address and the nodes for which you're connected to for a successful eclipse attack which could be quite difficult.

There are safeguards against eclipse attack implemented in Bitcoin Core. Having a secure connection between your node and the other nodes would defeat MITM and the safeguards would do the rest.

Go to your transaction history, right click on this transaction and press "Copy Raw Transaction".

Go to Window>Console and type in the following format:

Replace the long string (02000...) with the one that you've copied.

It has been turned on by default for quite some time, since one of the version from 2018.


Almost there. Even if you were to use RBF and spend the inputs to another address, miners can still choose to include your first transaction instead of the one with the increased fee. They are both valid until one of them gets confirmed.

It is changed due to either some change in the inputs/output or some change in the value of the outputs.

---

No offence, the post is actually extremely wordy and some better structuring would be needed.

Just create another transaction with a larger fee rate. The current minimum mempool fee is at least 2sat/vbyte.

The transaction wasn't broadcasted because it didn't meet the minimum mempool fee rates. This means that nothing actually changed on the network level so you should be able to create a new transaction on your online Electrum.

Some mixers or services exhibits certain identifiable behavior and it would be fairly easy to flag them as a suspicious transaction, CoinJoin namely would have many inputs and outputs with some of the outputs having consistent value. It is not difficult for them to identify it but tracing it would be a problem.

Transferring the coins a few times after mixing could probably solve the issue. This way, there is an argument to be made that you're not the one using a mixer and instead the person who sent you the coins did. It's not a guaranteed success but it would be better than sending the CoinJoin to them directly. Keep in mind if that if an exchange doesn't want you to use CoinJoin or any mixers, then your privacy is under threat anyways. I consider them complicit with helping the government to track their customers.

Pruned nodes are meant for those users who wants to run Bitcoin Core but cannot keep up with the storage requirements. It is not a substitute for archival nodes because they're different in certain aspects.

IMO, even if you don't allow people to use pruning, then they would simply not run a node at all. Eitherways, those running pruned nodes are still a net benefit to Bitcoin. As long as people are aware of the utility and differences between the both of them, there is really no problem about this. Some will continue running full archival nodes and the rest that can't will simply run a pruned full node.

...
But I think this is a better as an entirely separate topic instead of continuing it on this thread.

The only instance which the checksum will fail given a correct BIP39 seed is if it was generated with Electrum.

If not, here's a guide on BTCrecover and trying to unscramble the seed phrase: https://github.com/3rdIteration/btcrecover/blob/master/docs/BIP39_descrambling_seedlists.md.

Coordinating multiple governments is a hard enough tasks, coupled with potential conflict of interests between them.

China actually controls about 65% of the hashrate, based on CBECI's research BUT that is based on a sampling of several mining pools which are pretty much all based in China so take it with a pinch of salt. If you're talking about controlling the current 51% of the hashrate, it is already possible for certain states to have that much within their geographical boundaries but coercing and coordinating an attack, especially with such a huge and diversed region like China could be very difficult.

If you're thinking of the government purchasing them, it is possible but it would be a terrible idea. It would be useless after an attack.

Bitcoin's energy consumption is not excessively big, not that current infrastructure cannot support it and I predict by the time nuclear fusion becomes practical, the cost and efficiency of other forms of energy would've probably increased as well. 51% attacks cannot be sustained over long periods of time; after a single attack, the community would react to the attack accordingly and probably render the ASICs useless. There is no point in sustaining such an attack and given Bitcoin's total market cap, any 51% attack would be purely political as the cost would probably be greater than the benefits and that the GDP of a single country is likely greater than what they stand to gain financially from such an attack.

But, if you're talking about countries like North Korea then they probably would be incentivised financially. Given their energy situation, its safe to say that they're far from a threat.