Fixing Testnet4: proposal

[LoyceV]

Testnet should kind of suck due to the nature of potential Tests and fuckery going on.  Having to jump through hoops and learn which fork is supported by which service, or blah blah blah, is an important part of the learning experience.

jumping through hoops is annoying when testing something. Instead of being able to quickly start the actual testing, I first had to scrape for testnet coins on different networks.
You're right on the learning experience, but that wasn't my goal.

[BlackHatCoiner]

Just go with the hard fork... I see little to no reason to be scared of it and it fixes what needs to be fixed.

I would obviously rather just go with the hardfork, but I can't think of how we can coordinate this with the least disruption. Imagine that 75% of the hashrate votes for this hardfork, and we have Mara and Foundry mining our chain, starting from September 1st: what happens with the rest of the testnet users?

Anyone downloading Bitcoin Core up to v30 will have access to the old client, with a chain that might still have some hashrate (~25%) and thus, still lives. How do we convince them to migrate? This is why I like the idea of the softfork. Nobody has to update anything; only miners.

[LoyceV]

Imagine that 75% of the hashrate votes for this hardfork, and we have Mara and Foundry mining our chain, starting from September 1st: what happens with the rest of the testnet users?

To answer the obvious: the other testnet users will be left behind on the other chain.

Anyone downloading Bitcoin Core up to v30 will have access to the old client, with a chain that might still have some hashrate (~25%) and thus, still lives.

Just like the old testnet (3) still lives I wasn't around when testnet2 was abandoned, but I assume Bitcoin Core back then used "-testnet" to start in testnet mode, and that same startup option now points to testnet 3. But for testnet4, they introduced a new startup option "-testnet4". So even after upgrading, people who didn't change their startup options still use the old testnet.

How do we convince them to migrate?

We don't But if they pay attention and notice an improved version of testnet that doesn't have 5 hours of empty blocks all the time, they may want to upgrade.

[stwenhao]

what happens with the rest of the testnet users?

If they will have enough ASICs, then their network difficulty will just gradually drop. If not, then they will be stuck.

How do we convince them to migrate?

That's why soft-forks and no-forks are easier to deploy. For example, fjahr's version is a no-fork, but it just doesn't have enough support. But if it would have for example 75% support, then the network difficulty would drop. Also, if ASICs would make blocks faster than in 20 minutes, then there would be no CPU blocks anyway.

Just go with the hard fork... I see little to no reason to be scared of it and it fixes what needs to be fixed.

Yes. The problem with hard forks is not technical: it is social. If you want to just hard-fork unconditionally, then the code for that is already written by BlackHatCoiner, and you can just use it. But, as you can see, people are just afraid of landing in the minority chain, or they are worried, that users of the old version wouldn't upgrade.

But if they pay attention and notice an improved version of testnet that doesn't have 5 hours of empty blocks all the time, they may want to upgrade.

Yes. If people will accept 150k "premine", then they will upgrade. But anyway, no testnet was "honestly" launched, so maybe nobody would care. The current testnet4 had 40k "premine", and people use it, so maybe 150k wouldn't be much worse than that.

[LoyceV]

no testnet was "honestly" launched

I don't think that's a necessity. Who needs a lot of coins to test things?
Even I'm still loaded on testnet4 coins from CPU mining almost 2 years ago. I barely see requests for them, and they're in a VM on my old laptop, so all I can think of is expanding this project:

The QR-codes I created are for testnet4 (and all addresses on the first page have 1 testnet coin each).
PDF: loyce.club/other/print_two-sided.pdf (anyone who needs testnet4 coins: take some, but leave some for someone else)
Address list: loyce.club/other/addresses.txt (note: the last 200 addresses are not in the PDF, and the keys are lost)

There are currently still 13 testnet4 coins inside that PDF. I was disappointed when someone took almost all of them at once. Before that, it was used honorably for several months. And that's the problem of adding value: someone will want all of it.

Off-topic: should I fund pages 3,5,...,11 on the above PDF too? I didn't keep the private keys, only the QR-codes, but I do have the address list as watch-only in Electrum to keep track of balances.

[hmbdofficial]

How do we convince them to migrate?
That's why soft-forks and no-forks are easier to deploy. For example, fjahr's version is a no-fork, but it just doesn't have enough support. But if it would have for example 75% support, then the network difficulty would drop. Also, if ASICs would make blocks faster than in 20 minutes, then there would be no CPU blocks anyway.

