Fixing Testnet4: proposal

[LoyceV]

Code:

git clone https://github.com/batmanbytes/bitcoin.git <dir_name>
cd <dir_name>
git fetch --all
git checkout 21caca0d056eef172d052f9babaeb6f4113c78bc
sudo apt-get install build-essential cmake pkgconf python3 libevent-dev libboost-dev libsqlite3-dev -y
cmake -B build
cmake --build build
./build/bin/bitcoind --testnet4

I'm compiling this right now, but had to use -DENABLE_IPC=OFF because of missing "Cap'n Proto" (which I've never heard of before). It looks like it's going to take a few hours compiling on my server.

Let it sync and wait for block 129,024. I will run mine, and if everything is run successful, I will open a new thread and address the mining pools.

So without an ASIC that throws quite some hashrate at it, this chain will just get stuck forever, right?

[BlackHatCoiner]

I will also assist with mining pool & community outreach.

Thanks!

I'm compiling this right now, but had to use -DENABLE_IPC=OFF because of missing "Cap'n Proto" (which I've never heard of before). It looks like it's going to take a few hours compiling on my server.

I did include libcapnp-dev capnproto in the docker post, but forgot to update the previous post. -DENABLE_IPC=OFF is also fine. Yes, compiling without using a flag -j to set the number of concurrent jobs, will take longer, but it will eventually finish. I did not include that flag, because it is memory hungry and not friendly for cheap servers.

So without an ASIC that throws quite some hashrate at it, this chain will just get stuck forever, right?

Right.

[LoyceV]

I
So without an ASIC that throws quite some hashrate at it, this chain will just get stuck forever, right?

Right.

If it stays stuck, would it be an option to just restart from block 0 (without the 20 minute rule)? That way it would be able to get started until an ASIC takes over.

[BlackHatCoiner]

If it stays stuck, would it be an option to just restart from block 0 (without the 20 minute rule)? That way it would be able to get started until an ASIC takes over.

I can think of many good ideas as well, but remember that we're optimizing for code complexity. We don't want to make the code reviewing part difficult.

[LoyceV]

It's syncing! See tmp.loyce.club/testnet4_debug_BlackHatCoiner_edition.log for the latest 10,000 log entries (updated every minute).

[BlackHatCoiner]

The fork is working!

Foundry mined block 129,024 and changed the difficulty bits to 0x19039f05 in: 000000000000000163ae895ba31b802d418d228d552fbfbca85cff85abfb7ea0.

The old chain was then followed by CPU block 129,025 in: 000000000ef7ff58c3464fd777262c5e00652b1b62d572437fce0b2ef5729101.

Our forked nodes did not accept it:

Code:

2026-04-05T08:38:58Z [validation] AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000000000ef7ff58c3464fd777262c5e00652b1b62d572437fce0b2ef5729101, bad-diffbits, incorrect proof of work

We are stuck at block 129,024:

Code:

$ docker exec btc-testnet4 ./build/bin/bitcoin-cli --testnet4 getblockchaininfo
{
  "chain": "testnet4",
  "blocks": 129024,
  "headers": 129024,
  "bestblockhash": "000000000000000163ae895ba31b802d418d228d552fbfbca85cff85abfb7ea0",
  "bits": "19039f05",
  "target": "00000000000000039f0500000000000000000000000000000000000000000000",
  "difficulty": 1186053598.112904,
  "time": 1775381741,
  "mediantime": 1775381139,
  "verificationprogress": 1,
  "initialblockdownload": false,
  "chainwork": "000000000000000000000000000000000000000000000a79e06814b8f5c817aa",
  "size_on_disk": 12951959435,
  "pruned": false,
  "warnings": [
    "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
  ]
}

Code:

