Whats the current state of testnet3 vs testnet4?

[nc50lc]

Edit: I requested coins from coinfaucet and it's not working. It's stuck with 0 confirmations. If anyone could confirm if testnet4 is down or something let me know..

It's not down, blocks are just too inconsistent unlike in mainnet.

Any ideas? Do I just send it with no miner fee? or add a custom one?

There's not much transactions in testnet4, you can just set it to 0.1-1sat/vB or set "fallbackfee=0.00001" so you don't have to manually set it whenever estimate is taking too long to work.

[LoyceV]

Edit: I requested coins from coinfaucet and it's not working. It's stuck with 0 confirmations.

That's what I meant when I mentioned most "miners" mine empty blocks on testnet4. This way they're the fastest claiming the block reward.

[athanred]

Transaction Fee: Warning: fee estimation is not currently possible.

I never trusted Bitcoin Core's fee estimation, and always picked my fees manually. Historically, it was the worst fee estimator I saw, so I stopped using it years ago. There is even a topic on Delving, where some people tried to fix it, but they probably didn't deploy it yet, if it doesn't work for you: https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703

Any ideas?

Just look at your own mempool, and see, what fees are needed. Probably "getblocktemplate" will give you a valid block data, collected from your own node, and then, you can simply check, what is the lowest fee, that could be included.

Do I just send it with no miner fee?

Well, if you use testnet4, then you can always disconnect from the network, wait 20 minutes, and then mine any block on your CPU. If all you need is testing things, and not trading coins, then that should be sufficient.

or add a custom one?

I always added a custom one. But also note, that because of CPU blocks, mined every 20 minutes, you will have to wait for the next ASIC block, to see your transaction confirmed. Because testnet4 CPU miners usually include no transactions, to see their blocks propagated faster. It is more profitable to win 50 tBTCs, instead of trying to get for example 50.01 tBTC, and losing everything, just because someone else propagated a block faster, at the same height.

It's stuck with 0 confirmations.

It will confirm, when some ASIC miner will include it. CPU miners have no incentive to include transactions, because it slows down their block propagation. And because everyone keeps an empty block, mined far in advance, only broadcasting time matters for min-difficulty blocks.

If anyone could confirm if testnet4 is down

No, it is up and running. But it was turned into some useless altcoin by traders, and CPU miners, to the point, where everyone uses something else, while waiting for fjahr to release testnet5. Some miners are selling a lot of coins, and there is some trading, but beyond that, most developers actually stopped using testnet4 for anything serious, because they have signet, which they can fully control, or regtest, where they can locally make any chain they want.

[LoyceV]

Well, if you use testnet4, then you can always disconnect from the network, wait 20 minutes, and then mine any block on your CPU. If all you need is testing things, and not trading coins, then that should be sufficient.

Tiny detail: you'll need to wait 2 hours longer because blocks are mined 2 hours into the future already. Or just change your system clock

[BlackHatCoiner]

I never trusted Bitcoin Core's fee estimation, and always picked my fees manually.

One thing that remains a mystery is why Bitcoin Core's fee estimation is so garbage. It's even big mystery than Bitcoin Core not supporting some mnemonic standard for its wallet, and forcing its users store their wallets digitally.

Well, if you use testnet4, then you can always disconnect from the network, wait 20 minutes, and then mine any block on your CPU. If all you need is testing things, and not trading coins, then that should be sufficient.

Tiny detail: you'll need to wait 2 hours longer because blocks are mined 2 hours into the future already. Or just change your system clock

No, you don't have to wait 2 hours, just 20 minutes. The second 20 minutes have passed, a block you mine that is 2 hours into the future becomes valid again.

[LoyceV]

One thing that remains a mystery is why Bitcoin Core's fee estimation is so garbage.

When I look at mempool.space, I expect 0.32 sat/vbyte to be enough to be confirmed within a few blocks. Bitcoin Core tells me I need to just over 1 sat/vbyte for a confirmation within 2 blocks. But if I'd accept 4 hours, the recommendation is still slightly above 1 sat/vbyte. For anything that can take a day up to a week, Bitcoin Core still recommends double 0.32 sat/vbyte.
It's always been terrible indeed.