Let say for example if a no- folk proposal like fjahr’s version later gain strong support let say maybe like (75% plus of hash rate power), how then exactly will the migration happen in practice? Would the miners just voluntarily switch? Or could it be that the drop in difficulty time and faster block times automatically pushes the network towards the new rule without needing the hard folk?

[BlackHatCoiner]

A summary of the roads we can take:

Solution	Type	How it works	Pros	Cons
Road A	Hard fork	At block 151,200, difficulty can no longer drop to min-diff. Epoch 75 averages 60 min/block; epoch 76 drops ~75% to ~15 min/block; then stabilizes at 10 min.	- Simplest solution theoretically - Simplest in code - Best chance of being merged in Bitcoin Core - Mimics mainnet behavior	- Epoch 75 still slow (60 min/block) - Takes an extra epoch to stabilize at 10 min
Road B	Hard fork	At block 151,200, fix difficulty for that epoch so blocks are mined every 10 minutes immediately and disable min-diff.	- Simple to understand theoretically - Returns to 10 min/block immediately - Mimics mainnet behavior	- More complex code change - Lower chance of being merged in Bitcoin Core
Road C	Soft fork	At block 151,200, invalidate any block whose timestamp is more than 20 minutes after the previous block.	- Very easy code change - Soft fork (backwards compatible)	- Complex to understand theoretically - Does not fully mimic mainnet (defeats testnet purpose) - Takes a long time to return to 10 min/block interval

[BayAreaCoins]

Just go with the hard fork... I see little to no reason to be scared of it and it fixes what needs to be fixed.

I would obviously rather just go with the hardfork, but I can't think of how we can coordinate this with the least disruption. Imagine that 75% of the hashrate votes for this hardfork, and we have Mara and Foundry mining our chain, starting from September 1st: what happens with the rest of the testnet users?

Anyone downloading Bitcoin Core up to v30 will have access to the old client, with a chain that might still have some hashrate (~25%) and thus, still lives. How do we convince them to migrate? This is why I like the idea of the softfork. Nobody has to update anything; only miners.

We don't have to convince anyone.  They either play ball or their information is all wrong, and people (users) are pissed.

This is extremely simple... the services that support the hardfork have weight in the network beyond mining power.

Such as the exchange.  If people want to trade Testnet4 then they will be on the right side of the fork... the market will meet the group's needs.

Example:  If mempool doesn't fix their explorer, then people won't trust or use their service.  Someone else will want the free web traffic.  This will work like this throughout.

Right now, I'd say everyone that matters... mining syndicates, small mining pools, solo miners, users, developers, faucets funded, the exchange, and others are all very supportive of just a flat-out hard fork.  The ones that have a problem are just emotional or likely have no skin in the game or long since gave up because of these problems... they likely will come back online when we (the active users) push this all together. *cough* stwenhao *cough* (and who cares if he doesn't tbh )

It is possible and potentially likely that if even one person doesn't like the hard fork and puts their money where their mouth is.  Calculating cost in these things are difficult because resources can be poured with the purpose of being burned to prove a point or whatever.  That's 100% ok IMO.  (not very fun on the wrong side, but that's life too)


No one will remember this hard fork in hindsight, and it won't be visible for users on the current versions or when using third parties.

Testnet is a good place to do this and it is actually needed... this isn't a theoretical issue for people, it's a real-life problem, and everyone here wants to fix it.

[BlackHatCoiner]

No one will remember this hard fork in hindsight, and it won't be visible for users on the current versions or when using third parties.

So how do you suggest new people will figure this out? It would be easy peasy if Bitcoin Core merged it, and anyone downloading v31 with --testnet4 was landed on the hardforked chain, but what if they just never care to merge it?

We don't have to convince anyone.  They either play ball or their information is all wrong, and people (users) are pissed.

Their information is not "all wrong". The other chain will continue existing, normally. Users of the old chain won't be pissed or interrupted. They will receive more empty blocks because of the hashrate migration, but even with just a little bit hashrate, they can get their transactions confirmed once in a while.

I don't think we have any other option, though. The softfork road is just complicated and will probably not receive enough support from the miners and Bitcoin Core. At least the hardfork is brutally fixing everything.

[BayAreaCoins]

No one will remember this hard fork in hindsight, and it won't be visible for users on the current versions or when using third parties.

So how do you suggest new people will figure this out? It would be easy peasy if Bitcoin Core merged it, and anyone downloading v31 with --testnet4 was landed on the hardforked chain, but what if they just never care to merge it?

We don't have to convince anyone.  They either play ball or their information is all wrong, and people (users) are pissed.

Their information is not "all wrong". The other chain will continue existing, normally. Users of the old chain won't be pissed or interrupted. They will receive more empty blocks because of the hashrate migration, but even with just a little bit hashrate, they can get their transactions confirmed once in a while.

I don't think we have any other option, though. The softfork road is just complicated and will probably not receive enough support from the miners and Bitcoin Core. At least the hardfork is brutally fixing everything.

People might find out the hard way...

When they send their 10,000 daily worthless faucet sends into the void... You will see pissed users.

When someone sends $2 worth of DOGE worth of Testnet into the void and this explorer sees it, but that one doesn't... you'll see Tweets or whatever it is called these days.

It'll hopefully do some of that "learning without concent" stuff on how to use RBF. (Doubtful, but a fella can hope)

I do see a few options, but I'd rather not give the option to fix an obvious problem... Example: Offer the old chain market with this "proper" chain or Bitcoin.  Then don't credit screw-ups.  Kinda sucks, but it's learning in the real world. (I'd also personally not want to custer fuck my life with forks of Testnet. )