$ docker exec btc-testnet4 ./build/bin/bitcoin-cli --testnet4 getblocktemplate '{"rules": ["segwit"]}'
{
  "capabilities": [
    "proposal"
  ],
  "version": 536870912,
  "rules": [
    "csv",
    "!segwit",
    "taproot"
  ],
  "vbavailable": {
  },
  "vbrequired": 0,
  "previousblockhash": "000000000000000163ae895ba31b802d418d228d552fbfbca85cff85abfb7ea0",
  "transactions": [
  ],
  "coinbaseaux": {
  },
  "coinbasevalue": 5000000000,
  "longpollid": "000000000000000163ae895ba31b802d418d228d552fbfbca85cff85abfb7ea01243",
  "target": "00000000000000039f0500000000000000000000000000000000000000000000",
  "mintime": 1775381140,
  "mutable": [
    "time",
    "transactions",
    "prevblock"
  ],
  "noncerange": "00000000ffffffff",
  "sigoplimit": 80000,
  "sizelimit": 4000000,
  "weightlimit": 4000000,
  "curtime": 1775382923,
  "bits": "19039f05", # <- not 1d00ffff, as in the old nodes
  "height": 129025,
  "default_witness_commitment": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9"
}

The next step now is to revert the fork height to 151,200, rebase the code in case there are merge conflicts, and let Foundry, Mara, and other mining pools of testnet4 to run this client instead.

[LoyceV]

The next step now is to revert the fork height to 151,200

Why wait that long?

and let Foundry, Mara, and other mining pools of testnet4 to run this client instead.

I never understood why ASIC owners waste that much hardware on testnet, but while they're at it, they should just switch! Let's say the majority of hashrate switches to your fork: do I understand correctly that even people who don't run your Fork will follow this chain when it's the longest? That would mean all those CPU-miners will keep mining blocks on top of their own chain, only to be forked out again at every ASIC block. If that's correct, then all that's needed is for some ASIC miners to mine at your chain, and "normal" testnet4 users don't even have to run your code to benefit from it.
In this scenario, other ASIC-miners will be forked out if they mine on top of a CPU block.

[BlackHatCoiner]

Why wait that long?

Epoch 75, ~20k blocks, not too long to forget, not too little to not make on time. Sticking with simple numbers.

I never understood why ASIC owners waste that much hardware on testnet, but while they're at it, they should just switch!

I agree!

Let's say the majority of hashrate switches to your fork: do I understand correctly that even people who don't run your Fork will follow this chain when it's the longest?

Correct, it is a softfork. Previously, with the arbitrary difficulty adjustment to 1,000,000 it was a hardfork, and both chains would coexist; nodes running the old client would reject blocks with difficulty 1 million and follow CPU miners' chain. Now, as long as the majority of the hashrate mines my fork, the other chain will be continuously reorged out of existence.

If that's correct, then all that's needed is for some ASIC miners to mine at your chain, and "normal" testnet4 users don't even have to run your code to benefit from it.

Yep. That's why softfork.

[LoyceV]

all that's needed is for some ASIC miners to mine at your chain

Yep.

If they do, they'll get about 6 times more blocks in the long run

Meanwhile at my debug.log:

Code:

