Nakamoto Threat Model

[jio-gl]

Nakamoto Release Threat Model

Version 0.1

What are we working on?

We are modeling threats for the Nakamoto Release - a new Stacks blockchain design that enables faster and more reliable block production. Key components include:

• Smart contracts like .pox-4 for PoX and distributed signing
• Stacker nodes for signing blocks
• Miner nodes for block production
• Peer network for block propagation
• Interaction with the Bitcoin blockchain
• Consensus mechanisms and cryptographic protocols

What can go wrong?

• Smart contract flaws enable STX lockup or unauthorized operations
• Dishonest signers manipulate voting or refuse to sign valid blocks
• Cryptographic weaknesses compromise keys or enable forgeries
• Transaction censorship, exclusion, or manipulation by miners
• Eclipse attacks isolate nodes from peers and canonical chain
• Operational failures like bugs/outages disrupt block production
• Legal or regulatory changes undermine blockchain operations
• Business partnerships and integrations introduce new risks

What are we going to do about it?

• Extensive auditing of core smart contracts like .pox-4
• Multi-party computation and key sharding for signing keys
• Penalties and slashing conditions for byzantine actors
• MEV protections like ATC-C to prevent block exclusion
• Peer authentication and redundancy for resilience
• Monitoring systems to rapidly detect anomalies or failures
• Ongoing cryptography research and upgrade planning
• Legal/regulatory tracking and compliance program
• Structured vetting process and risk modeling for partners

Did we do a good job?

We can validate the threat model via:

• Expert design and code reviews
• Implementation of model-informed mitigations
• Bug bounties and penetration testing
• Staged testnet deployments under attack simulation
• Security KPIs like meaningful time between failures
• Tracking of audit/testing findings and remediation
• Regular re-assessment as implementation and landscape evolve

[NTM-1] Smart Contract Threats

• [NTM-1-1] Access control vulnerabilities in .pox-4 contract could allow unauthorized stacking/voting
• [NTM-1-2] Logic errors in .pox-4 could enable STX lockup or miscalculation of rewards
• [NTM-1-3] Flaws in WSTS implementation could enable faulty quorum or manipulated signing

Mitigation Plan

[NTM-1-1]

• Conduct thorough smart contract audits on .pox-4 prior to deployment
• Implement role-based access controls for stacking/voting functions
• Provide bug bounties for .pox-4 vulnerabilities
• Use formal verification tools to prove correctness where possible
• Test contract extensively on testnets prior to mainnet deployment

[NTM-1-2]

• Carefully review reward calculations and STX lockup logic
• Unit test reward calculation and STX lockup code paths
• Fuzz test inputs to .pox-4 functions
• Conduct audits focused on identifying logic errors
• Freeze/fix critical .pox-4 logic after auditing

[NTM-1-3]

• Conduct cryptographic reviews of WSTS implementation
• Formal verification and proofs of security for WSTS code
• Extensively unit test all WSTS functionality
• Fuzz test and simulate WSTS in adversarial environments
• Periodic audits of WSTS implementation for flaws
• Implement continuous monitoring for faulty quorums

[NTM-2] Stacker Voting Threats

• [NTM-2-1] Collusion to stall blocks or manipulate votes
• [NTM-2-2] Dishonest signers refusing to sign or signing invalid blocks
• [NTM-2-3] Sybil attacks with fake identities to influence votes
• [NTM-2-4] 51% attack if majority of STX is compromised
• [NTM-2-5] DDoS attacks could disrupt signing and block production

Mitigation Plan

[NTM-2-1]

• Implement slashing conditions for byzantine behavior
• Require minimum node uptime and redundancy for Stackers
• Monitoring systems to detect abnormal stalling activity

[NTM-2-2]

• Slashing and penalties for refusal to sign valid blocks
• Monitoring systems to detect dishonest signing patterns
• Smart contract logic to auto-remove dishonest signers

[NTM-2-3]

• KYC/AML requirements for Stacker participation
• Limit number of identities per validated entity
• Monitoring systems to detect Sybil identities
• Raise threshold signature requirements to mitigate impact

[NTM-2-4]