However, let me talk to some people smarter than me and get back with you.  I think there is more to it than they just keep spinning.


Regardless, I think the focus should be on "What is right?" than "What could go wrong with humans we don't control?".  Put the code in place and let the humans sort it out.  We can't control what others care about, but there is an option for us to try and help something we do care about. (maybe lol)

Just go with the hard fork... I see little to no reason to be scared of it and it fixes what needs to be fixed.

The problem with hard forks is not technical: it is social.

"Problem" <3



I'm sure there are other future potentials, but... I think it'd be pretty silly for Core to stay on the old broken shit if we do the heavy lifting for them OR they launch Testnet5 fresh with your work and we are off to the fucking races again! *shrugs*. A fix is a fix IMO.

I'd bet they follow. (I suspect a few of them use the exchange... regardless I think it's the "right" thing to do.)

[stwenhao]

but what if they just never care to merge it?

Then, you will have your own, working testnet, while other people will still use the broken one. Just like fjahr and some other developers used testnet4 for around 40k blocks, while everyone else used testnet3. And guess what: many people still use testnet3, and they are not going to switch to testnet4, testnet5, or anything else.

Also, Bitcoin Core developers can simply use what they currently use, and don't care about testnet4. As you probably heard, they started testing slow blocks. And where are they tested? Of course on signet. Why there? Because it is not traded, because it is easier to control, and because if someone will try to build some kind of market there, then the creators could easily destroy it, because they can fully control new blocks.

So how do you suggest new people will figure this out?

Well, now you just need to reach enough support for your version, and that's all. As you saw in practice, your code works. If you will have enough ASICs on your side, then you can activate it, and it will be usable. Or: as it was in your test, you can activate it unconditionally, but then, it may be stuck, if other ASICs won't apply your changes.

Which means, that if the code is ready, then just ask mining pools. Just go further, and if you succeed, then it will be fixed.

I think it'd be pretty silly for Core to stay on the old broken shit

When Proof of Work faucets in signet succeeded, then it became unnecessary to fix testnet4 (also because if it is traded, then some people no longer want to test things there). Releasing testnet5 with 10.5 million premined coins wouldn't stop it from being traded, so it was rejected. But so far, no exchange wanted to list signet coins, which is why they can be safely used for current testing, for example related to slow blocks.

And then, if signet is good for testing, then why should they test things on coins, that are traded for real BTCs? If someone will successfully fix testnet4, then it will be fixed. But if not, then it will simply stay, as it is, and will be replaced by testnet5 after some months or years, with a completely new chain, when some developer will need it.

[stwenhao]

how then exactly will the migration happen in practice?

If min-difficulty blocks will be always followed with ASIC blocks, which will have later timestamps, then the network difficulty will start decreasing. Which will mean, that there will be less and less CPU blocks. And then, if on average, ASIC blocks will be mined once per 10 minutes, then CPU blocks will be rare. And then, if the majority will enforce fjahr's version, then mining blocks with min-difficulty with future timestamps will technically be possible, but all of them will be reorged later.

Would the miners just voluntarily switch?

It's not a technical problem, but a social one. If coins are worthless, then people have an incentive to switch, because fixing the network alone is worth it, and losing thousands of potential tBTCs is meaningless. But if coins are traded, then switching means earning less coins, because exploiting the rules will no longer be possible. And then, if miners can get a lot of test coins, and trade them for real BTCs, then why they should be interested in fixing the network for everyone else? For them, it works, because they can produce a lot of blocks, and they are confirmed, so they have no incentive to fix the situation, and lose the edge, that they have over everyone else.

