Tempnet: 2027 Chipnet Upgrade & Pre-Upgrade Testing

Infrastructure
#1

Hi all, it’s time to start test-upgrading Chipnet for 2027 :rocket:

I’ve set up a tempnet to test CHIP-2025-03 Faster Blocks for Bitcoin Cash with activation set to MTP 1792065600 (2026-10-15T12:00:00.000Z).

I’ll continue spinning up infrastructure for this (or the latest) tempnet and keep it online through November 15, at which point I’ll redirect everything to chipnet .

I’ve set up some nodes and a block explorer at https://tempnet.chaingraph.cash/. I’ll post more detailed instructions here next week on setting up a node and connecting to the network.

Any volunteers to run nodes and mine are appreciated. Please post connection info, links to software patches, links to your projects, and testing-related tips below. Thanks!

12 Likes
CHIP-2025-03 Faster Blocks: gathering statements of support (and dissent)
#2

Great work, thank you for setting this up.

I’m travelling at the moment, but I do want to learn more about how to set up nodes & infrastructure myself so I’ll be looking at this and maybe come back with the ability to contribute.

3 Likes
#3

Thank you for setting this up. I’m very interested because of the potential UX impact on my project

Back in June I had to come up with a workaround, because MTP wasn’t predictable enough for the covenant I’m developing. So I’d like to see exactly where the assumptions break with 1-minute blocks, especially nLocktime / MTP and the “tick” / blockchain-time abstraction in the CHIP. (The tick is honestly the piece that would help us most.)

What are the testing priorities?

I’m happy to contribute. I currently have a Raspberry Pi 5 mining on testnet3, and I can point a miner at the tempnet.

3 Likes
#4

MTP window remains 11 blocks, so it will lag by real time 2-10 minutes instead of 20-100, subject to variance. Time-based locktimes reap full benefits of finer-grained chain progression, I hope this can help you!

Height-based locktime still works in 600-tick units: Writing L for a height-mode nLocktime value and T(b) for the tick of block b inclusive of its own contribution, a transaction is final in block b if T(b) > 600 * L .

2 Likes
#5

I explain myself poorly. The issue I had was me not understanding the trade offs of measuring time with MTP. When I started testing it was obvious that it was the wrong approach. And that doesn’t change with faster blocks. But I still use MTP as a fall back in case the primary source of time fails.

But to be fair with faster blocks is going to be a better fall back.

2 Likes
#6

Successfully synced a node with tempnet. Patches/binaries and some notes here for anyone interested: https://github.com/9500/bchn-tempnet

3 Likes
#7

PSA: orphan rate on tempnet is expected to be artificially higher due to testnets dropping difficulty to 1 if no block has been found in 2x the target time.

When baseline difficulty is low (now it is ~3) the impact of this is low, but this would change if someone were to point an ASIC at it and blow up the baseline difficulty.

At normal difficulty, 13.5% of block intervals are expected to exceed 2x the target time (Poisson distribution), which triggers the drop to difficulty 1 (just ~4.3 GHashes to find a block, matching ~72 MH/s at the 60s target time).
When that happens, the network will find the next block much faster.
How much faster?
It depends on the baseline difficulty.
If dropping from 3 to 1 (as is currently the case on tempnet) then the expected time to find the next block will go down from 60s to 20s.

Combined expected orphan rate is thus:

  • testnet_orphan_rate = 0.865 * orphan_rate(60s) + 0.135 * orphan_rate(60s / baseline_difficulty)

If we expect 1% on 60s mainnet then on tempnet (with baseline difficulty 3) it would grow to about 1.27%.
But if the baseline difficulty were higher, e.g. 1000, then the network would find a block 60ms after the difficulty drop! This is assuming miners are optimized to make use of difficulty=1 as soon as it becomes available.

If they’re not optimized and their getblocktemplate polling straddles the boundary, then the impact will be lessened, as they won’t all start mining at difficulty=1 at the same time, and so the risk of an orphan race will be lower.

