Tempnet: 2027 Chipnet Upgrade & Pre-Upgrade Testing

bitcoincashautist · October 29, 2026, 11:14am

PSA I did some patches to @9500’s build, ran a private "tempnet’, and then, using a live node, I mined 115 blocks to test some specific cases: verified halvings, ABLA, ASERT, coinbase maturity, locktimes, and sequences all behave correctly across the seam. Also, verified the duplicate coinbase shape rule escapes (locktime or version). Technically, if you patch chainparams to match mine you can turn it into a live network and continue mining. (mainnet params with some overrides: all past upgrades active from block 1, halving interval 21 blocks, and ASERT half-life 3600s).

I’ll release this mini chain soon, and I intend to make it into a unit tests fixture in BCHN.
Notice the 2 big blocks, that’s testing ABLA at the seam and mining exactly at max. for the last 600s block and first 60s block, which tempnet can’t do now.
And I ramped difficulty up enough before activation to test the ASERT seam, too.

N=101 time=2026-10-16 01:16:04 UTC mediantime=2026-10-16 01:13:53 UTC difficulty=8.390489522240577 size=147
N=102 time=2026-10-16 01:16:16 UTC mediantime=2026-10-16 01:15:25 UTC difficulty=9.396351449137374 size=147
N=103 time=2026-10-16 01:17:28 UTC mediantime=2026-10-16 01:15:28 UTC difficulty=10.52396643513509 size=32000000
N=104 time=2026-10-16 01:18:28 UTC mediantime=2026-10-16 01:15:40 UTC difficulty=1.165087379331188 size=3200188
N=105 time=2026-10-16 01:19:28 UTC mediantime=2026-10-16 01:15:52 UTC difficulty=1.165087379331188 size=147
N=106 time=2026-10-16 01:20:28 UTC mediantime=2026-10-16 01:16:04 UTC difficulty=1.165087379331188 size=217
N=107 time=2026-10-16 01:20:40 UTC mediantime=2026-10-16 01:16:16 UTC difficulty=1.165087379331188 size=147
N=108 time=2026-10-16 01:20:52 UTC mediantime=2026-10-16 01:17:28 UTC difficulty=1.175895356348238 size=147
N=109 time=2026-10-16 01:21:04 UTC mediantime=2026-10-16 01:18:28 UTC difficulty=1.186798261499457 size=147
N=110 time=2026-10-16 01:21:16 UTC mediantime=2026-10-16 01:19:28 UTC difficulty=1.197817663401082 size=147
N=111 time=2026-10-16 01:21:28 UTC mediantime=2026-10-16 01:20:28 UTC difficulty=1.208932096146396 size=147
N=112 time=2026-10-16 01:22:28 UTC mediantime=2026-10-16 01:20:40 UTC difficulty=1.220163842859803 size=147
N=113 time=2026-10-16 01:23:28 UTC mediantime=2026-10-16 01:20:52 UTC difficulty=1.220163842859803 size=212
N=114 time=2026-10-16 01:24:28 UTC mediantime=2026-10-16 01:21:04 UTC difficulty=1.220163842859803 size=212
N=115 time=2026-10-16 01:25:28 UTC mediantime=2026-10-16 01:21:16 UTC difficulty=1.220163842859803 size=152

cculianu · October 29, 2026, 8:24pm

Please update your repo – it doesn’t contain the latest code fixes.

Latest code is here: Commits · blocktime/wip2 · Calin Culianu / Bitcoin Cash Node · GitLab

EVERYONE: 9500’s build has bugs in it please have him resynch it from my upstream and release a patched version that is synched to latest. It has p2p network bugs and other assorted nonsense – it’s 15 days old at this point and the code wan’t in great shape back then.

URGENT please have 9500 update this!!!

bitcoincashautist · October 29, 2026, 8:54pm

I applied his patches on top of latest wip2, here: Files · tempnet · ac-0353f40e / Bitcoin Cash Node · GitLab

git clone https://gitlab.com/0353F40E/bitcoin-cash-node.git
cd bitcoin-cash-node
./contrib/tempnet/build.sh

apply config to ~/.bitcoin/bitcoin.conf then just:

cd build/src
./bitcoind

9500 · October 29, 2026, 10:45pm

Repo updated, planned to do it sooner but didn’t get to it. Will try to keep it in sync. Thanks @bitcoincashautist for quick reaction and publishing updated fork.

bitcoincashautist · October 30, 2026, 11:21am