• Implement staking lock periods to increase attacker costs
• Ensure sufficiently decentralized Stacker distribution
• Monitoring systems to detect concentrated STX ownership
• Emergency stacker rotation if threshold is approached

[NTM-2-5]

• DDoS mitigation infrastructure for Stacker nodes
• Require redundancy in Stacker nodes
• Implement reputation systems to block attacking nodes
• Monitoring systems to rapidly detect DDoS attempts

[NTM-3] Cryptographic Threats

• [NTM-3-1] Flaws in distributed key generation could compromise signing keys
• [NTM-3-2] Weak randomness during signing vulnerable to prediction
• [NTM-3-3] Side-channel attacks on signer hardware to steal keys
• [NTM-3-4] Implementation bugs introduce crypto vulnerabilities
• [NTM-3-5] Insufficient threshold t makes system insecure
• [NTM-3-6] Scalability issues with many signers

Mitigation Plan

[NTM-3-1]

• Use multi-party computation for distributed key generation
• Implement cryptographic audits of key generation scheme
• Ensure redundancy and rotation of key shares
• Secure erasure of keys from memory after use

[NTM-3-2]

• Use audited random number generation sources
• Continuously monitor entropy sources for manipulation
• Cryptographic audits of signing implementations

[NTM-3-3]

• Hardware-based security for signer nodes
• Regular rotation of signing nodes and keys
• Physical security controls on premises

[NTM-3-4]

• Extensive unit testing of cryptographic code
• Formal verification of core crypto implementations
• Bug bounties for discovered vulnerabilities

[NTM-3-5]

• Cryptographic analysis to model optimal threshold
• Monitoring and simulation to estimate fault tolerance
• Dynamic threshold adjustments via governance

[NTM-3-6]

• Shard signers into smaller quorum groups
• Optimize implementations for signature aggregation
• Horizontally scale signers across more hardware
• Lower signing frequency if throughput limited

[NTM-4] Bitcoin Threats

[NTM-4-1] Double spends could burn counterfeit BTC for mining eligibility

[NTM-4-2] Finney attacks could manipulate block-commits for cheap mining

[NTM-4-3] 51% attack reorgs could disrupt Stacks/Bitcoin consensus

[NTM-4-4] Selfish mining could exclude block-commits and disrupt chain

Mitigation Plan

[NTM-4-1]

• Require sufficient Bitcoin confirmations before accepting BTC
• Perform chain analysis to detect double spend attempts
• Ban participants who attempt to double spend
• Alert monitoring if duplicate BTC detected

[NTM-4-2]

• Require minimum Bitcoin confirmations before mining eligibility
• Monitoring systems to detect block anomalies
• Cryptographic commitment schemes to prevent Finney attacks
• Implement difficulty adjustments to mitigate impact

[NTM-4-3]

• Make Bitcoin reorgs expensive by anchoring Stacks history
• Monitoring systems to rapidly detect Bitcoin chain anomalies
• Emergency response plan to handle critical Bitcoin failures
• Ensure redundancy across multiple blockchains

[NTM-4-4]

• Use BLS signatures to mitigate targeted miner exclusion
• Adjust election algorithms to punish selfish mining
• Implement miner reputation systems
• Monitoring systems to detect exclusion of commits

[NTM-5] Stacks Threats

[NTM-5-1] Eclipse attacks could isolate nodes from canonical chain

[NTM-5-2] Faulty nodes could stall consensus and block production

[NTM-5-3] Congestion could delay inclusion of important transactions

[NTM-5-4] Oracle manipulations can lead to faulty contract executions

[NTM-5-5] Front-running to extract MEV from pending transactions

Mitigation Plan

[NTM-5-1]

• Use Dandelion diffusion to mitigate eclipse attacks
• Monitoring systems to detect isolation of nodes
• Peer authentication and encryption to prevent infiltration
• Incentives for nodes to maintain diverse peer connections

[NTM-5-2]

• Minimum uptime and redundancy requirements for nodes
• Reputation systems to limit faulty node impact
• Monitoring systems to detect stalled consensus
• Node patching and updates to mitigate bugs

[NTM-5-3]

• Dynamic block sizes or pricing to prevent congestion
• Prioritization of transactions via pricing
• Scaling optimizations like sharding as required
• Monitoring systems tracking transaction latency