2026-04-05T08:16:08Z Saw new header hash=00000000000000037c415f8bad8194aed1c07aacb15a323216bd5b77dafea0d0 height=129019 peer=136
2026-04-05T08:16:09Z UpdateTip: new best=00000000000000037c415f8bad8194aed1c07aacb15a323216bd5b77dafea0d0 height=129019 version=0x3004c000 log2_work=75.388879 tx=14304339 date='2026-04-05T08:25:37Z' progress=1.000000 cache=1910.2MiB(14004057txo)
2026-04-05T08:16:09Z Saw new header hash=0000000006b9f2ac350c3d0a9b10bf69df35775dd4e42b26bbd9830ed68abcda height=129020 peer=27
2026-04-05T08:16:09Z UpdateTip: new best=0000000006b9f2ac350c3d0a9b10bf69df35775dd4e42b26bbd9830ed68abcda height=129020 version=0x2152c000 log2_work=75.388879 tx=14304341 date='2026-04-05T08:45:38Z' progress=1.000000 cache=1910.2MiB(14004059txo)
2026-04-05T08:16:09Z Saw new header hash=000000000cacfcc6ad79919e07bb74149ea6d34247c06ce847bc57cb4b58eaf8 height=129021 peer=9
2026-04-05T08:16:09Z UpdateTip: new best=000000000cacfcc6ad79919e07bb74149ea6d34247c06ce847bc57cb4b58eaf8 height=129021 version=0x21416000 log2_work=75.388879 tx=14304342 date='2026-04-05T09:05:39Z' progress=1.000000 cache=1910.2MiB(14004060txo)
2026-04-05T08:16:09Z Saw new header hash=000000000153874f7be8d1ce83c3548c55105e6e4be4227eee0af23dd63c91f2 height=129022 peer=27
2026-04-05T08:16:09Z UpdateTip: new best=000000000153874f7be8d1ce83c3548c55105e6e4be4227eee0af23dd63c91f2 height=129022 version=0x2062e000 log2_work=75.388879 tx=14304343 date='2026-04-05T09:25:40Z' progress=1.000000 cache=1910.2MiB(14004061txo)
2026-04-05T08:16:09Z Saw new cmpctblock header hash=0000000002df096950967613e32bee0c6c8d39df45bfa59981b8d8c48a05f2df height=129023 peer=18
2026-04-05T08:16:09Z UpdateTip: new best=0000000002df096950967613e32bee0c6c8d39df45bfa59981b8d8c48a05f2df height=129023 version=0x20790000 log2_work=75.388879 tx=14304344 date='2026-04-05T09:45:41Z' progress=1.000000 cache=1910.2MiB(14004062txo)
2026-04-05T08:30:35Z New block-relay-only peer connected: transport: v2, version: 70016, blocks=129023 peer=713
2026-04-05T08:36:16Z Flushed fee estimates to fee_estimates.dat.
2026-04-05T08:37:56Z New block-relay-only peer connected: transport: v2, version: 70016, blocks=129023 peer=722
2026-04-05T08:38:58Z Saw new cmpctblock header hash=000000000000000163ae895ba31b802d418d228d552fbfbca85cff85abfb7ea0 height=129024 peer=8
2026-04-05T08:38:58Z UpdateTip: new best=000000000000000163ae895ba31b802d418d228d552fbfbca85cff85abfb7ea0 height=129024 version=0x2566e000 log2_work=75.389027 tx=14304398 date='2026-04-05T09:35:41Z' progress=1.000000 cache=1910.2MiB(14004117txo)
2026-04-05T08:38:59Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129025 peer=724
2026-04-05T08:38:59Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=725
2026-04-05T08:39:05Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=726
2026-04-05T08:39:18Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=727
2026-04-05T08:39:19Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=728
2026-04-05T08:39:20Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=729
2026-04-05T08:39:21Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=730
2026-04-05T08:39:22Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=731
2026-04-05T08:39:34Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=732
2026-04-05T08:39:35Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=733
2026-04-05T08:40:09Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=735
2026-04-05T08:40:18Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=738
2026-04-05T08:40:26Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=739
2026-04-05T08:40:44Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=740
2026-04-05T08:40:45Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=741
2026-04-05T08:40:45Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=742
2026-04-05T08:40:59Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=743
2026-04-05T08:41:17Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=744
2026-04-05T08:41:18Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=745
2026-04-05T08:41:20Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=746
2026-04-05T08:41:59Z New outbound-full-relay peer connected: transport: v1, version: 70015, blocks=129027 peer=747
2026-04-05T08:45:45Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=751
2026-04-05T08:47:45Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=753
2026-04-05T08:54:34Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=758
2026-04-05T08:55:12Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=760
2026-04-05T08:55:16Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129027 peer=761
2026-04-05T08:57:31Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129028 peer=764
2026-04-05T09:04:40Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129028 peer=770
2026-04-05T09:15:06Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2168 seconds ago)
2026-04-05T09:16:12Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129029 peer=784
2026-04-05T09:16:22Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129029 peer=785
2026-04-05T09:25:36Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2798 seconds ago)
2026-04-05T09:25:40Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129029 peer=791
2026-04-05T09:36:06Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3428 seconds ago)
2026-04-05T09:36:16Z Flushed fee estimates to fee_estimates.dat.
2026-04-05T09:46:36Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4058 seconds ago)
2026-04-05T09:51:13Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129036 peer=815
2026-04-05T09:53:20Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129036 peer=818
2026-04-05T09:57:06Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4688 seconds ago)
2026-04-05T10:04:25Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129037 peer=825
2026-04-05T10:04:41Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129037 peer=826
2026-04-05T10:07:36Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5318 seconds ago)
2026-04-05T10:11:00Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129037 peer=828
2026-04-05T10:18:06Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5948 seconds ago)
2026-04-05T10:28:36Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6578 seconds ago)
2026-04-05T10:32:31Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129038 peer=841
2026-04-05T10:32:48Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129038 peer=842
2026-04-05T10:33:24Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129038 peer=844
2026-04-05T10:35:16Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129038 peer=847
2026-04-05T10:35:43Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129038 peer=849
2026-04-05T10:36:16Z Flushed fee estimates to fee_estimates.dat.
2026-04-05T10:36:52Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129039 peer=852
2026-04-05T10:39:06Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7208 seconds ago)
2026-04-05T10:40:01Z New outbound-full-relay peer connected: transport: v2, version: 70016, blocks=129044 peer=853