Verified tempnet blocks using CHIP’s implementation of consensus rules:

[ABLA Ticks] Auto-configured epsilonMax: 2837960626724546304, betaMax: 9459868755748488064
seeded schedule from --activation-height=327988
loaded 3913 checkpoint prevouts
loaded 21584 ABLA rows
loaded 21583 header rows
replaying 230137203 bytes from chain_327900.raw, checkpoint height 327899 tick 196739400 tau 600->600
  verified 20 blocks, height 327919 (000000000000163fa5ead574bb7d66512365946c14e12d21c434e5a5b32525ec)
  verified 40 blocks, height 327939 (00000000000012b3eb87341896ade8af956f9e1d6dbce8369cbeefdb17b76dc9)
  verified 60 blocks, height 327959 (0000000000001d7875561c623341f792867750809e50471b2ad7965d11c85032)
  verified 80 blocks, height 327979 (0000000000000025955d6377c459b14cfdf13c38e80759c71d150a64549f7cdc)
H_a confirmed at height 327988 by the CHIP predicate
interval change at height 327989: 600 -> 60 (tick 196792860)
  verified 100 blocks, height 327999 (0000000000d618c0f13bf85a15b57a9ea234d14bc6b997658dc569bbacc7d7cf)

...

  verified 21580 blocks, height 349479 (000000000000740ab2dd68eee07db95e8cd2d2d213322bd9d9543116a1113eba)

=== blockchain_test ===
network:            chipnet
blocks verified:    21583
height range:       327900..349482
tip hash:           00000000000077f75f32327def108bd904adb35eef79ff147b1dac7aa705b283
tip tick:           198082440
transactions:       314784 (non-coinbase 293201)
2027 activation:    height 327988
abla activation:    checkpoint
abla rows compared: 21583
header rows checked:21583
subsidy total:      5596000000000 sats
fees (known):       489305902 sats over 21583 blocks (0 txs with unknown inputs)
work since start:   00000000000000000000000000000000000000000000000005d5ebc973fabc33
timelock checks:    314784 ok, 0 skipped (utxo gap)
warnings:           0
failures:           0
PASS

Details and reproduction: “Full-Chain Replay Verification”

PulseHawk · October 30, 2026, 11:35am

Week two of our tempnet counts, this time with a listener on our own network path. We said Wednesday and this is two days late, sorry for that.

How we count. A listener without its own node keeps connections only to tempnet peers that confirm the fork at block 327,989 and logs every block announcement with its message type (inv, headers, cmpctblock), a peer label such as peer_1 and the arrival time in milliseconds. We then match the announcements by hash against our own header chain, fetched over p2p and checked for linkage and proof of work. For each block we request one cmpctblock from the first announcer and estimate missing transactions from the BIP152 short IDs against the transactions announced to us by inv.

Coverage. The listener ran from 25 Oct 09:15 utc to 28 Oct 07:36 utc in 14 segments, 71.7 h in total. There are two gaps between segments, of 6 min 57 s on 25 Oct from 09:27:47 utc and of 1 min 35 s on 26 Oct from 12:37:49 utc. Each segment held 31 to 47 peers that confirm the fork.

Block intervals, 21 Oct 10:00 utc to 28 Oct 10:00 utc, blocks 335,561 to 345,613

	counted	computed for 60 s
intervals	10,053
mean	60.16 s	60 s
median	45.0 s	41.6 s
p90	132.0 s	138.2 s
p99	212.5 s	276.3 s
share above 5 min	0.02 % (2)	0.67 %
longest gap	334 s, before block 335,881 on 21 Oct 15:45:56 utc	about 588 s
timestamp minus median time past, median / p90 / p99	355 / 518 / 658 s	340 / 557 / 786 s

In the same week 1,364 blocks carry the minimum difficulty.

Listener, blocks 341,252 to 345,470 (4,207 blocks)

We saw every one of the 4,207 chain blocks announced, in the median by 22 peers.

	counted
first seen by inv	4,205
first seen by headers	2
first seen by cmpctblock	0
timestamp_deviation, median / p90 / p99	0.78 / 3.40 / 31.1 s
timestamp_deviation, smallest / largest	0.08 / 196.0 s
propagation_spread, median / p90 / p99	7.6 / 10.8 / 16.7 s
stale blocks after 6 confirmations	16 of 4,223 announced (0.38 %)
cmpctblock received on request	4,204
cmpctblock received unsolicited	0
short IDs per block, median / p90 / largest	5 / 25 / 78
missing transactions (estimate), median / p99 / largest	0 / 1 / 10