No, you don't have to wait 2 hours, just 20 minutes. The second 20 minutes have passed, a block you mine that is 2 hours into the future becomes valid again.

That's only if you hack and recompile Bitcoin Core, right?

[TheButterZone]

I just tried testnet4, for the first time of any testnet in my life, because I needed on-demand incoming TX to get an alert for. What I noticed on the side was how long the TXs were staying unconfirmed (well in excess of 20 minutes/the estimated next block time on mempool.space), as I sent everything back to mempool.space's faucet, except the fees that I didn't care about setting correctly.

ETA: Hyperlink to that faucet

[LoyceV]

That feels more complicated than running the existing Bitcoin Core testnet4 with my own fork.

I'll give this a try: Testnet4 LoyceVork ("Vork" is Dutch for "Fork", so it fits nicely)

Update: this doesn't work the way I expected. I have Testnet4 LoyceVork running and mined 14 blocks after rejecting the other blocks:

Code:

~/bitcoin-31.1/bin/bitcoin-cli -rpcuser=LoyceVork -rpcpassword=xxx -rpcport=58332 -testnet4 invalidateblock 000000001fed1a914651afc36574003c5300cac5df738c3976f28d54f7096253 # block 2

That works fine, I can mine blocks. But if I run the same on another node and add the first node:

Code:

~/bitcoin-31.1/bin/bitcoin-cli -rpcuser=LoyceVork -rpcpassword=xxx -rpcport=58332 -testnet4 addnode "38.102.86.40:58333" "onetry" true

It doesn't start downloading the blocks I mind. It sees the block height (16), but doesn't use them. What am I missing here? If this works, I could easily setup my own Testnet with a very small Electrum server, and regular wipes if there's spam.

[BlackHatCoiner]

It's always been terrible indeed.

Yes, and I've never understood why this is the case for the largest Bitcoin project (the Bitcoin project, some would argue). Especially when so many wallets use the Bitcoin Core RPC to estimate fees etc.

Also, the fact that there are so many wallets is due to Core having a terrible internal wallet, but this is another discussion.

That's only if you hack and recompile Bitcoin Core, right?

No, it's consensus rule. No hacks needed.

It doesn't start downloading the blocks I mind. It sees the block height (16), but doesn't use them. What am I missing here?

This is most likely because of the hardcoded minimum chain work: https://github.com/bitcoin/bitcoin/blob/282a05b8d10e317d2ce4b42b96ee8b13345804ea/src/kernel/chainparams.cpp#L380. If your node's chain's work is less than that, other nodes will ignore it.

[LoyceV]

That's only if you hack and recompile Bitcoin Core, right?

No, it's consensus rule. No hacks needed.

Doesn't that only apply to accepting the "future" block, and not to mining it on purpose?

This is most likely because of the hardcoded minimum chain work: https://github.com/bitcoin/bitcoin/blob/282a05b8d10e317d2ce4b42b96ee8b13345804ea/src/kernel/chainparams.cpp#L380. If your node's chain's work is less than that, other nodes will ignore it.

So this is mine:

Code:

0000000000000000000000000000000000000000000000000000001100110011

This is the minimum:

Code:

000000000000000000000000000000000000000000000e346a558455ade8eca9

I can forget about that on a CPU, so I give up on "Testnet4 LoyceVork".

[athanred]

why Bitcoin Core's fee estimation is so garbage

Because nobody cares, and there are so many users of block explorers, that it remained unfixed.

Also, that's why in Open Source, people work on things they need or they like, not necessarily on the things, which are needed by the rest of the community. And because developers don't need it, and users switched to Electrum anyway, there is no pressure to fix it any time soon.

and forcing its users store their wallets digitally

Well, I wrote my WIFs on a piece of paper. And did the same later with descriptors. Because you never know, when your hardware would crash, and it is a good option, to recover things, if something goes wrong.

No, you don't have to wait 2 hours, just 20 minutes.

If you want to disconnect anyway, then it is even simpler: you can invalidate some recent blocks with "invalidateblock", mine something by yourself, and then reconsider these blocks later with "reconsiderblock", when you will want to connect again with the rest of the network.

That's only if you hack and recompile Bitcoin Core, right?

If you recompile the code, then you can easily change 2 hours rule into 20 hours rule. But if you don't, then invalidating some recent blocks is enough, and for that, no recompiling is needed.

