Nope, it's not or perhaps their settings is slightly different.

Both Statoshi and my nodes are indicating it to be slightly more than 1.9sat/vbyte. You can check my node's info for something that indicates the default settings and thus the general node population: http://163.172.57.208/getmempoolinfo.txt.

I would probably expect it to be purged again after the TX volume rises by the mid week, if that happens just broadcast it again. Don't think ~2sat/vbyte has any chance for a confirmation given the current situation.

o_e_l_e_o is correct... it's a mechanism used to try and keep the mempool "size" to below 300 Megabytes... Transactions with very very low fees will either not be accepted or be "purged" if the "mempoolminfee" increases to a value higher than the transaction.

If you look here: https://statoshi.info:3000/d/000000020/memory-pool?orgId=1 (check last graph)
and here: https://mempool.space/


You'll see that this value is currently around 7 sats/byte... any transaction with a fee less than this will either not be accepted... or purged if it was already in a node's mempool.

Note that this value is not the same as the "minrelaytxfee" (which usually defaults to 1 sat/byte)

I was having this problem last week when I was trying to consolidate some really small payments that I had received. i wanted to see how low of a fee I could get away with so I ended up copying the raw transaction and broadcasting it from several block explorer websites. BTC.com and mempool.space will allow you to broadcast a transaction with a fee of 1 sat/vbyte but BTC.com will get rid of it after a few days.

Note that this value is not the same as the "minrelaytxfee" (which usually defaults to 1 sat/byte)

68 isn't that many in the grand scheme of things... if it was several hundred or 1000+ or something, then it might cause the throttling... but 68 shouldn't really trigger that.

And even stranger that it works perfectly on a different PC... there must be something in the setup of that specific PC that is causing the connections to go crazy like that... some AntiVirus/AntiMalware or firewall perhaps?

Approximately how many transactions and/or addresses are in that specific wallet?

It could be that your wallet simply has too many transactions and/or is requesting info for too many addresses at once... because of that the servers are throttling your connection... Once it is throttled, the "ElectrumX" server (which most Electrum Servers are running) will remember your IP and refuse your connection until a specified timeout period has passed.

https://live.blockcypher.com/btc/pushtx/
you will have to paste your entire tranasction hex (like what you posted in an earlier comment here) in this textbox and press broadcast.
keep in mind that there is no guarantee that other nodes would accept a transaction that may break one of their preferences (standard rules) such as RBF fee bump.

It seems that there is something blocking your Electrum to connect in any Electrum server.

Are you using a VPN? Try to disable it and try again. If not, then try to change your PC/Laptop DNS.

You can choose any of these DNS below.
- 8.8.8.8 and 8.8.4.4 = Google DNS
- 1.1.1.1 and 1.0.0.1 = Cloudflare DNS

After you manually set the DNS, follow this.

- Open CMD
- Type "ipconfig /release" then enter
- Type "ipconfig /renew" then enter
- Type "ipconfig /flushdns" then enter

Then try to check your Electrum again if the circle turns to green.

Mine has no problem with synchronization.

Seems like you've been being disconnected from your selected server again and again, try to connect to other servers.
If you're using your own and it's outdated, upgrade to the latest version (probably related: Electrum 4.0.2 keeps Synchronizing)

BTW, that was off-topic... and the number below that's being updated is the total number of addresses in your wallet + new UTXOs.

Could've been me. I went to try to broadcast the transaction everywhere and found that Blockcypher doesn't follow the RBF fee increment rule (or didn't see your old transaction). You could've lucked out and Blockcypher relayed it to a miner who also doesn't care about the amount of fee increment.

I would say that it's an outlier and you would usually have to increase the fee enough to meet the requirement.

I looked at the transaction that you're trying to replace. It doesn't have enough incremental fee.

The reference node requires that the new transaction to pay an additional fee (amounting to a network relay fee) to the previous transaction. Failing which, the reference node will refuse to relay the transaction resulting in a poor propagation. Try paying an additional 0.00000073BTC.

You can try it: instead of using just the nodeid, follow it with an '@' sign then the PC/ISP's IP address like for example:
0369c4ddc6076646ddf30ad58c4beca8eee399557063f69a17xxxxxxxxxxxxxxxxx@17x.1xx.2x.4x
Both Electrum wallets should be active.

Might be an issue with how coinb.in calculate fees/byte. Could you paste the raw TX here?

if the original transaction is marked as replaceable (this is the default behaviour in electrum) then simply right clicking it and choosing increase fee, choosing a higher fee and then clicking ok and then sign and broadcast in the next window should do the trick.

Is your replacement transaction having a larger fee per byte than your first transaction?

Just a web utility tool for you to submit transactions to the network[1].

[1] coinb.in/#broadcast

I don't get it.
But everything you can do with mainnet, you can do the same with testnet.

Because, you'll have to pay a fee that might take a portion of it to spend that balance because you'll end up with lots of very small inputs.
Transaction fee will be based from the fee rate (which you'll set in the wallet) and the transaction's virtual size which will get higher if it has a lot of inputs.
1sat/B is still good enough to consolidate them though.

Custodial wallets will just send from their hot wallet when you want to withdraw (minus their fee which can be cheaper for low-priority).
Personally, I'll use a custodial wallet for that amount.

LN is a very good choice however won't let you receive 'savings' from your 'clients' unless you have enough inbound capacity.
And you don't have enough funds to open a channel of 0.002 BTC then use submarine swap or spend some satoshi.
You need to find a way to increase your inbound capacity like mentioned in the previous sentence.

I don't get it.
But everything you can do with mainnet, you can do the same with testnet.

broadcast using a broadcast tool.