timestamp_deviation is first seen minus the header timestamp, the name bitcoincashautist suggested in this thread. It is not a pure propagation value because miners set the timestamp within the rules. Of the 42 blocks above the 99th percentile, 41 carry a header timestamp exactly 120 s after their parent, and none of them carries the minimum difficulty.

propagation_spread is the last minus the first announcement across our peers, for blocks seen from at least two peers. It describes the spread at one listener over 20 to 50 connections, not the propagation time across the network.

A stale block here is a block that was announced to us but is not in the chain 6 blocks later. The full list with height, hash, header time, first seen and number of announcing peers is in the CSV linked below.

Why the compact block numbers are an estimate. We run no mempool. We count the short IDs that match no transaction announced to us by inv. A real node also knows transactions it validated itself, so this approximates what a node would have to request.

Why cmpctblock almost never arrives as an announcement. Under BIP152 a node pushes new blocks as cmpctblock right away to at most three peers that it picks itself as high bandwidth peers, usually the peers that recently delivered blocks first. A listener that never relays blocks is never picked, so every other peer announces by inv or headers and sends the cmpctblock only on request.

Next to rufitnes/tempnet-data. We matched our 4,207 blocks by hash with the public data at commit 787f561 (snapshot 345,617), and all of them are in both sets.

	counted	source rufitnes/tempnet-data
timestamp_deviation, median / p90 / p99	0.78 / 3.4 / 31.1 s	1 / 4 / 33 s
blocks via compact	4,204 (on request)	4,189
missing or requested transactions, median / p99 / largest	0 / 1 / 10	0 / 1 / 10
stale blocks or reorg events	16 stale blocks	0 reorg events

The reorg count and our stale count measure different things. A node logs a reorg only if it had already moved its tip to the block that later lost, and a node that receives the winning block first never logs one. The time columns use whole seconds on his side and milliseconds on ours, and the two clocks are not aligned.

One caveat after cculianu’s note on the 9500 build. Our listener window ends on 28 Oct, before that build was resynced on 29 Oct, so the announcement and stale numbers above come from a network where some peers may still have run the older code. For the count on Wed 4 Nov we will split the week at that change and show both halves side by side, so any p2p effect of the fix becomes visible.

Data, one row per block, is at github.com/neoalphavault-png/kaspa-pulse on branch messung/bch-tempnet, file data/bch/tempnet-woche2-bloecke-2026-10-28.csv. The listener keeps running until the tempnet ends on 15 Nov.

bitcoincashautist · October 30, 2026, 11:43am

Nice, this is latency-dominated and CHIP predicted 0.41% for the 0 missing transactions case

Rufitnes · October 30, 2026, 4:06pm

I have to admit, half of this goes over my head

One thing I can add: the +120 s cluster. In the same window (341,252-345,470)
I found 106 blocks whose header time is exactly 120 s after their parent.
101 of them pay to the same coinbase address
(bchtest:qqat2ay3hqdslmzhm9p8ptyt9tuzxunfnse4n0rqj9), and that address mines
about three quarters of the blocks in the window (116 of 150 in a random
sample). So it looks like one dominant miner’s template/nTime policy rather
than a network-wide effect — which supports exactly the caveat you make:
timestamp_deviation is not propagation.

I’m also adding the accepted-but-not-connected parse, so we can count stale
blocks with the same definition you use.

PulseHawk · October 30, 2026, 5:26pm

thanks both.

@bitcoincashautist good to see the stale share land next to the CHIP number. we counted 0.38 % (16 of 4,223 announced) against the 0.41 % you quote for the zero missing transactions case. that is one week from one listener, so we keep tracking it weekly.

@Rufitnes that is the missing piece, thanks for checking. it fits our side too, 41 of our 42 slowest blocks carry a header time exactly 120 s after their parent. so the long tail in timestamp_deviation looks like one miner’s timestamp policy, not slow propagation. in the week 3 count on wed 4 nov we will show timestamp_deviation twice, once for all blocks and once without the blocks stamped exactly 120 s after their parent, so the propagation part stands on its own.

in short, for anyone skimming. a block reaches our listener from around 22 peers, the first and last announcement are 7.6 s apart in the median, almost no block needs extra transactions fetched, and about 4 in 1,000 announced blocks end up stale.

kzKallisti · November 4, 2026, 6:44am

Hi everyone,