[NotATether]

all that's needed is for some ASIC miners to mine at your chain

Yep.

If they do, they'll get about 6 times more blocks in the long run

This shouldn't matter for testnet since the coins are worthless, all that's needed to make this work is some "bedrock" layer of ASICs who will always mine so that block generation does not stall for disproportionate periods of time.

I don't really trust big companies to have the goodwill to always have testnet ASICs running in the event something changes, so maybe it's time to start making BitAxe-style products go mainstream, but for testnet and making the primary functions of these devices something else. e.g. Bitcoin node or even space heater.

[stwenhao]

So without an ASIC that throws quite some hashrate at it, this chain will just get stuck forever, right?

Yes, but the original testnet4 will be stuck without any ASICs too. After 2016 blocks, ASICs are needed anyway in each chain. So, if you will have a lot of hashrate on your side, then the old network can be stuck, while the new one can keep moving forward.

even people who don't run your Fork will follow this chain when it's the longest?

Only if it would be a soft-fork, and not a hard-fork. Which means, that for example all ASICs would need to not use timestamps bigger than 20 minutes away from the previous block. Then, it would be accepted by all clients.

Currently, you can use an ASIC to mine a block, but if the timestamp will be bigger than 20 minutes, then it will be rejected by old nodes, because old consensus rules will force 0x1d00ffff difficulty.

So, if you want to stay compatible, then ASICs should use the real timestamp once per 2016 blocks, and everywhere else, they cannot exceed 20 minutes.

Correct, it is a softfork.

You will see, that it is not, when any ASIC will produce a block with ASIC difficulty, which will be more than 20 minutes away from the previous block.

Because the old testnet creators made a mistake: instead of allowing CPU blocks after 20 minutes, they forced it. Which is why your code is a hard-fork.

[LoyceV]

I don't really trust big companies to have the goodwill to always have testnet ASICs running in the event something changes, so maybe it's time to start making BitAxe-style products go mainstream, but for testnet and making the primary functions of these devices something else. e.g. Bitcoin node or even space heater.

I've done the math on nerdminers, and indeed, it's a space heater
But it's not going to help if some ASIC pushed the difficulty up with 10,000 times more hashrate than the BitAxe.

Currently, you can use an ASIC to mine a block, but if the timestamp will be bigger than 20 minutes, then it will be rejected by old nodes, because old consensus rules will force 0x1d00ffff difficulty.

I did not know that. That indeed messes up the details.

[BlackHatCoiner]

Because the old testnet creators made a mistake: instead of allowing CPU blocks after 20 minutes, they forced it.

The devil is in the details. You had mentioned that on Github, but I completely forgot it. It is a hardfork, right. In order to be a softfork, getblocktemplate needs to return 20 minutes into the future max, otherwise it will be rejected.

So the path is split into two roads, and we must follow one:

• Road A: the fork is configured so that blocks cannot be more than 20 minutes into the future. If a block 100,000 was mined in timestamp X, block 100,001 can be mined with timestamp at most X + 1200. That sounds terrible considering blocks will take 2 hour to be mined at the epoch 75.
• Road B: we leave things as is, we accept it is a hardfork and we use block signaling to see what percentage of miners support it across the next weeks.

Unless anyone has a better idea.

[stwenhao]

You can do both, if you want to.

the fork is configured so that blocks cannot be more than 20 minutes into the future

You can implement it in your client, just to measure the support of your version. Then, by counting ASIC blocks with timestamps not bigger than 20 minutes, you will know, how much hashrate supports it. And blocks with exactly 20 minutes will mean, that it probably took longer, but some ASIC miner decided to put the older timestamp, just to make it compatible with the old rules.

we leave things as is, we accept it is a hardfork

Well, if a lot of blocks will have ASIC difficulty, then your client will be widely supported, and then you can apply a hard-fork. Because now, you don't know, how much hashrate is on your side, and if forking is safe or not.

