Funding open-source Bitcoin development is necessary, but it is not sufficient. A grant can give a contributor time to work. It cannot, by itself, transfer years of accumulated context, sharpen technical judgment, expose weak assumptions, or teach someone how to approach a system they do not yet understand.
That requires people working together.
From August 24 to 28, we gathered a small group at Casa21, Vinteum’s hacker house in São Paulo, for a week-long Deep Dive on Bitcoin mining. Deep Dives are technical gatherings where fellows, grantees, researchers, and experienced contributors spend several days studying a part of the Bitcoin stack together.
They are not courses. There is no instructor expected to have all the answers, and there is usually no software to ship by Friday. Instead, we read specifications and source code line by line, reconstruct why systems look the way they do, challenge what we are reading, and follow questions wherever they lead.
The group is intentionally uneven. This time, the room included someone deeply involved with Stratum V2, researchers with broad Bitcoin protocol experience but limited mining specialization, developers already working on mining-related projects, and newer contributors working elsewhere in the Bitcoin stack.
That asymmetry is part of the design.
Someone may understand the history of a protocol but not its implementation. Another may know a codebase intimately while having less context about the system around it. A newcomer may ask the uncomfortable question that everyone else has learned to stop asking.
For five days, the objective is to close some of those gaps together.
The discussions described here were held under the Chatham House Rule. The ideas and observations are therefore presented without attribution.
Why mining?
Mining sits at an unusual intersection of Bitcoin.
It touches consensus, block construction, peer-to-peer networking, pool economics, distributed systems, cryptographic protocols, specialized hardware, firmware, and physical infrastructure. Changes that appear local to one part of that stack can have consequences elsewhere.
It is also an area where Vinteum already supports several contributors working on different layers of the mining stack: Stratum V2,decentralized pool infrastructure through P2Poolv2, open-source mining firmware through Mujina, Bitcoin Core interfaces used by mining software, and network monitoring around phenomena such as block propagation and forks.
If we want to support work in these areas responsibly, understanding isolated repositories is not enough. We need to understand how the different parts of the mining stack fit together, where their assumptions and interfaces meet, and the problems miners, pools, firmware developers, node developers, and protocol designers are actually trying to solve.
So we started at the beginning.
Reconstructing how we got here
We spent much of the first day reconstructing how Bitcoin mining infrastructure evolved.
We went back to getwork, getblocktemplate, BIPs 22 and 23, early CPU and GPU miners, the emergence of pooled mining, and the original Stratum protocol.
Reading old Bitcointalk announcements, archived documentation, and source code from projects such as cpuminer, cgminer, and the original Slush pool was useful precisely because the abstractions that seem natural today had not yet solidified.
One distinction became particularly useful.
getblocktemplate and Stratum are sometimes described as successive approaches to giving miners work, but they operate at different boundaries. getblocktemplate is fundamentally concerned with producing candidate block templates and exposing the information necessary to construct blocks. Stratum evolved around the operational requirements of pooled mining: efficiently distributing jobs, varying work among miners, and accounting for shares.
Understanding the different problems these protocols were designed to solve made later parts of the week easier to reason about. It also reminded us that protocols rarely appear fully formed. They inherit assumptions from the systems that preceded them. Sometimes the quickest way to understand a strange design decision in a current specification is to read a fifteen-year-old forum thread.
Learning the language of Stratum V2
We then spent roughly two days inside the Stratum V2 specifications, occasionally moving into the reference implementation when the prose alone was not enough to understand how a construct was intended to work.
One of the most useful outcomes was not learning any individual message but acquiring a better language for talking about mining systems. Stratum V2 makes explicit a set of objects and roles that are easy to blur together when reasoning about mining: connections carry messages, channels organize mining work, jobs describe work that mining devices can perform, shares demonstrate completed work, and templates carry the information necessary to construct candidate Bitcoin blocks. Around them sit distinct roles: mining devices, mining proxies, pool services, template providers, Job Declaration Clients, and Job Declaration Servers.
As we worked through these abstractions, an analogy kept coming to my mind.
Part of what enabled the personal computer industry to become so diverse was the standardization of interfaces between components. A company did not need to design an entire computer around its own proprietary architecture in order to build a better network card, graphics adapter, storage controller, or sound card. Once sufficiently stable interfaces and buses existed, different companies could specialize in individual components while still building things that interoperated with the rest of the system.
Stratum V2 gave me a glimpse of something similar for Bitcoin mining. By making roles and the interfaces between them explicit, it can provide a kind of glue between specialized components of the mining stack. A developer working on a template provider, proxy, pool service, firmware implementation, or job declaration component can reason about a defined boundary rather than having to understand or reproduce an entire vertically integrated mining system.
That does not mean Stratum V2 has already produced such an ecosystem, or that standardization alone will do so. But it suggests a potentially important consequence of the protocol that goes beyond replacing Stratum V1: it can create boundaries around which different teams can specialize and independently improve parts of the mining infrastructure.
The same decomposition also makes the system easier to reason about. Once roles and boundaries become explicit, we can ask more precise questions: where does a particular responsibility belong? Which components must trust one another? What state crosses a boundary? And which assumptions exist between components even when no protocol message explicitly expresses them?
The last question proved particularly interesting. Stratum V2 gives us a fairly rich language for describing the mechanics of pooled mining, but comparatively little language for describing pool policy itself. That may be perfectly reasonable for the protocol, but it may also leave room for better conceptual tools around it.
One possible research direction that emerged from the discussion is whether Stratum V2 roles and objects could be modeled using techniques from dataflow and concurrent-systems formalizations. Thinking about templates, jobs, tokens, shares, and solutions as objects flowing among actors makes some configurations surprisingly natural to represent this way, and such a model might help make relationships and assumptions between components more explicit.
We do not yet know whether it would prove useful. That is exactly the kind of question a Deep Dive is supposed to produce.
Specifications are part of the security surface
Reading specifications collaboratively also reveals a less glamorous category of problem: prose.
Across the week, we accumulated many places where definitions, relationships, or explanations in the specifications could be made clearer. Some were minor editorial questions. Others required going into source code to infer the intended behavior.
This is not merely documentation work.
For security-sensitive infrastructure, specifications are part of the security surface. They are one of the mechanisms through which assumptions are transferred between independent implementations and across generations of contributors. Ambiguous terminology, unstated invariants, and concepts that exist only in the heads of experienced developers create room for two reasonable implementers to understand the same system differently.
Code review is security work. Testing is security work. Careful specification review should be treated the same way.
Crossing the Bitcoin Core boundary
By the fourth day, we moved toward the boundary between mining infrastructure and Bitcoin Core.
The abstractions we had been studying eventually have to meet a Bitcoin node. A Stratum V2 Template provider, for example, needs to obtain the information required to construct block templates, while mining infrastructure ultimately needs to submit any resulting blocks back to the node for validation and propagation to the Bitcoin network.
We read Bitcoin Core’s mining IPC interface and used a small experimental application to explore how its Cap’n Proto–based interface behaves, particularly its asynchronous execution and pipelining model.
The mining interface is currently the most functional and actively developed of Bitcoin Core’s newer IPC interfaces, which made it interesting to us for another reason. Since last year, we have been discussing with other researchers what a possible monitoring interface for Bitcoin Core could look like: an interface that would expose information about the behavior of a running node to external monitoring and measurement tools without tightly coupling them to Bitcoin Core internals.
Reading the mining interface therefore served two purposes. We wanted to understand how mining software can interact with Bitcoin Core, but we could also examine a concrete, relatively mature example of how Bitcoin Core is defining boundaries for external components.
Questions that look implementation-specific, such as how objects cross the IPC boundary, how asynchronous calls compose, how lifetimes are represented, how interfaces evolve, can become design input for an entirely different interface.
This is one of the things we value about the Deep Dive format: studying one real system closely often gives us better questions for another problem we are already thinking about.
More broadly, interfaces like these are where the abstractions of different projects meet. They often determine whether otherwise elegant protocol designs can actually be composed into reliable systems, making them fertile ground for meaningful engineering and research problems.
Decentralizing the pool
The second part of that day moved to P2Poolv2.
Traditional mining pools provide miners with more predictable income, but typically rely on a pool operator to coordinate work, account for shares, and manage payouts. P2Pool approaches the problem differently: miners coordinate through a separate share chain, enabling pooled accounting without relying on the same centralized pool operator model.
Understanding that design required us to reason about something that looks enough like Bitcoin to be familiar, while being different enough to be dangerous if approached by analogy alone. We traced how shares are represented, how the share chain relates to Bitcoin mining work, and how accounting eventually connects back to payouts.
During that process, the group identified a potentially security-relevant edge case involving malicious miner behavior, denial of service, and possible loss of funds. We are intentionally not describing the details here while the investigation continues.
Whether it ultimately proves to be a vulnerability, an incorrect assumption in our analysis, or simply something that needs better documentation is secondary to the lesson. The point of security review is not to arrive with vulnerabilities already known. It is to create conditions in which assumptions are likely to be challenged.
Eventually, there is silicon
There was one more abstraction layer we wanted to remove. On the last day, we stopped talking about a “mining device” as if it were a black box and opened documentation for the BM13xx family of ASICs.
For several participants, this meant briefly leaving familiar software territory.
We discussed how jobs eventually become work sent to ASIC chips, but also the less glamorous engineering underneath: UART communication, clock generation and distribution, board topology, voltage regulation, power distribution, and the constraints involved in controlling many chips operating simultaneously.
We used open-source documentation produced through community reverse engineering efforts, along with projects including Mujina and Bitaxe, to connect the protocol-level view of mining with actual hardware.
This produced a satisfying full-circle moment.
At the beginning of the week, a miner was an actor receiving a job and returning a share. By the end, that box had exploded into firmware, serial buses, clock domains, power rails, ASIC cores, and finally billions upon billions of SHA-256 computations.
Abstractions are useful engineering building blocks. Knowing when to break them open feels like art.
Research should begin with real systems
Deep Dives are also part of how we think about research at Vinteum. We are interested in theoretical questions, but we do not want our research priorities to emerge only from what appears interesting in isolation.
Working directly with open-source projects exposes another source of questions: things that implementers do not understand well enough, assumptions nobody has tested recently, measurements that do not exist, architectures that have grown difficult to reason about, or designs whose trade-offs are still mostly understood through anecdotal evidence.
Sometimes the right outcome is engineering. Sometimes it is an experiment. Sometimes a question should become a research project. And sometimes a week of investigation should conclude that an initially interesting idea is not worth pursuing.
All four are valuable outcomes.
This is also why developing contributors cannot be reduced to teaching them how to produce pull requests. A mature open-source developer needs to learn how to enter an unfamiliar system, reconstruct its assumptions, distinguish an implementation detail from a protocol invariant, recognize when evidence is weak, ask maintainers useful questions, and eventually decide which problems are worth spending months of their life solving.
Those abilities are difficult to measure on GitHub alone, but much easier to recognize after spending a week around the same table.
Bitcoin has no security department. Its resilience depends on a distributed community of people capable of seriously examining different parts of the system: consensus code, libraries, protocols, hardware, infrastructure, specifications, and the boundaries connecting them. No organization can cover that entire surface, but organizations that support open-source development can help increase the number of people who can.
A week like this often ends with more questions than it began with. That is not a failure of the format. It may be the clearest indication that it worked.
Five days at Casa21
There are outputs from a Deep Dive that will eventually be visible: specification improvements, research questions, experiments, issues, code, and perhaps security findings.
But some of the most important outputs are harder to publish.
They are the moment when a developer working on firmware finally understands why a protocol abstraction exists. The researcher who discovers that their mental model of pooled mining was incomplete. The newcomer who learns enough during the week to participate meaningfully in a discussion that would have been unintelligible on Monday. The question asked over lunch that sends everyone back to the specification afterward.
That is why we keep these gatherings small, technical, and in person.
Casa21 exists partly to make this possible: to create a place where people working on different parts of Bitcoin can spend enough uninterrupted time together for understanding to compound.
So, what happens when you put Bitcoin developers with very different backgrounds in the same room for a week and refuse to stop at the first plausible explanation?
You leave with better mental models, better questions, a few assumptions that no longer look as solid as they did on Monday, and a clearer sense of where more engineering, research, and scrutiny are needed.
There is plenty left to figure out.
That is precisely why we do this.