PS I ported this CPU miner https://github.com/A60AB5450353F40E/bitcoin_solo_miner

  • git clone https://github.com/A60AB5450353F40E/bitcoin_solo_miner.git,
  • build with cargo build --release and
  • copy the repo’s .env and *.txt files into the binary’s folder, edit as necessary, and then
  • just run ./bch_solo_miner

Notes:

  • Use the Bitcoin legacy address format, because I didn’t bother implementing CashAddress.
  • The BCHN RPC needs to be patched to add target_time to getblocktemplate (the wip2 branch has it now).
  • My miner was broken and was producing lots of orphans due to staleness; it’s fixed now.
2 Likes
#8

Note 1: This theoretical orphan rate is no higher than the calculated orphan rate for testnet 10-mins using the simplified model that BCA is operating from.

Note 2: We don’t see this theoretical orphan rate in practice on testnets because the math used to generate this prediction threw out information from the real world.

Note 3: It’s important that your models do not toss out information from reality inadvertently. Often scientists defend their failed theories with “Well the math checks out”.

This is a false statement. It is not expected to be.

2 Likes
#9

Because criterion is 2x the target time, Poisson process means 14% of blocks will have difficulty=1, no matter the target time, but that doesn’t mean each such block will have a competitor.

We DON’T expect exactly 14% orphans - that’s just the upper bound, and will depend on number of active miners, their hashrates and configurations.

Anyway, I need to resist the urge to go further down this rabbit hole, porting that Rust miner was enough curiosity satisfaction for the day :slight_smile:

1 Like
#10

I didn’t. Now we have a Rust-based testnet miner that uses midstate optimization, pulls 90–100 MH/s with a 6-core Xeon, and is optimized to switch to difficulty=1 as soon as it becomes available.

See my updated post above :slight_smile:

I suspect ASIC miners aren’t optimized to exploit the difficulty=1 drop as soon as it is available. It would be interesting to go further down the rabbit hole and optimize them, then see what happens with testnet’s orphan rates.

#11

Hi all, we are PulseHawk, independent blockchain measurement. We counted Tempnet block headers from activation to 21 Oct 10:00 UTC and want to share the numbers, mostly for the MTP and tick questions above.

Window 15 Oct 12:56 to 21 Oct 09:59 UTC, heights 327,989 to 335,560, 7,572 blocks. Our own headers over P2P, chain and PoW checked, cross checked with two Tempnet peers (500 of 500 hashes equal).

counted expected at 60 s
mean interval 67.07 s 60 s
median interval 43.0 s 41.6 s
p90 / p99 125 s / 232 s 138 s / 276 s
over 5 min 0.38% (29 blocks) 0.67%
block time minus MTP before it, median / p90 / p99 335 / 524 / 765 s 340 / 557 / 786 s
10 blocks, median / p99 568 / 1,229 s one 600 s block 416 / 2,763 s

On MTP (@Rufitnes). A block timestamp sits a median 335 s ahead of the MTP before it, 765 s for 1 block in 100. That matches what 11 blocks at 60 s predict. So with 1 minute blocks MTP trails block time by about 5.6 minutes typically and up to about 13 minutes, and anything that locks on MTP should plan for that spread.

On 10 block windows. Ten 1 minute blocks took a median 568 s with p99 1,229 s, against 416 s and 2,763 s for one 600 s block. Similar median, much smaller spread.

What we cannot judge yet. 3,455 of the 7,572 blocks carry minimum difficulty (all of them on 15 and 17 Oct, 87 on 21 Oct), so difficulty adjustment after hashrate jumps cannot be read cleanly. The longest gap was 20,863 s at height 328,223 on 16 Oct, on a testnet with few miners.

We keep counting and post here every Wednesday until 15 Nov, with a final summary that day. If there is a number you want counted for your tests, ask here.

6 Likes
#12

Hi and welcome, and thanks for the freebie!

independent on-chain counts. we measure fast proof of work chains under load.

