For August 2026, there are currently two forks scheduled:
It would be good to discuss what monitoring and data collection would be worthwhile for this. I invite everyone interested in this to participate in the discussion here.
I’ll probably run a fork-observer instance with a Bitcoin Core node and a BIP-110/300 node side by side. I’ll likely also live-stream this in some capacity.
Monitoring for transaction replay across the forks, assuming there are blocks for them, should be interesting as well. Not sure if I’ll get to this.
For the BIP-110 fork, someone might attempt to publish data-embedding transactions into the chain around the fork height or shortly after. Especially on the BIP-110 side. It would be good to have coverage of this, even if it’s not given that this will happen.
Additionally: observe on which side of these forks pools are mining. This can be done with stratum data. On top of that: What side is currently more profitable to mine on given the current fees and price?
At block ~964,000, the Bitcoin blockchain is read. Every address holding BTC at that moment is credited an equal amount of eCash — automatically, with no action required from you.
It might be helpful to some to create a data set that shows whether UTXOs are unique to Bitcoin, i.e., immune to replay on RDTS. Same for eCash, if they don’t have replay protection.
I’ve been thinking about adding a visualization of what-is-being-mined-on to fork-observer using stratum data: Show next block based on stratum jobs by 0xB10C · Pull Request #137 · 0xB10C/fork-observer · GitHub
An idea for an activation live stream would be to show a Core and Knots+BIP110 node on fork-observer and have them both connected to a ckpool instance each, which are then connected to a stratum-observer instance. This would show which blocks the nodes consider active and which block they are mining on. Could also mix in some of the bigger pools like AntPool, F2Pool, ViaBTC, … Maybe Foundry if we can get pool details too.
The same works for the eCash activation.
Seeing this makes me think we are going to see a bunch of inscriptions being broadcast for a potential BIP-110 compliant block right before around/activation: Add BIP-110 compatible envelope parser by lifofifoX · Pull Request #4545 · ordinals/ord · GitHub . Well, there also seems to be policy: count bare data envelopes (OP_2DROP/pushnum runs) as datacarrier by kwsantiago · Pull Request #319 · bitcoinknots/bitcoin · GitHub now…
added a height based countdown feature for halving/soft-forks/special heights to fork-observer: add: per-network height countdown by 0xB10C · Pull Request #142 · 0xB10C/fork-observer · GitHub
Relevant for tracking Ocean, a variety of stratum endpoints:
They updated the activation date to block 963,648, instead of 964,000. Aprox 22/08/2026
Found the node’s repo too:
A bit of an update on the infrastructure I’m going to be putting together for the August forks. The initial focus is BIP-110 but I’m also aiming to cover off the BIP-300 eCash fork too. I feel that it’s necessary for comprehensive and objective monitoring/data capture for both ongoing discourse and future research (and, well, historical preservation generally). As such, the aim is live monitoring and dissemination while the events are underway, plus archive for analysis and research afterwards.
I’ve spun up 3 nodes that exist at different points in the policy spectrum: Bitcoin Knots (with RDTS enforcement enabled), Bitcoin Core and Libre Relay. This diversity gives good coverage of the policy differences (and in the likely event of a split this gives a position on each side). As these are VPS nodes, in the interest of VPS cost, they are pruned (full archival nodes running elsewhere).
Each node runs the same stack: peer-observer capturing all that it does, a getblocktemplate sampler, and a mempool sampler component too. Everything is captured locally (on VPS) and regularly pulled to archive. I will openly publish the archive datasets, probably on the BNOC data share, as soon possible (and as close to original form as possible).
I’m treating a persistent chain split with minority hashrate as the most likely outcome. Everything keeps running through mandatory signalling and activation at 961,632. With Knots on one side and Core and Libre Relay on the other, both sides of the split will get followed and all data collected and archived.
The aforementioned mempool sampler will feed a live visualiser to show mempool diffs. I’m also building a transaction classifier that checks everything the mempools see against the RDTS rules to show in how much of the transaction flow would be rejected under BIP-110, and how that changes around activation, including any last-minute rush of inscriptions as anticipated, etc. Also, what BIP-110 compliant yet likely “spam” is making it onto the BIP-110 side.
Also relevant to the stratum mentions above, I’ve started on stratum job capture against a range of pool endpoints, including OCEAN (and their new BIP-110 signalling endpoints), AntPool, F2Pool, etc. Trial collectors are running now, with the aim of having this solid before the mandatory signalling window. It should show which chain each pool is actually building on through signalling and activation (live visualised), a nice complement to the fork-observer stratum view mentioned earlier.
I’ll be throwing up a public site in the next week or so to consolidate and display all this (live) information and more through the fork events. If there’s any specific additional data you think should be collected or specific visualisations to show, please let me know!
Edit: probably a way to show transaction “splitting” (protection/replay) as @murchandamus suggests too
I started to work on a pilot extractor for the bip300301_enforcer ( GitHub - LayerTwo-Labs/bip300301_enforcer: CUSF software enforcing BIP300 and BIP301 rules. · GitHub ).
The goal is to collect the enforcer’s validated view of the chain.
I’ve quickly vibed together a bit of page to show some of the fork data. Had planned for much more, but focus has been COLDCARD stuff most of the week 
Will add to this for the eCash fork, and then generally use the domain to organise and present the collected data after-the-fact(s).
No bip110 blocks in the stale-blocks repo yet?
As of 2026-08-12T07:00:00Z, the BIP-110 side of the fork as mined three blocks. The first two were added by @ajtowns in add stale blocks at 961324, 961632, 961633 by ajtowns · Pull Request #119 · bitcoin-data/stale-blocks · GitHub and the third is added in Automated: add recent stale block(s) 2026-08-12 by github-actions[bot] · Pull Request #122 · bitcoin-data/stale-blocks · GitHub.
I guess there’s the question as to what point do we continue to add them. If there’s a clear hardfork, then that’s probably a exclusion reason. Let’s see how many more are mined before that happens.
Here’s more information and recordings of the monitoring livestream I did: BIP-110 monitoring stream: mandatory signaling start. I include the following timeline:
The blocks leading up to block 961632 came in fast and the fork happened earlier than anticipated.
19:33 UTC: the last shared block, 961631, was found.
19:36 UTC: the non-BIP-110-signaling block 961632 was found.
20:12 UTC: to the surprise of many, BIP-110 miners found a signaling block 961632. This forked the chain.
20:19 UTC: F2Pool found 961633 on the non-signaling chain.
20:30 UTC: a non-BIP-110-signaling Ocean miner found 961634. The non-signaling chain was two blocks in the lead.
21:49 UTC: the signaling chain found its block 961633. By then, the non-signaling tip had extended to 961638.
Regarding transaction replay: I didn’t look into this, but I aware of others how did. In this post, mononaut shows that most transactions in the two BIP-110 (he writes BIP-100, but I think that’s a mistake) blocks, were first confirmed on the Bitcoin block chain, and then on the chain enforcing the BIP-110 signaling rule (blue). Only a handful of transactions (pink) were first mined on the BIP-110 signaling chain, and then replayed on Bitcoin. There are also a few (green) transactions that were split.
There have also been reports of the BIP-110-signaling-enforcing nodes dropping connections (I’m not sure if inbound or outbound) around mandatory signaling start. I had a brief look at the logs, but didn’t find anything immediately (and then choose to spent time on other things).
However, it seems that there was a slight drop in connections around the time the first BIP-110 signaling block was mined and then a slow, but steady drop in connections starting on 2026-08-10T03:40:00Z until the next block was found.
Some interesting data to check is how the network was slowing splitting during the mandatory signaling; this is because non-bip110 nodes disconnected from bip110 nodes as they saw their peers in an old chain.
I cannot recover logs from the day, but if anyone has logs they should check for something like:
[ConsiderEviction] Outbound peer has old chain, best known block = ... disconnecting peer=
Another way to check this node drop was checking every N seconds your peers tip:
sliv3r@bitcoin:~ $ bitcoin-cli getpeerinfo | grep 961633
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
"synced_headers": 961633,
"synced_blocks": 961633,
sliv3r@bitcoin:~ $ bitcoin-cli getpeerinfo | grep 961632
"synced_headers": 961632,
"synced_blocks": 961632,
sliv3r@bitcoin:/mnt/ssd/bitcoin $ bitcoin-cli getpeerinfo | grep 961632
"synced_headers": 961632,
"synced_blocks": 961632,
sliv3r@bitcoin:/mnt/ssd/bitcoin $ bitcoin-cli getpeerinfo | grep 961632
sliv3r@bitcoin:/mnt/ssd/bitcoin $
At the time of executing the first `getpeerinfo` non-bip110 nodes were one block ahead.
Again I fail to recover more logs, but I was able to find this from a message I shared during the signaling day. If I recall correctly the two last commands were executed with a ~5min difference. And there was another execution before the logs I still have which showed I had more than 2 stale peers (4 IIRC).