What am I missing here?

If you are connected with the rest of the network, then your chain is probably not the strongest one.

If your node's chain's work is less than that, other nodes will ignore it.

Which is why using regtest, or a custom signet is simpler, if you want to build your own chain from scratch.

I can forget about that on a CPU, so I give up on "Testnet4 LoyceVork".

Then use custom signet, if you want CPU mining. Or regtest, if you want paper-and-pencil mining. By the way: your node won't fetch these data by default, however, if you push it manually through "submitblock", then it should work, even if you will try mining on top of mainnet from 2009.

[BlackHatCoiner]

Doesn't that only apply to accepting the "future" block, and not to mining it on purpose?

By mining it "on purpose" do you mean to mine the block, keep it temporarily locally and broadcast it on time since the network will reject it if you send it sooner? Yes, that is not supported by default on Bitcoin Core, you'd have to modify the client and the miner / mining pool software.

Well, I wrote my WIFs on a piece of paper. And did the same later with descriptors. Because you never know, when your hardware would crash, and it is a good option, to recover things, if something goes wrong.

This is a really bad practice, and I don't understand why so many people write down the descriptor text, which is why I'm so against descriptors in the first place. There is a real chance you've messed up your WIFs or descriptors, if you write them down on paper. It's a really big string of text.

[LoyceV]

There is a real chance you've messed up your WIFs or descriptors, if you write them down on paper.

If it's an additional backup, it doesn't increase the risk.

I've always liked "raw" private keys, but I prefer printing them (with BIP38 encryption).

[BlackHatCoiner]

If it's an additional backup, it doesn't increase the risk.

It increases the risk of sleeping easy that your printed QR code encoded descriptor can get destroyed, because "you have a backup".

I've always liked "raw" private keys, but I prefer printing them (with BIP38 encryption).

I've made mistakes when writing down WIF private keys enough times to understand there's a significant risk with humans writing down non-human readable text. Plus, a seed phrase can produce unlimited addresses. A private key is just one address, ugh.

The descriptor is the most scary part of N-of-M multi-sig, in my opinion.

[takuma sato]

If it's an additional backup, it doesn't increase the risk.

It increases the risk of sleeping easy that your printed QR code encoded descriptor can get destroyed, because "you have a backup".

I've always liked "raw" private keys, but I prefer printing them (with BIP38 encryption).

I've made mistakes when writing down WIF private keys enough times to understand there's a significant risk with humans writing down non-human readable text. Plus, a seed phrase can produce unlimited addresses. A private key is just one address, ugh.

The descriptor is the most scary part of N-of-M multi-sig, in my opinion.

Agreed, I also never trusted "seed wallets" beyond spending amounts because im paranoid about the whole concept, mostly for the future when quantum is able to do something actually interesting. Same goes as PSBT, some of the stuff could be used for a derivation attack in theory, so PSBT content files should be encrypted and then decrypted during the transaction, but the file just contains raw text as of now. Legacy wallets are safer in theory since it's all isolated with it's own private key but they give you it's own set of problems since you could screw up during backups, or during running a watch-only wallet etc as you may not own the change address, and they are deprecated in more modern versions of Bitcoin Core anyway.

[LoyceV]

I just checked how testnet4 is doing: the last block that included transactions was 10 hours ago.

Any idea what's with "OP_RETURN 𓊝 ballast 𓊝" that pays 0,50000000 tBTC in fees? There are more of these waiting to get confirmed.

[nc50lc]

Any idea what's with "OP_RETURN 𓊝 ballast 𓊝" that pays 0,50000000 tBTC in fees? There are more of these waiting to get confirmed.

This is a wild guess:
Since those icons are "ships", it must be analogous to a ship's ballast (WiKi) to stabilize testnet network.
Its very high fee could potentially encourage miners to include transactions to their blocks.

If successful, that'll minimize zero txn blocks so confirmations could speed-up back to normal again.

[LoyceV]

Its very high fee could potentially encourage miners to include transactions to their blocks.

It's not working: there's currently 26.541 tBTC waiting to be confirmed. But it can't work: including those transactions would mean the miner is a millisecond slower, which means another miner who doesn't include them wins the race.