So, you can make it conditional: if X% of the last blocks support your rules, then hard-fork, according to road B, otherwise stick with road A, and try to reach more support.

[BlackHatCoiner]

The problem with softfork road A is that it noticeably messes with the timestamp. I can implement block signaling to see how many miners pick road A fork, but even with 90% support, at the fork height, the timestamp limit will have to be continuously hit, resulting in a chain that cannot keep up with the present timestamp.

So, the chain will look like this:

Block 151,200: mined at real time 13:00:00, timestamp 13:00:00
Block 151,201: mined at real time 15:01:35, timestamp 13:20:00
Block 151,202: mined at real time 17:13:55, timestamp 13:40:00

This will quickly render the timestamp meaningless.

[stwenhao]

This will quickly render the timestamp meaningless.

No, it will just bring back the real network difficulty, and then, ASICs will be able to find a block faster than in 20 minutes. And after 2016 blocks, ASIC miners can always put the real timestamp, just to calculate the next target properly.

Also, timestamps in testnet4 are currently meaningless anyway, as you constantly have blocks two hours in the future.

I can implement block signaling to see how many miners pick road A fork

Another way is to just signal support, and hard-fork, if a given threshold will be reached. Then, old rules are left unchanged, before the hard-fork. And then, after forking, you can be quite sure, that the hashrate majority is on your side, so the old network will be stuck anyway.

[hmbdofficial]

This will quickly render the timestamp meaningless.
No, it will just bring back the real network difficulty, and then, ASICs will be able to find a block faster than in 20 minutes. And after 2016 blocks, ASIC miners can always put the real timestamp, just to calculate the next target properly.

Also, timestamps in testnet4 are currently meaningless anyway, as you constantly have blocks two hours in the future.

Does that mean If a Bitcoin miner deliberately sets fake timestamps to artificially lower the network difficulty on testnet4, wouldn’t ASICs still be able to solve blocks much faster than the intended 20-minute average? And after mining 2016 blocks with manipulated timestamps, couldn’t the miners simply switch back to using real timestamps to correctly calculate the next difficulty adjustment.

[BlackHatCoiner]

No, it will just bring back the real network difficulty, and then, ASICs will be able to find a block faster than in 20 minutes. And after 2016 blocks, ASIC miners can always put the real timestamp, just to calculate the next target properly.

Let me walk through this.

During epoch 75: Average block time is 1 hour. Timestamp is not up to date, it has remained in the past. We can assume that the timestamp in block 153216 (start of epoch 76) is 2016*20 minutes after 151200. This is 28 days.

This means that if block 151200 is mined with timestamp September 1st 13:00:00, block 153216 will have timestamp September 29nd, 13:00:00, but in real terms, block 153216 will be mined after 2016*60 minutes, or 84 days (November 24nd, 2026). This is 3 months in one epoch, and after this epoch, difficulty will fall by only 50%. So epoch 76 will take ~1.5 months.

It does not look pretty to me.

[stwenhao]

Well, you don't have to wait, to drop the difficulty, or to reorg a chain of CPU blocks. It can be done now, because putting different timestamps in ASIC blocks is backward-compatible.

The only thing, that is hard-fork-ish, is accepting ASIC blocks with timestamps bigger than 20 minutes.

If you modify only the code for mining, then it will be compatible.

Which means, that road A can be done here and now (as long as you limit it just to the mining code), and road B can be activated later automatically, if enough support will be reached.

Because now, you don't know, how much hashrate is behind your version, to go with road B. As you saw on your test with block 129,024, it works. But you have to be sure, that you are on the fork, that is mined by the hashrate majority, otherwise, it would work, but someone would need to produce the blocks.

[LoyceV]

Unless anyone has a better idea.

Road C: complicate your code changes: if more than 20 minutes have passed, miners mine one low-difficulty block. But they don't broadcast it, as that would be ignored by all other miners who run your Fork. The moment they find a real ASIC block, they broadcast both blocks. If more than 40 minutes have passed, they'll mine a new low-difficulty block again that replaces the earlier low-difficulty block (to limit the number of low-difficulty blocks to as few as possible. This should be repeated for any multiple of 20 minutes until a new ASIC block is found.
So you'll need to adjust your code to still accept low-difficulty blocks, but only when there's an ASIC block on top of them already. If I understand stwenhao correctly, this should make it a softfork again.