TIL such a service exist (https://pulsehawk.io/), it may come in handy (and prices are approachable)!

Interesting measurement on ZCash’s 25s blocks:

In our listener window on 17 October 2026, 14:51 to 20:21 UTC, 5 of 780 announced blocks did not land in the chain, 0.64%, each at depth 1.

1 Like
#13

Welcome to Bitcoin Cash Research! Very cool to see this independent verification. Will you be putting in a statement about the upgrade itself? Are you for/neutral/against 1 minute blocks? https://www.consensus.cash/

It’s the endorsement and lock in window right now so it’s very interesting to get perspectives from people who are just appearing in the community as to their initial impression.

2 Likes
#14

Thanks both, glad it’s useful.

@BitcoinCashPodcast we stay neutral on the CHIP by design, and we won’t sign a statement for or against. Our job is to count what the network does and publish it with the method, so anyone can check it, whatever they think of 1 minute blocks.

@bitcoincashautist thanks for the kind words. With the lock in window open, is there one number you’d find most useful from tempnet before 15 Nov? For example how often a block is announced but does not land in the chain, which we counted on Zcash, or how far MTP trails real time after a fast run of blocks. If it helps your tests, we’ll add it to Wednesday’s count.

4 Likes
#15

I have added tempnet support in my block explorer at https://BlockExplorer.cash and also to the transaction visualiser at https://aquarium.cash

Node stats at https://node.galt.cash

This is not a statement of support or rejection for 1 minute blocks.

3 Likes
#16

Yes, this; generally, the data that does NOT become part of the canonical chain is the most valuable, things like:

  • orphaned blocks
  • node-local receive/accept times (so we can compare vs header timestamps)
  • whether the compact blocks fast relay path was exercised (and info on missing TXs count if not)
  • propagation time from watching INV messages
1 Like
#17

I vibecoded this this evening I hope is useful.

https://github.com/rufitnes/tempnet-data — live dashboard: BCH tempnet · live telemetry

Short version: node-local receive/accept times :heavy_check_mark: · compact relay exercised, with missing-tx counts :heavy_check_mark: (none so far) · reorgs/orphans ✘ (none yet, watching) · INV-level propagation ✘ (not possible with stock logging). Method, definitions and caveats are in the README, and the raw CSV is there if anyone wants to slice it differently.

PulseHawk counts what ends up in the chain; this captures what a node sees on the way there and the parts that never get there. (Our full-range numbers line up with theirs.)

If someone runs the same capture from a different network path, we can compare.

4 Likes
#18

Cool, looks nice! Note that receive_delay is a bit misleading, suggest timestamp_deviation, because a miner can timestamp anywhere in the <MTP, FTL> range (about -5min / +2h tolerance), and they don’t have to update the timestamp after every hash so even if honest – there could be some delay behind real miner’s time.

Re “Why these numbers look odd”:

  1. Flat hash and difficulty Poisson distribution would have average 1 minute but median ~0.693 x 60 = 42s!
  2. Distribution is skewed due to testnet rule which drops difficulty to 1 whenever no block has been found for 2x the target time (2 minutes) - there can’t really be stalls for hours on such testnet unless nobody’s mining or is mining with such low hash that the lowest difficulty block takes some time, or miner is not configured to immediately “exploit” the difficulty drop.
2 Likes
#19

Public Electrum endpoints for tempnet:

tempnet.pub.rapids.cash
TCP 65001 / SSL 65002 / WS 65003 / WSS 65004

(Also available: mainnet, chipnet, testnet3, testnet4)

Uptime not guaranteed, regular short downtime with code updates still expected on all chains.

2 Likes
#20

thanks, that list is exactly what we were after. and thanks to rufitnes for the capture and for checking it against ours, good to see the full range line up.

on the 42 s point, our window from 15 oct to 21 oct came out at a median of 43.0 s against the 41.6 s a flat Poisson process gives. so the median alone looks healthy and the testnet difficulty drop shows up in the tail instead.

for the weekly count on wed 28 oct we are looking at adding a capture from our own P2P client on a separate network path, with first announce times per block and anything announced that never ends up in the chain, using timestamp_deviation as suggested. if it holds up we will post it next to rufitnes’ numbers so the two paths can be compared.

1 Like