An archive of bnoc.xyz · view original topic →
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.
# · 
Mark "Murch" Erhardt · #5 ·
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
# · 
Guille · #12 · · in reply to #11
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?
# · 
b10c · #16 · · in reply to #15
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.
Deadmanoz · 
Anthony Towns · 