Or could it be that the drop in difficulty time and faster block times automatically pushes the network towards the new rule without needing the hard folk?

Something like that. Basically, if the hashrate majority will keep reorging min-difficulty blocks, then there will be 2016 ASIC blocks per difficulty adjustment. And then, the difficulty will self-adjust properly.

Technically, in that kind of no-fork, some CPU blocks could still appear for a while. But if ASICs will reorg them later, then there will be no incentive to make them, other than for example testing, if some non-standard transaction is valid or not.

Also, it wouldn't matter, that CPU blocks are there, if ASIC blocks would push timestamps to the future. Because the main problem is related to the fact, that first, you have blocks from the future, and then, ASICs use the current time, which pushes the network back in time, and allows making even more CPU blocks. Which then pushes the difficulty upwards, and finally, you have a network, where most blocks have minimal difficulty.

[BlackHatCoiner]

I think where we all agree is to go with the standard hardfork road. It's simple in the code, it's brute and everyone can understand it. It's already implemented in my version, but what is left is block signaling, so we can see in the next weeks, and until the end of summer, how much support there is from the hashrate.

@stwenhao, do you think I should rebase my code to be up-to-date with the latest merged change from Bitcoin Core, or leave it as is? I'm thinking that constantly rebasing it is just time consuming.

[LoyceV]

what is left is block signaling, so we can see in the next weeks, and until the end of summer, how much support there is from the hashrate.

