This project started with a very simple problem. While solo mining, I kept checking the screen to see whether anything interesting had happened. Accepted shares are nice to see, but in solo mining there is really one event you are waiting for.
A block.
After finding several solo MicroBitcoin blocks, I realized I needed a better notification system than staring at logs all day. So I started building a small Windows application that watches blockchain activity and alerts me when a new block appears.
I call it BlockWave Radio.
The first version had a very simple job:
Watch the current block height.
Detect a new block.
Play a sound.
Show an alert.
That was enough to make the idea useful, but it also created several technical questions. If an explorer API reports block height 100 and then 101, detecting a new block seems easy.
But what happens when the API times out?
What happens when it returns cached data?
What if the same block is returned several times?
What if two sources temporarily disagree?
How do I make sure the application does not play the same alert more than once?
The application therefore needs to keep track of the last known block height and ideally the block hash as well. It also needs retry logic, duplicate detection, and a way to deal with temporary network failures. Supporting more networks creates another problem because different explorers use different endpoints and response formats. I am also thinking about source redundancy. Using one public explorer is convenient, but if that service goes offline, the application becomes blind. A better version could use a primary explorer, a fallback explorer, and possibly direct node RPC where available. Another feature I am interested in is determining whether a newly discovered block actually matters to the miner I am watching.
A simple notification in the app says:
NEW BLOCK FOUND
A more useful one could eventually say:
NEW BLOCK FOUND
Checking whether it belongs to your miner.
That part is harder because the answer depends on the network, the pool, the available APIs, and what information the mining software exposes.
I should probably clarify something about the projects I often mention. When I say I built an application, that does not mean every experiment is a large or complete product. Many of these are intentionally small tools designed to solve one specific problem or help me understand one part of a technology. Because their scope is narrow, some can be built and tested relatively quickly.
The larger projects are completely different.
I have projects that I have been working on for weeks or months, and some still have unresolved networking, integration, or architecture problems. These smaller applications are often just pieces of a larger learning process. I build something small, test it on a real network, find the weak points, and sometimes reuse what I learned in a larger project later.
BlockWave Radio is one of those small tools.
It started because I wanted to hear when a block appeared instead of constantly watching a mining log.
Now it has me thinking about explorer reliability, multiple data sources, wallet monitoring, block ownership detection, and reorg handling.
That is usually how these experiments grow for me.
One problem leads to another question.
That question becomes another small experiment.
If anyone here has experience with reliable block monitoring, explorer APIs, node RPC, reorg handling, or detecting whether a newly found block belongs to a specific miner or pool worker, I would really like to hear how you approach it.
My goal with these small projects is mostly to understand what is actually happening underneath the interfaces we normally use.
Build something small.
Run it against a real network.
See where it fails.
Improve it.
Comments
No comments yet. Start the conversation.