Bitcoin Four-Constituency Threat Model
Map your security responsibilities by identifying which of four Bitcoin stakeholder roles you occupy.
The Bitcoin network's security depends on four distinct constituencies each playing a different role in establishing and defending consensus. Holders set price signals and economic incentives; node runners enforce and defend the protocol rules; miners find blocks and maintain chain continuity; developers propose and implement changes to node software. Each group faces different attack vectors—holders face theft and custodial risk, node runners face software vulnerabilities and spam-driven bloat, miners face physical and economic attacks, developers face social engineering and governance capture. By first identifying your primary constituency, you can apply targeted defenses rather than unfocused generic advice.
- Your role in the Bitcoin network determines your specific attack surface.
- Each constituency has different leverage over consensus and different responsibilities to the network.
- Generic security advice misses role-specific vulnerabilities that bad actors actively exploit.
- Understanding cross-constituency dependencies reveals systemic risks invisible from a single vantage point.
- Every constituency can always take at least one concrete action to improve Bitcoin's overall security.
- Identify your primary constituencyDetermine which of the four groups best describes your primary relationship to Bitcoin: Holder (buying, selling, storing BTC), Node Runner (validating transactions and enforcing consensus rules), Miner (producing blocks), or Developer (contributing to node or protocol software). Most people occupy more than one; pick the one with the largest exposure or responsibility.Pro tipYou can belong to multiple constituencies simultaneously. Prioritize the role where a failure would have the greatest financial or network impact.
- Map the specific attack surface for your roleEach constituency faces different threats. Holders: custodial risk, phishing, key theft. Node runners: software vulnerabilities, UTXO bloat, spam-driven availability degradation. Miners: physical security, pool centralization, firmware attacks. Developers: social engineering, supply-chain attacks on software dependencies, governance capture.Pro tipCross-reference your threat map with publicly disclosed CVEs relevant to Bitcoin software if you run a node or contribute code.WarningDo not import threat models from adjacent roles. A developer's primary risks are not the same as a holder's, and conflating them leads to misallocated security effort.
- Apply the CIA Triad to your constituency-specific threatsFor each threat you identified, classify it as a Confidentiality, Integrity, or Availability risk. This cross-application lets you prioritize: for node runners and miners, Availability is paramount; for holders, Confidentiality of seed phrases is often the critical pillar.
- Implement targeted defenses for your roleExecute the highest-leverage security action for your constituency: holders should move to self-custody hardware wallets; node runners should run the latest verified Bitcoin Core with a monitored mempool; miners should secure physical infrastructure and use multiple pools; developers should enforce strict code-review and supply-chain verification processes.Pro tipStart with the one action that would eliminate your largest single point of failure before optimizing secondary defenses.WarningAvoid security theater—adding complexity without eliminating real risk. A hardware wallet stored in the same location as your written seed phrase does not eliminate the primary threat.
- Understand how your constituency's choices affect the other threeRecognize that each constituency's behavior creates externalities for the others. Node runners who enforce clean mempool policies reduce Availability attacks on holders. Developers who introduce new features risk adding attack vectors that affect miners and node runners. Holders who move coins off exchanges reduce the leverage of custodial entities over governance.Pro tipBefore making a significant change—upgrading node software, switching mining pools, large transactions—consider the second-order effects on the constituencies you interact with.
A bitcoiner classifies themselves as a Holder. Mapping their attack surface, they recognize their coins on an exchange are exposed to custodial Availability risk: the exchange could halt withdrawals during a crisis. Applying the constituency model, they see that node runners enforce the rules that make self-custody possible. They move coins to a hardware wallet and begin running a node, shifting from Holder to Holder + Node Runner, reducing cross-constituency dependency.
A node runner applies the four-constituency model and recognizes that Developer actions directly affect their Integrity and Availability risk. When Bitcoin Core v31 shipped a bug forcing wallet migration, node runners who tracked the Developer constituency's release notes caught the issue before upgrading. Those who treated Developer activity as irrelevant to their role upgraded blindly and lost access to old wallet formats.
Evaluating the inscription spam debate through the four-constituency lens: Holders faced Availability attacks (unaffordable fees), Node Runners faced bloat and storage costs, Miners gained short-term fee revenue, Developers faced pressure to patch or ignore CVEs. The model reveals why constituencies talked past each other—each was optimizing for their own role's incentives without modeling the cross-constituency impact on Bitcoin's monetary Availability.
Originally a five-constituency model proposed by Andreas Antonopoulos. Luke de Wolf simplified it to four groups in 'Defending Bitcoin,' consolidating merchants and exchanges into the holder and node-runner categories to create a more actionable threat-mapping lens. Extracted from Bitcoin Infinity Media.