testnet3 users lack full-time nodes

So, I noticed something that might interest some testnet3 folks. There are plenty of transactions on https://mempool.space/testnet that just sit there unconfirmed for days. It’s kinda weird since some miners are mining blocks that aren’t even full, so you’d think they could easily include these transactions, especially since some of them have lower fees. But why are so many blocks empty? Well, a lot of users just throw in their transactions and then shut down their clients. And when their nodes are offline? Those transactions don’t get re-broadcasted by anyone. So when new miners come along, they don’t see those transactions. They don’t include them in their block proposals and the waiting game just keeps extending until one of the old miners finally picks it up. Check this out: https://mempool.space/testnet/tx/882cf91eb089fd83ae26f6f557dc0d5ff4a670b07b405282200c5fd963267329#vin=0 This one was unconfirmed for 4 days. And honestly, it probably would’ve stayed unconfirmed for a lot longer. But then, just a minute later, it got confirmed! (I’ve seen this happen with other transactions too. It’s not just luck; every transaction I rebroadcast was confirmed in just minutes, even if they were stuck for days.) So my takeaway? Running a full node (even in pruning mode) is a smart move if you want your transactions confirmed faster. You might have a "fee rate" of 856 sat/vB and an "effective fee rate" of 3,048 sat/vB, but still end up waiting days for one confirmation. But if you just keep a full node up and running...

You'll be surprised by how many users of mainnet run their own node.   You could blame the miners as well. If your only source of (testnet) income is through transaction fees, then you should increase your storage limit and allow more transactions in your mempool, and for longer time. BTW, why does it have an average block time of 43 seconds? What's the name of the attack it currently experiences?

The same issues can happen in each chain, which copy-pasted Bitcoin Core source code. Which is why even if you are just a regular user, you are incentivized to run some kind of node, to re-broadcast your own transactions. For the same reasons we have testnet4: every 2016 blocks, the difficulty is adjusted. If you mine a block with CPU difficulty in exactly the right time, then, the code assumes, that it was the network difficulty for the last two weeks. And then, it is resetted. And then, after each re-adjustment, ASICs bring back the difficulty from 1 to the real one. Just a regular blockstorm, which is why we have 17 halvings and 38146 satoshis as the base reward in testnet3, even though the chain started in 2011. Of course. I still don't understand, why some users run their ASICs, and include a single coinbase transaction, getting 38146 satoshis, instead of getting 7 tBTC for the same work, and including transactions properly. In general, all of that is just a remainder, that full nodes are important, and what can happen, when there are not enough of them, running 24/7. Also, it is yet another remainder, that by default, transaction propagation is quite weak, and there are some tricks, which you can use for a while, as long as some miners won't fill their mempools properly (for example by replacing 100 sat/vB transaction with just 1 sat/vB transaction through full-RBF, if you send it to the right node).

So, in testnet3, when no block is found for 20 minutes, you can quickly mine a long chain of difficulty=1 blocks, and immediately broadcast them, whereas in testnet4, this chain of blocks cannot go more than 2 hours into the future and each block has to have a time distance of 20 minutes + 1 second. Is that right?

Exactly. It is called time-warp attack, it is why BIP-94 was introduced, and it is also described here: https://blog.lopp.net/griefing-bitcoin-testnet/ Two hours rule is present in all networks. But: if you don't have restrictions from BIP-94, then you can pretend, that something took two weeks, even if it is not the case. I think Jameson Lopp described it quite well, how you can fake timestamps. No. If you reset the difficulty, during difficulty adjustment, then you can produce six blocks per second, and after 2016 blocks (mined in 5 minutes and 36 seconds), the difficulty will be changed from 1 to 4. Then, after the next 2016 blocks, it will change from 4 to 16, and so on, until you reach the real difficulty. But: if you apply Lopp's attack, then you can for example switch the difficulty in different ways, for example: 1 -> 4 -> 1 -> 4 -> 1 ... The difference between testnet4 and testnet3, when it comes to difficulty adjustments, is that after 2016 blocks, testnet3 difficulty can go for example from 123456789 into 1. But in testnet4, ASICs have to mine at least a single block per two weeks, with the real difficulty. And then, on top of that, you have timewarp rules from BIP-94, which are restricting timestamps further (and are still discussed by developers, because it is still not fully clear, which rules will be deployed into mainnet).

There is no correlation between running a node + staying online and having your transaction mined. When a transaction is pushed to the network (whether through your own full node or a SPV client or even an online tool to push it) it becomes part of the transactions in other full nodes' (aka peers') mempool on the network. A new miner connects to a node or a pool that was already online. If a new node comes online they will request mempool from other peers and they will receive the transactions in their mempool which will include the tx pushed by someone who went offline. It could be a bug with mempool.space website and node they run in the backend! My guess is that it is a lack of relay problem. For example if you check some of the transactions found on https://mempool.space/testnet/mempool-block/0 in other block explorers you can see that they cannot be found elsewhere. Example: https://mempool.space/testnet/tx/9249f922fbf243ccd1107f9a25db1ed1372dc876b585bdd8f98aab8ad5eea0e5 Says it was first seen 3 days ago but it cannot be found on other explorers https://live.blockcypher.com/btc-testnet/tx/9249f922fbf243ccd1107f9a25db1ed1372dc876b585bdd8f98aab8ad5eea0e5 https://blockstream.info/testnet/search?q=9249f922fbf243ccd1107f9a25db1ed1372dc876b585bdd8f98aab8ad5eea0e5 Maybe these transactions were pushed directly through their service here https://mempool.space/testnet/tx/push but their node doesn't relay them to the rest of the network. Therefore those txs stay only in their node and show up only in their platform. Meaning no miner sees them to mine them. This explains why they were mined when you manually download the raw tx from their website and push it using your own node. Edit: Here is an experiment to show you don't need a full node and the problem is with mempool.space. Take any tx from their UI like https://mempool.space/testnet/tx/0ad727680449c102b36baacc1f33cff09da69c42655710af25588632291cf0c6#vout=0 and download the raw hex. Then go to any explorer like https://live.blockcypher.com/btc/pushtx/ or https://blockstream.info/testnet/tx/push to push the tx. It gets confirmed right away like the one I experimented with and was confirmed already after 2 months.

I guess you are right. I saw transaction counter increased from 100k into 400k, but my node received none of that. Which means, that someone is just pushing transactions to their block explorer, without sending any of that to the rest of the network.

Mempool.space probably has more bugs. In the testnet4 explorer, this address[1] is shown as having minus 20 thousand something bitcoin. It's probably due to a miscalculation that occurs in their backend when the chain is reorged. (It happens when this miner reorgs the chain, while there is a transaction that spends from his address reorged.) [1] https://mempool.space/testnet4/address/tb1qwq8yt3w6k2yrjr2nwq2a59wny3f3ns2xx3fgg9