[NTM-5-4]

• Thorough auditing of oracle smart contracts
• Monitoring systems to detect manipulation
• Limit oracle calls from core system contracts
• Multi-party oracle schemes to increase security

[NTM-5-5]

• Encrypted/obfuscated transaction pool
• Front-running protections like flash loans
• Limit exposed chain data to mitigate exploits
• Monitoring systems to detect transaction anomalies

[NTM-6] Governance Threats

[NTM-6-1] Centralized governance could lead to corruption

[NTM-6-2] Inadequate stakeholder input into upgrades

[NTM-6-3] Unclear or flawed dispute resolution mechanisms

[NTM-6-1]

• Implement decentralized governance via DAOs
• Transparent and on-chain governance processes
• Stakeholder voting rights proportional to stake
• Checks and balances via multi-party administration

[NTM-6-2]

• Gather community input through forums and surveys
• Sufficient notice and discussion periods for changes
• Stakeholder voting on all parameter changes
• Bug bounties and testnets to involve ecosystem

[NTM-6-3]

• Published dispute resolution policy and mechanisms
• Allow disputes to be adjudicated on-chain via DAO
• Overhaul dispute processes post-mortem if flawed
• External arbitration as needed for serious disputes

[NTM-7] Operational Threats

[NTM-7-1] Bugs and flaws due to insufficient testing

[NTM-7-2] Network outages could stall block production

[NTM-7-3] Lack of monitoring leading to undiscovered failures

[NTM-7-4] Upgrade bugs or incompatibilities disrupt operations

Mitigation Plan

[NTM-7-1]

• Implement extensive unit, integration, and system testing
• Launch comprehensive bug bounty programs
• Conduct regular external audits and penetration testing
• Enable testnets, staging environments, and canary releases

[NTM-7-2]

• Multi-region node deployment with failover capacity
• Minimum node uptime requirements and redundancy
• Priority incident response plans for network outages
• Monitoring systems to rapidly detect network issues

[NTM-7-3]

• Implement robust monitoring, logging, and analytics
• Define key operational metrics and ideal thresholds
• Configure alerting for metric anomalies and failures
• Regularly test failover processes and backups

[NTM-7-4]

• Thorough QA testing of upgrades and patches
• Segmented rollouts to progressively mitigate bugs
• Feature flags and config toggles to disable as needed
• Monitoring systems to quickly identify upgrade faults

[NTM-8] Broad Threats

[NTM-8-1] Cryptographic breakthroughs that compromise security

[NTM-8-2] Emergent threats like quantum computing

[NTM-8-3] Changing regulatory landscape creates legal issues

[NTM-8-4] Business failures or partnerships problems

[NTM-8-5] Data breaches and infrastructure attacks

[NTM-8-6] Lack of audits leaving flaws undiscovered

[NTM-8-1]

• Continuously evaluate emerging cryptographic research
• Implement algorithm agility to upgrade crypto as needed
• Focus on quantum-resistant cryptography
• Bug bounty programs to identify any crypto flaws

[NTM-8-2]

• Research quantum computing impact and mitigations
• Contribute to development of quantum-resistant crypto
• Implement hybrid schemes to increase quantum readiness
• Partner with quantum computing labs and researchers

[NTM-8-3]

• Dedicated legal and compliance team to monitor regulations
• Contribute to policy discussions and draft considerations
• Build compliant systems from the start
• Geofencing and jurisdiction analysis to manage legal risk

[NTM-8-4]

• Vet partners thoroughly - technically and legally
• Structure partnerships to limit downstream risk
• Multi-partner strategies to avoid over-reliance
• Audit smart contract integrations carefully

[NTM-8-5]

• Implement defense-in-depth with layered controls
• Mandatory security training and practices
• Regular pen testing and security audits
• Bug bounty programs and external security research

[NTM-8-6]

• Frequent internal and external audit schedules
• Address all audit findings via bug bounties
• Automated scanning for new vulnerabilities
• Targeted audits of highest risk components

[AshtonStephens]

These sections are the largest concerns:

• [NTM-1] Smart Contract Threats
• [NTM-2] Stacker Voting Threats
• [NTM-3] Cryptographic Threats