I’ve set up a tempnet node with identical configuration to my chipnet node, so I am also mining tempnet.

I also added tempnet support to Selene Explorer. See here: Bitcoin Cash dashboard · Bitcoin Cash

cculianu · November 5, 2026, 4:20am

Latest implementation is here: Draft: Implement `CHIP-2025-03 Faster Blocks for Bitcoin Cash` (!2184) · Merge requests · Bitcoin Cash Node / Bitcoin Cash Node · GitLab

@9500 if you can update your release to pull in latest code from the above?

9500 · November 5, 2026, 8:40am

Done, same link still valid and points to a new code and release.

PulseHawk · November 5, 2026, 8:45am

@bitcoincashautist @rufitnes Week three of our tempnet counts.

Two windows. Our listener numbers change from 29 Oct 21:00 utc on. At 22:35 utc all our connections to one node dropped in the same second, which looks like a restart, but the change in our numbers starts about 95 min earlier. So every table below has one column before and one after 29 Oct 21:00 utc, and no value is averaged across both.

Block intervals from our own headers

	before, 28 Oct 10:00 utc to 29 Oct 21:00 utc	after, 29 Oct 21:00 utc to 4 Nov 10:00 utc	computed for 60 s
blocks	345,614 to 347,726	347,727 to 356,040
intervals	2,113	8,314
mean	59.62 s	57.59 s	60 s
median	43.0 s	30.0 s	41.6 s
p90	132.0 s	129.0 s	138.2 s
p99	207.0 s	382.9 s	276.3 s
share above 5 min	0.0 % (0)	1.56 % (130)	0.67 %
longest gap	276 s	1,159 s	about 576 s
blocks with minimum difficulty	282	1,513
intervals of exactly 120 s	46	57

Listener on our own network path

	before	after
chain blocks seen	2,113	7,449
peers announcing a block, median	23	16
timestamp_deviation, median / p90 / p99, all blocks	0.80 / 3.34 / 36.3 s	3.19 / 5.29 / 14.1 s
same without blocks exactly 120 s after their parent	0.78 / 3.20 / 5.1 s (without 46)	3.18 / 5.25 / 12.2 s (without 55)
propagation_spread, median / p90	7.8 / 11.0 s	7.2 / 10.3 s
stale blocks after 6 confirmations	4 of 2,117 announced (0.19 %)	398 of 7,847 announced (5.07 %)

A correction to how we showed week two. We gave a timestamp_deviation p99 of 31.1 s. Without the 107 blocks whose header timestamp is exactly 120 s after their parent the p99 is 5.2 s, so that tail came almost entirely from those blocks. Thanks to rufitnes, who showed on 30 Oct that 101 of the 106 such blocks in his window pay to the same coinbase address (source rufitnes). We only count timestamps and do not look at who mined a block.

Stale blocks use the same definition as in week two. A block counts as stale when it was announced to us and is not in the chain 6 blocks later, and the share is stale blocks over chain blocks plus stale blocks.

In the before window 38 blocks reached one of our peers more than 10 min after the first announcement, between 29 Oct 00:21 utc and 29 Oct 00:55 utc. That is why we leave out the p99 of propagation_spread this week.

Of the 398 stale blocks in the after window, 356 fall into three short periods, 216 from 29 Oct 21:00 utc to 29 Oct 23:00 utc with 488 chain blocks per hour, 112 from 2 Nov 22:00 utc to 3 Nov 00:00 utc with 369 chain blocks per hour and 28 from 3 Nov 08:00 utc to 3 Nov 09:00 utc with 254 chain blocks per hour. Across the whole after window the median is 58 chain blocks per hour.

Coverage. The listener covered 148.0 h of the 148.0 h from window start to 3 Nov 13:59 utc, in 28 segments with 35 to 47 peers that confirm the fork at block 327,989. There was no gap between segments. Listener data ends at 3 Nov 13:59 utc, because the segment after it stopped without saving its data, so the last 20 h of the window are missing from the listener tables.

All numbers in the tables are counted by us from our own header chain and our own listener, except the column computed for an ideal 60 s chain. The listener keeps running until the tempnet ends on 15 Nov.

bitcoincashautist · November 5, 2026, 9:27am

We had an ASIC miner come & go, who brought so much hash that blocks sped up to seconds during DAA ramp-up. I’m surprised it resulted in only 5% stale rate and not more. It’s a good sign that no nodes dropped off during such high block frequency.

Charts and hashrate for the experiment courtesy of https://bitcoincashpool.org/