A quick look at the latest ~8 hours of blocks shows that only MARA Pool and Foundry USA create "ASIC blocks" (I've only looked at blocks with many zeros on mempool.space for this). If that's the case, all the block signaling will depend on just those 2 pools and the rare solo miner is insignificant. So can't this whole block signaling thing be dealt with by email as a much more direct approach?

[stwenhao]

do you think I should rebase my code to be up-to-date with the latest merged change from Bitcoin Core, or leave it as is?

Yes, you can rebase it.

I'm thinking that constantly rebasing it is just time consuming.

It can be automated. As far as I remember, it is something like that:

Code:

git checkout your_branch
git rebase -i HEAD~number_of_commits
#grab your commits
git checkout master
git pull
git branch -D your_branch
git checkout -b your_branch
git rebase -i HEAD~0
#put your commits
git push

If your code is left unchanged, then the same steps are repeated over and over again. Which means, that it should be possible to write some tool, which will do that automatically. Usually, I used simple bash scripts for that kind of things, and put commands like that into "rebase_to_master.sh", or something similar. In most cases, the only changed thing was the number of my commits (which can be also counted automatically), and everything else was identical.

Yes, I know it is time-consuming, but you will need it anyway, because you want to be sure, that new changes didn't break any of your code, or vice versa. And because your changes will land on top of the current code.

So can't this whole block signaling thing be dealt with by email as a much more direct approach?

Of course it can be done like that. It is all about not landing on a minority chain. If there are just two big pools, then it simplifies everything.

Maybe also block explorers like mempool.space could be contacted. If they will show your chain, instead of the old one, then it would definitely help. By the way: other block explorers probably still display testnet3 anyway, and they don't care about future testnets.

[BayAreaCoins]

so they have no incentive to fix the situation, and lose the edge, that they have over everyone else.

If anyone would lose the edge due to this fork, it would be my associates and I.

Yet here I am.  This fix is insentive for losers like you who aren't good enough to mine any Testnet blocks period when we are busy vacuuming up pocket change... you should be a little more thankful.

Stwenhao is trash btw, you should avoid 95% of his ideas or what he thinks because he is wrong and never actually brings anything to the table. (also a sockpuppet Testnet trader rofl, fucking loser)


Tons of over complicated shit that only works in his imagination.  Please be very careful with him.  He is not a friend of the cause by any means.

Also Stwenhao, they use Signet cause they are so trash they can't use Testnet... not a very impressive flex.

If you need a real developer to talk to, please let me know and I'll ask someone real and big if they would chat with you.

Feels not needed though.


I glanced at the Github updates today, looks better, I'll read more indepth when I get home later.

Good job dude.  Keep that loser Saint Noodleeater out of your head, he isn't dumb, but his ideas in reality are laughable. <3. (Not once have I ever seen *anything* of substance from him either, all talk.  This CPU block thing could be "fixed" today with reorgs, but ya, nothing of substance from that user besides him dumping some premined Testnet4 coins on my exchange, quitting mining, and then lobbying for Testnet5!!! (lol)

[BlackHatCoiner]

The testnet4-fix branch is now rebased with bitcoin/bitcoin:master. It was simpler than I thought:

Code:

# git branch shows "testnet4-fix"
git fetch upstream
git rebase upstream/master

If that's the case, all the block signaling will depend on just those 2 pools and the rare solo miner is insignificant. So can't this whole block signaling thing be dealt with by email as a much more direct approach?

Yes, I think a direct mail before any block signal, if it even happens, is definitely a good idea. Mara, Foundry and wiz (the person behind mempool.space who is also a testnet miner). Maybe I also make a page "Testnet4 Fix" to make this whole process easier.

[hmbdofficial]

so they have no incentive to fix the situation, and lose the edge, that they have over everyone else.

If anyone would lose the edge due to this fork, it would be my associates and I.

Yet here I am.  This fix is insentive for losers like you who aren't good enough to mine any Testnet blocks period when we are busy vacuuming up pocket change... you should be a little more thankful.

Stwenhao is trash btw, you should avoid 95% of his ideas or what he thinks because he is wrong and never actually brings anything to the table. (also a sockpuppet Testnet trader rofl, fucking loser)

Tons of over complicated shit that only works in his imagination.  Please be very careful with him.  He is not a friend of the cause by anymeans.

Also Stwenhao, they use Signet cause they are so trash they can't use Testnet... not a very impressive flex.

This kind of claim coming from user with 4 Negative feedback, believe him at your own risk.

[BayAreaCoins]

so they have no incentive to fix the situation, and lose the edge, that they have over everyone else.

If anyone would lose the edge due to this fork, it would be my associates and I.

Yet here I am.  This fix is insentive for losers like you who aren't good enough to mine any Testnet blocks period when we are busy vacuuming up pocket change... you should be a little more thankful.

Stwenhao is trash btw, you should avoid 95% of his ideas or what he thinks because he is wrong and never actually brings anything to the table. (also a sockpuppet Testnet trader rofl, fucking loser)

Tons of over complicated shit that only works in his imagination.  Please be very careful with him.  He is not a friend of the cause by anymeans.

Also Stwenhao, they use Signet cause they are so trash they can't use Testnet... not a very impressive flex.

This kind of claim coming from user with 4 Negative feedback, believe him at your own risk.

Look at my feedback, then look at Testnet blocks, and then make your own assumptions.

No need to trust me either.  Take a look at the blockchain and see who is really moving coins and using the Testnet network at scale.

https://mempool.space/testnet/address/tb1qm6juaswhsmdl4w4ezj7lqx5c6xdz7ct99weumg. (650,000,000 Testnet3 received and the page is so big Mempool can't handle loading the page likely for most folks). This is one of our addresses.

https://mempool.space/testnet4/address/tb1qf6yq8r42p3dpmpn7nxexhm628uduj7spm0skmc -  450,000 Testnet coins moved today.  This too is one of our addresses.

This is the big empty block miner (which is not me): https://mempool.space/testnet4/address/tb1qr8xjkrx46yfsch7q2ts2g007haufq48n9pe6qc "Coinbase (Newly Generated Coins) J
i_'i  ckpool"/buy tBTC at https://altquick.com/"

Even the coins that StWenhao uses for his puzzle in his signature came from my service... which is hilarious.  If StWenhao wants to play testnet, he will follow the hard fork too.

*shrugs*


I do big grown-up Testnet business and testing... all the Bitcointalk negative feedback is from people who don't trade with me or butthurt over various things.  Nothing that actually has to do with trust or bad business.

If you do *anything* worth while on Bitcointalk, you will get negative feedback from some weirdo out there.

See look, now you have negative feedback!!! (I'll remove it haha)

Also, I have way more than 4 negative feedbacks if you click on my trust... I've been here for a very long time. (before this username) Regardless, many people I do business with or for would prefer to stay out of the limelight of giving us any credit for success.  I've paid out wellover $250,000 in Bitcoin to whom I strongly suspect are or were Bitcoin developers who trade Testnet.

Many of these coins sat dormate since 2012 and a "small" amount of coinage helped put those Testnet coins into circulation after ~13 years of worthlessly sitting.  Here is an example so you don't have to trust that crazy claim:  https://mempool.space/testnet/tx/54f917a658c25bd022c87461c877b43511a7a9e012a0c2e6ef95da9aa34d4204

If you don't know, now you know.