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.

Yeah I get what you mean. But the NODE_NETWORK_LIMITED doesn't mean that the node is pruned. My node, which has the entire blockchain on disk also signals NODE_NETWORK_LIMITED with 1033 flag, 1024 for being able to serve last 288 blocks, 8 for NODE_WITNESS and 1 for NODE_NETWORK.

So, for a full node with the entire blockchain, it should not only signal NODE_NETWORK_LIMITED but also NODE_NETWORK.

A nifty way to do so is to (prepend) the desired strings[1] as a subdomain to query. For example, nslookup x9.dnsseed.bluematt.me.

This will work if the DNS seeder supports service bits filtering[2].


[1] https://github.com/sipa/bitcoin-seeder/blob/a09d2870d1b7f4dd3c1753bbf4fd0bc3690b7ef9/main.cpp#L165
[2] https://github.com/bitcoin/bitcoin/blob/7cb0bcb6811070786937fb5cc0af82cf4ef21ff0/src/chainparams.cpp#L121

It is not free. Costs are incurred in the areas of R&D, maintenance, labour, etc. These are all costs that has to be offset by the producer and it should be more expensive than current methods. It's more of a cleaner energy than a free energy.

Proof of work will still function fine, you're possibly only (as stated probably not) reducing the costs from consuming the electricity. There are still scarce resources being consumed and incurred, production of ASICs, land, labour. It doesn't diminish any security of PoW based coins, perhaps slightly in the worst case.

State sponsored attacks, assuming 51% attacks has never been limited by the electrical costs or anything in that area. It is possible for countries to attack Bitcoin this way but it really doesn't make any sense right now and I don't expect countries to attempt it in the future either. ASICs required and the opportunity costs of having an attack is far greater than any benefits that they may have.

It is quite hard to prevent any leakage of the connections that you have. Getaddr does have privacy measures but if a person is determined enough, they can still achieve it though with much more difficulty. As I've mentioned in my previous post, without a MITM, it would be fairly hard for an adversary to execute a sybil attack that affects the security to that extent. Something like this would require a (relatively large) amount of resources with different IP ranges, and a huge number of nodes it to be even possible, not regarding the feasibility.

Having a secret or a trusted node can be a solution but it is definitely not necessary or doable for most, unless the final node that you're connecting to is definitely not getting sybil'ed, then you're safe. If it isn't then you're just wasting your resources. The counter against such attacks is the cost and the features of Bitcoin Core.

Connections between nodes are not encrypted. Packets can be dropped by the adversary and there is simply no way to detect something like this happening if the attacker can intercept the packets.

Not exactly. It does nothing if the attacker is actively listening to your connections, ie. a public wifi of some sorts. I'm not sure if this is the case but it wouldn't work if Bitcoin Core will tell the peers about the nodes you know about upon receiving a getaddr message. Trying to connect through another type of network or using some form of secure communication would reduce the chances of a successful MITM.

Implementing anchors.dat does help with the situation somewhat by mitigating the possibility of eclipse attack.

These attack should probably work better with MITM attacks and the attacker can possibly restrict the peers that they can connect to. It is usually quite targeted and specific as well, instead of it being a general attack as that'll be quite impractical given both the financial limitation as well as Bitcoin Core's node connection policy (IIRC it restricts the number of connections to each subnets). A single connection to a non-attacker controlled node will render this attack ineffective as well.

Both of them are possible but the scope of the attack is quite limited as well and doesn't make much sense financially.

No they cannot.

The nodes can do whatever they want, accepting invalid transactions, accepting blocks with thousands of block regards, etc. However, as you've mentioned, nodes enforces the rules themselves. No matter how many nodes an attacker controls, the set of rules that each node enforces cannot be changed. They will not accept any invalid blocks, transactions, messages, etc and they will be kicked after hitting the ban limit for the nodes.

The miners also cannot dictate the rules directly nor can they violate any rules if they want it to be accepted by the nodes.

Have a general sensing on the local laws first. If the jurisdiction that you're visiting explicitly bans cryptocurrency and/or deems any activities related to it as being illegal, I would advice you to err on the side of caution and leave it at home. Especially if you're a person of interest, something like this is probably an excuse that they can use. Might just be unnecessary paranoia but I personally wouldn't leave it to chances.

Hardware wallets are not completely safe from physical attacks as well, exposing it unnecessary like this would bring about a huge risk.

Probably. $100 is still quite little even with 10sat/byte.

ViaBTC requires at least 10sat/byte.

Depends actually. Some wallet do not remove or give their user an option to remove the transaction even when it gets dropped from most node's mempool. Could be a problem if this is the case.

At 20sat/vbyte, you'll be looking to pay at least $300-$400 in fees. If anyone is willing to confirm it for less than that, they're likely trying to scam you.

What wallet did you use for this? You can probably attempt to make another transaction which spends a higher fee if it gets dropped.