Bitcoin

Version: 1.0

Authors: David Cervigni

Executive Summary

This section contains an executive summary of the identified threats and their mitigation status

There are 15 unmitigated threats without proposed operational controls.

Threat IDCVSSAlways valid?
LightningNetwork.
WATCHTOWER_FAILURE 		10.0 (Critical) Yes
Bitcoin.
HASH_POWER_DECREASE 		7.5 (High) Yes
LightningNetwork.
ROUTING_NODE_DOS 		7.5 (High) Yes
Mixing.
PRIVACY_LEAK 		7.5 (High) Yes
Bitcoin.
51_PERCENT_ATTACK 		6.6 (Medium) Yes
Mixing.
MIXER_EXIT_SCAM 		6.5 (Medium) Yes
ARK.
PRIVACY_LEAK 		6.5 (Medium) Yes
Bitcoin.
DOUBLE_SPENDING 		5.9 (Medium) Yes
Bitcoin.
NETWORK_PARTITION 		5.9 (Medium) Yes
Mixing.
PARTICIPANT_LINKAGE 		5.9 (Medium) Yes
Mixing.
NETWORK_LEVEL_ANALYSIS 		5.9 (Medium) Yes
LightningNetwork.
CHANNEL_STATE_TAMPERING 		5.5 (Medium) Yes
LightningNetwork.
PRIVACY_LEAK 		5.3 (Medium) Yes
LightningNetwork.
CHANNEL_CLOSURE_DELAY 		4.9 (Medium) Yes
Bitcoin.
MINING_REORG 		0.0 (None) Yes

Threats Summary

This section contains an executive summary of the threats and their mitigation status

There are a total of 19 identified threats of which 19 are not fully mitigated by default, and 15 are unmitigated without proposed operational controls.

Threat IDCVSSValid when (condition)Fully mitigatedHas Operational
countermeasures
LightningNetwork.
WATCHTOWER_FAILURE 		10.0 (Critical) Always valid ❌ No
ARK.
ARK_DOUBLE_SPENDING 		9.1 (Critical) Always valid ❌ Yes
ARK.
FUND_LOCKUP 		9.1 (Critical) Always valid ❌ Yes
ARK.
HUB_COLLUSION 		9.0 (Critical) Always valid ❌ Yes
Bitcoin.
HASH_POWER_DECREASE 		7.5 (High) Always valid ❌ No
LightningNetwork.
ROUTING_NODE_DOS 		7.5 (High) Always valid ❌ No
Mixing.
PRIVACY_LEAK 		7.5 (High) Always valid ❌ No
ARK.
DOS_ATTACK 		7.5 (High) Always valid ❌ Yes
Bitcoin.
51_PERCENT_ATTACK 		6.6 (Medium) Always valid ❌ No
Mixing.
MIXER_EXIT_SCAM 		6.5 (Medium) Always valid ❌ No
ARK.
PRIVACY_LEAK 		6.5 (Medium) Always valid ❌ No
Bitcoin.
DOUBLE_SPENDING 		5.9 (Medium) Always valid ❌ No
Bitcoin.
NETWORK_PARTITION 		5.9 (Medium) Always valid ❌ No
Mixing.
PARTICIPANT_LINKAGE 		5.9 (Medium) Always valid ❌ No
Mixing.
NETWORK_LEVEL_ANALYSIS 		5.9 (Medium) Always valid ❌ No
LightningNetwork.
CHANNEL_STATE_TAMPERING 		5.5 (Medium) Always valid ❌ No
LightningNetwork.
PRIVACY_LEAK 		5.3 (Medium) Always valid ❌ No
LightningNetwork.
CHANNEL_CLOSURE_DELAY 		4.9 (Medium) Always valid ❌ No
Bitcoin.
MINING_REORG 		0.0 (None) Always valid ❌ No

Bitcoin - scope of analysis

Overview

Note: This is an example of threat model created by training an LLM

This document outlines potential threats to the Bitcoin network based on its design and operations as outlined in the Bitcoin whitepaper. It includes security measures to mitigate these threats.

Bitcoin security objectives

Network Security:

Data Integrity:

Operational Security:

Privacy Protection:

Data Integrity:

Diagram: Details:

Double Spending Prevention (DOUBLE_SPENDING_PREVENTION)

Prevent the double-spending of Bitcoin.

Priority: High

Attack tree:

Mining Security (MINING_SECURITY)

Ensure miners operate fairly and follow the network's protocol.

Priority: High

Network Availability (AVAILABILITY)

Ensure the Bitcoin network remains available and responsive to users.

Priority: High

Attack tree:

Resilience of the Bitcoin Network (NETWORK_RESILIENCE)

Ensure Bitcoin's blockchain remains secure and available even under attacks.

Priority: High

Attack tree:

Transaction Confidentiality (CONFIDENTIALITY)

Protect the privacy of Bitcoin transactions and user identities.

Priority: High

Attack tree:

Transaction Integrity (TRANSACTION_INTEGRITY)

Maintain the integrity of transactions recorded on the blockchain.

Priority: High

Attack tree:

Linked threat Models

  • Lightning Network (ID: Bitcoin.LightningNetwork)
  • Mixing (ID: Bitcoin.Mixing)
  • ARK L2 (ID: Bitcoin.ARK)

Bitcoin Threat Actors

Actors, agents, users and attackers may be used as synonymous.

Network Participants (NETWORK_PARTICIPANT)
Description:

Participants in the Bitcoin network who may attempt to exploit vulnerabilities or disrupt network operations.

In Scope as threat actor:

Yes

Sybil Actors (SYBIL_ACTORS)
Description:

Attackers attempting to dominate the network with numerous fake identities.

In Scope as threat actor:

Yes

Malicious Miners (MALICIOUS_MINERS)
Description:

Miners attempting to rewrite or fork the blockchain for selfish purposes.

In Scope as threat actor:

Yes

Network Attacker (NETWORK_ATTACKER)
Description:

Attackers attempting to disrupt the network's confidentiality availability or integrity.

In Scope as threat actor:

Yes

Actors whose economic interests could lead to disr[...] (ECONOMIC_ACTORS)
Description:

Actors whose economic interests could lead to disruptions in the network. This includes individuals or entities that may manipulate the mining rewards and transaction fees based on economic conditions or market demand.

In Scope as threat actor:

Yes

Actors involved in on-chain activities that could [...] (OTHER_ONCHAIN_ACTORS)
Description:

Actors involved in on-chain activities that could influence the security and availability of the network, including users transacting in Bitcoin and service providers.

In Scope as threat actor:

Yes

A collective of miners acting maliciously to alter[...] (ROGUE_MINING_POOL)
Description:

A collective of miners acting maliciously to alter block history or engage in fraudulent activities such as double spending.

In Scope as threat actor:

Yes

Regulatory bodies or governments that may implemen[...] (GOVERNMENT_ACTORS)
Description:

Regulatory bodies or governments that may implement laws affecting Bitcoin's use and operation, with the potential to disrupt network stability through regulatory changes.

In Scope as threat actor:

Yes

Assumptions

ADVANCED_ATTACKER

Attackers have significant computational power, potentially exceeding honest participants.

PUBLIC_NETWORK

Bitcoin operates on a public and open network.

Bitcoin Attack tree

Bitcoin Threats

Note This section contains the threat and mitigations identified during the analysis phase.

Control of Majority Hashing Power (51_PERCENT_ATTACK)

Threat actors:
Threat Description

An attacker accumulates more than 50% of the total mining power and uses this control to create a longer blockchain fork, thereby rewriting transaction history or blocking new transactions.

Impact

Allows an attacker to rewrite transaction history, double-spend, or block transactions.
TRANSACTION_INTEGRITY
NETWORK_RESILIENCE

CVSS
Base score: 6.6 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

Counter-measures for 51_PERCENT_ATTACK

DIVERSE_HASHPOWER Encourage diverse miner participation

Promote geographic and organizational decentralization of miners to reduce the likelihood of any single entity achieving majority hash power.

Countermeasure in place? ❌ Public and disclosable? ✔

Double Spending (DOUBLE_SPENDING)

Threat actors:
Threat Description

The attacker broadcasts two conflicting transactions to the network, one to make a purchase and another to send the same funds back to their own wallet, exploiting timing and confirmation delays.

Impact

Compromise of transaction validity by spending the same Bitcoin multiple times.
TRANSACTION_INTEGRITY

CVSS
Base score: 5.9 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Counter-measures for DOUBLE_SPENDING

LONGER_CONFIRMATION Increase block confirmations

Encourage waiting for multiple block confirmations to ensure transaction permanence.

Countermeasure in place? ✔ Public and disclosable? ✔

Network Partitioning (Eclipse Attack) (NETWORK_PARTITION)

Threat actors:
Threat Description

By controlling a node’s peers, the attacker isolates the target node from the rest of the network, feeding it incorrect blockchain data or preventing it from receiving updates.

Impact

Isolate nodes from the main network, manipulating their view of the blockchain.
NETWORK_RESILIENCE

CVSS
Base score: 5.9 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Counter-measures for NETWORK_PARTITION

PEER_DIVERSITY Peer Diversity

Nodes should maintain diverse peer connections to prevent isolation.

Countermeasure in place? ❌ Public and disclosable? ❌

Blockchain Reorganizations (MINING_REORG)

Threat actors:
Threat Description

Malicious miners use their hashing power to create an alternate chain that invalidates recent blocks, causing a reorganization of the blockchain.

Impact

Reverse transactions by introducing a longer fork.
TRANSACTION_INTEGRITY

CVSS
Base score: 0.0 (None)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:N

Counter-measures for MINING_REORG

TIMESTAMP_MONITORING Monitor blockchain timestamps

Use timestamps and multiple confirmations to minimize reorganization threats.

Countermeasure in place? ✔ Public and disclosable? ✔

Loss of Hash Power Due to Incentives (HASH_POWER_DECREASE)

Threat actors:
Threat Description

If the prevailing market conditions lead to low Bitcoin prices, miners may exit the market as profitability decreases. This reduction in mining activity could create a downward spiral where the network becomes less secure due to lower hash power, leading to longer confirmation times and increased vulnerability to attacks.

Impact

A significant decrease in hash power can lead to a drop in Bitcoin's price, reducing miner incentives, and potentially causing a negative feedback loop of further decreases in hash power before the next difficulty adjustment occurs. This creates a risk to the stability and security of the network, potentially making it more susceptible to attacks.
AVAILABILITY
NETWORK_RESILIENCE

CVSS
Base score: 7.5 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Counter-measures for HASH_POWER_DECREASE

MINER_SUBSIDY Maintain Miner Subsidies to Support Hash Power

Implement strategies to support miners during low price periods, such as temporarily lowering the mining difficulty adjustment period or providing incentives for miners to remain active in the ecosystem.

Countermeasure in place? ❌ Public and disclosable? ✔

DIVERSIFIED_REVENUE_MODELS Encourage Diversified Revenue Streams for Miners

Promote diversified revenue opportunities for miners, such as participating in transaction fee markets or providing ancillary services to the network to maintain viability even during low block reward phases.

Countermeasure in place? ❌ Public and disclosable? ✔

Lightning Network

Version: 1.1

Authors: David Cervigni

Lightning Network - scope of analysis

Overview

This document extends the Bitcoin threat model to focus on the Lightning Network, addressing threats to payment channels, routing nodes, and channel state integrity. The Lightning Network improves Bitcoin's scalability by facilitating off-chain transactions, but introduces specific security challenges. Transaction examples are derived from the Lightning Network whitepaper, incorporating the role of watchtowers to mitigate specific threats.

Lightning Network security objectives

Data Security:

System Integrity:

Network Resilience:

Operational Security:

Dispute Resolution:

Diagram: Details:

Channel Confidentiality (CHANNEL_CONFIDENTIALITY)

Ensure that the details of payment channels and transactions remain confidential and are not exposed to unauthorized entities.

Priority: High

Attack tree:

Channel Integrity (CHANNEL_INTEGRITY)

Protect the integrity of payment channel states to prevent tampering or unauthorized modifications.

Priority: High

Attack tree:

Routing Node Resilience (ROUTING_NODE_RESILIENCE)

Ensure routing nodes are protected against denial-of-service attacks and can handle high transaction volumes securely.

Priority: High

Attack tree:

Timely Channel Closure (TIMELY_CLOSURE)

Ensure channels can be closed promptly and securely in the event of disputes or failures.

Priority: High

Attack tree:

Watchtower Reliability (WATCHTOWER_RELIABILITY)

Ensure watchtowers function correctly to detect and penalize malicious channel state broadcasts.

Priority: High

Attack tree:

Lightning Network Threat Actors

Actors, agents, users and attackers may be used as synonymous.

Malicious Routing Node (MALICIOUS_ROUTING_NODE)
Description:

Routing nodes attempting to disrupt payments, intercept funds, or exploit network vulnerabilities.

In Scope as threat actor:

Yes

Malicious Channel Partner (CHANNEL_PARTNER)
Description:

A malicious channel partner attempting to cheat by broadcasting outdated or invalid channel states.

In Scope as threat actor:

Yes

Network Adversary (NETWORK_ADVERSARY)
Description:

An external attacker attempting to disrupt the network or compromise node communications.

In Scope as threat actor:

Yes

Assumptions

PUBLIC_NETWORK

The Lightning Network operates over a public and decentralized network, exposing nodes to potential adversaries.

PARTIAL_TRUST

Routing nodes may not be fully trusted by participants but are required for facilitating payments.

WATCHTOWER_AVAILABILITY

Watchtowers must remain available to detect and respond to malicious behavior promptly.

Lightning Network Attack tree

Lightning Network Threats

Note This section contains the threat and mitigations identified during the analysis phase.

Tampering with Channel States (CHANNEL_STATE_TAMPERING)

Threat actors:
Threat Description

A malicious channel partner broadcasts an outdated channel state to reclaim funds already spent. For example, Alice and Bob open a channel with 1 BTC each. Alice pays Bob 0.5 BTC off-chain, but later broadcasts the original channel state to reclaim her initial 1 BTC.

Impact

Attackers tamper with channel states, leading to disputes or financial loss for participants.
CHANNEL_INTEGRITY

CVSS
Base score: 5.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L
Counter-measures for CHANNEL_STATE_TAMPERING

PENALTY_MECHANISM Enforce Penalty Mechanisms

Use penalty transactions to ensure that any attempt to broadcast an outdated state results in a financial penalty for the attacker. Watchtowers monitor the blockchain for outdated states and broadcast penalty transactions on behalf of the victim.

Countermeasure in place? ✔ Public and disclosable? ✔

Denial of Service on Routing Nodes (ROUTING_NODE_DOS)

Threat actors:
Threat Description

A network adversary floods routing nodes with fake or excessive requests, causing them to exhaust resources. For instance, an attacker could repeatedly attempt to route payments through a specific node, forcing it to handle an unsustainable load.

Impact

Attackers overwhelm routing nodes, disrupting payment processing and reducing network availability.
ROUTING_NODE_RESILIENCE

CVSS
Base score: 7.5 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Counter-measures for ROUTING_NODE_DOS

RATE_LIMITING Implement Rate Limiting

Use rate limiting and request validation to mitigate denial-of-service attacks on routing nodes. Monitor traffic patterns and reject requests from nodes exhibiting suspicious behavior.

Countermeasure in place? ✔ Public and disclosable? ✔

Delayed Channel Closure (CHANNEL_CLOSURE_DELAY)

Threat actors:
Threat Description

The attacker refuses to cooperate during the channel closure process or uses the dispute mechanism maliciously. For example, Bob delays closing a channel with Alice, preventing her from accessing her locked funds during a time-sensitive event.

Impact

A malicious channel partner delays the closure of a channel, locking funds and causing financial loss.
TIMELY_CLOSURE

CVSS
Base score: 4.9 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Counter-measures for CHANNEL_CLOSURE_DELAY

FORCE_CLOSURE Support Force Closures

Allow participants to unilaterally close a channel after a timeout to recover locked funds. Watchtowers can assist by ensuring the closure process is secure and detecting malicious delays.

Countermeasure in place? ✔ Public and disclosable? ✔

Privacy Leak in Payment Routing (PRIVACY_LEAK)

Threat actors:
Threat Description

Malicious routing nodes or external adversaries analyze payment routes to infer transaction amounts and participants. For example, a routing node could monitor the flow of payments to deduce Alice is paying Charlie 0.2 BTC via Bob.

Impact

Sensitive transaction details are exposed to unauthorized entities, compromising user privacy.
CHANNEL_CONFIDENTIALITY

CVSS
Base score: 5.3 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
Counter-measures for PRIVACY_LEAK

ROUTE_ENCRYPTION Encrypt Payment Routes

Use onion routing to encrypt payment routes and protect transaction details from unauthorized disclosure. Ensure each hop only knows the adjacent nodes, preventing end-to-end correlation.

Countermeasure in place? ✔ Public and disclosable? ✔

Watchtower Unavailability (WATCHTOWER_FAILURE)

Threat actors:
Threat Description

A network adversary targets watchtowers with a DoS attack, preventing them from monitoring channel state broadcasts. For example, an attacker floods a watchtower with traffic to render it non-functional during a critical dispute.

Impact

Unavailable watchtowers fail to detect and penalize malicious behavior, weakening channel security.
WATCHTOWER_RELIABILITY

CVSS
Base score: 10.0 (Critical)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
Counter-measures for WATCHTOWER_FAILURE

DISTRIBUTED_WATCHTOWERS Use Distributed Watchtowers

Encourage the use of multiple, geographically distributed watchtowers to ensure redundancy and availability during disputes.

Countermeasure in place? ❌ Public and disclosable? ✔

Mixing

Version: 1.0

Authors: David Cervigni

Mixing - scope of analysis

Overview

This document provides a threat model for various Bitcoin mixing techniques aimed at enhancing privacy by obfuscating transaction trails. Mixing techniques such as CoinJoin, Tumbler services, and Chaumian mixing introduce potential security risks that need to be addressed.

Mixing security objectives

Privacy Enhancement:

System Integrity:

Identity Protection:

Diagram: Details:

Mixing Integrity (MIXING_INTEGRITY)

Ensure that the Bitcoin mixing process is free from tampering and fraudulent activity.

Priority: High

Attack tree:

Participant Anonymity (PARTICIPANT_ANONYMITY)

Protect the identity of participants engaging in mixing services.

Priority: High

Attack tree:

Transaction Privacy (TRANSACTION_PRIVACY)

Ensure Bitcoin transactions remain unlinkable and anonymous to third parties.

Priority: High

Attack tree:

Mixing Threat Actors

Actors, agents, users and attackers may be used as synonymous.

Malicious Mixing Service (MALICIOUS_MIXER)
Description:

A mixing service that colludes with attackers to deanonymize users.

In Scope as threat actor:

Yes

Network Observer (NETWORK_OBSERVER)
Description:

Entities monitoring the Bitcoin network to analyze transaction patterns and break anonymity.

In Scope as threat actor:

Yes

Participant Collusion (PARTICIPANT_COLLUSION)
Description:

Collaborating participants within a mixing process attempting to deanonymize others.

In Scope as threat actor:

Yes

Assumptions

TRUSTED_MIXING_SERVICE

Users assume that mixing services are not colluding with adversaries or law enforcement.

NETWORK_OBSERVATION

Adversaries may monitor the Bitcoin network to track transaction patterns despite mixing attempts.

Mixing Attack tree

Mixing Threats

Note This section contains the threat and mitigations identified during the analysis phase.

Privacy Leakage (PRIVACY_LEAK)

Threat actors:
Threat Description

A network observer analyzes mixing transaction patterns and timings to correlate addresses, revealing user identities.

Impact

Users' Bitcoin addresses and transaction history may be linked due to weaknesses in the mixing process.
TRANSACTION_PRIVACY

CVSS
Base score: 7.5 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Counter-measures for PRIVACY_LEAK

COIN_JOIN Use CoinJoin Techniques

Utilize CoinJoin-based mixing that combines multiple users' transactions to break address linkability.

Countermeasure in place? ✔ Public and disclosable? ✔

Mixer Exit Scam (MIXER_EXIT_SCAM)

Threat actors:
Threat Description

A malicious mixer operator collects deposits and disappears without processing the mixing, resulting in financial loss for users.

Impact

A mixing service may abscond with users' Bitcoin instead of returning mixed outputs.
MIXING_INTEGRITY

CVSS
Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Counter-measures for MIXER_EXIT_SCAM

TRUSTED_SERVICES Use Trusted and Audited Mixing Services

Prefer decentralized, open-source mixers with a proven track record of transparency.

Countermeasure in place? ❌ Public and disclosable? ✔

Participant Linkage Attack (PARTICIPANT_LINKAGE)

Threat actors:
Threat Description

Malicious participants join mixing transactions with the intent of analyzing inputs and outputs to deanonymize other users.

Impact

Participants within a mixing process collude to track inputs and outputs, reducing anonymity.
PARTICIPANT_ANONYMITY

CVSS
Base score: 5.9 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Counter-measures for PARTICIPANT_LINKAGE

RANDOMIZED_INPUTS Randomize Input and Output Patterns

Use randomized transaction structures and delays to reduce linkability between participants.

Countermeasure in place? ✔ Public and disclosable? ✔

Network-Level Transaction Analysis (NETWORK_LEVEL_ANALYSIS)

Threat actors:
Threat Description

An attacker monitors Bitcoin network traffic and uses timing analysis to correlate mixed transactions.

Impact

Adversaries analyze network traffic to uncover the relationships between mixed transactions.
TRANSACTION_PRIVACY

CVSS
Base score: 5.9 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Counter-measures for NETWORK_LEVEL_ANALYSIS

TOR_VPN_USAGE Use Privacy-Enhancing Technologies

Users should leverage Tor or VPN services to obfuscate their network traffic and enhance anonymity.

Countermeasure in place? ❌ Public and disclosable? ✔

ARK L2

Version: 1.1

Authors: Example by David Cervigni

ARK L2 - scope of analysis

Overview

Threat model for ARK Layer 2 scaling solution for Bitcoin. ARK aims to provide efficient off-chain scaling and enhanced privacy while preserving decentralization and security.

Diagrams

ARK_L2_Architecture.png

ARK L2 Threat Actors

Actors, agents, users and attackers may be used as synonymous.

Malicious Hub Operator (MALICIOUS_HUB)
Description:

A rogue hub operator attempting to steal funds or delay transactions.

In Scope as threat actor:

Yes

Network Attacker (NETWORK_ATTACKER)
Description:

An adversary attempting to exploit ARK's communication network.

In Scope as threat actor:

Yes

Internal Threat (INTERNAL_THREAT)
Description:

Insider threats from within the ARK network operations team.

In Scope as threat actor:

Yes

Assumptions

OFF_CHAIN_RISK

Off-chain transactions are inherently vulnerable to counterparty risks and require trust assumptions.

HUB_OPERATORS

ARK hubs may be operated by third parties with varying trust levels.

BITCOIN_FINALITY

ARK transactions are only final once confirmed on Bitcoin L1.

Assets

Summary Table

Title(ID)TypeIn Scope
Bitcoin Layer 1
BITCOIN_LAYER1 		system ✔️
ARK Off-chain Transactions
ARK_TRANSACTIONS 		dataflow ✔️
ARK Hub
ARK_HUB 		system ✔️
User Wallets
USER_WALLETS 		system ✔️
Details

Bitcoin Layer 1 (system in scope - ID: BITCOIN_LAYER1)

The base layer of Bitcoin blockchain used for anchoring Layer 2 transactions.

ARK Off-chain Transactions (dataflow in scope - ID: ARK_TRANSACTIONS)

Transactions processed off-chain within the ARK network before final settlement on Bitcoin L1.

ARK Hub (system in scope - ID: ARK_HUB)

Centralized or semi-centralized hubs that facilitate batching and processing of ARK transactions.

User Wallets (system in scope - ID: USER_WALLETS)

Wallets used by end-users to interact with the ARK network and execute transactions.

ARK L2 Attack tree

ARK L2 Threats

Note This section contains the threat and mitigations identified during the analysis phase.

Double Spending in Off-chain Transactions (ARK_DOUBLE_SPENDING)

Assets (IDs) involved in this threat:
Threat Description

The attacker attempts to make multiple payments before the finalization of off-chain transactions.

Impact

A malicious user may attempt to spend funds multiple times by exploiting delays in settlement finality.
DOUBLE_SPENDING_PREVENTION

CVSS
Base score: 9.1 (Critical)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Counter-measures for ARK_DOUBLE_SPENDING

TIMELOCKS Timelocks on Transactions

Implement timelocks to prevent double-spending attempts.

Countermeasure in place? ✔ Public and disclosable? ✔ Is operational?✔ (operated by UNDEFINED)

Hub Collusion Attack (HUB_COLLUSION)

Assets (IDs) involved in this threat:
Threat actors:
Threat Description

Multiple hubs conspire to delay or censor transactions to gain an unfair advantage.

Impact

Colluding hub operators could manipulate transaction processing or withhold transactions.
AVAILABILITY

CVSS
Base score: 9.0 (Critical)
Vector:CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:H
Counter-measures for HUB_COLLUSION

HUB_DECENTRALIZATION Distributed Hub Network

Encourage a decentralized set of hubs to reduce collusion risks.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by UNDEFINED)

User Privacy Leakage (PRIVACY_LEAK)

Assets (IDs) involved in this threat:
Threat actors:
Threat Description

An attacker monitors transaction flow to de-anonymize users.

Impact

User transaction data could be leaked due to weak privacy mechanisms.
CONFIDENTIALITY

CVSS
Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Counter-measures for PRIVACY_LEAK

COINJOIN_INTEGRATION CoinJoin Integration

Use privacy-enhancing techniques like CoinJoin to obfuscate transactions.

Countermeasure in place? ❌ Public and disclosable? ✔

Funds Locked Due to Hub Unresponsiveness (FUND_LOCKUP)

Assets (IDs) involved in this threat:
Threat actors:
Threat Description

The hub operator ceases operations or withholds processing transactions, leading to user funds being locked.

Impact

If a hub becomes unresponsive, user funds may become locked and inaccessible.
AVAILABILITY

CVSS
Base score: 9.1 (Critical)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Counter-measures for FUND_LOCKUP

REFUND_TRANSACTION Refund Transactions After 4 Weeks

Implement automatic refund transactions to return locked funds to the original owners after a pre-defined timeout period (e.g., 4 weeks).

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by UNDEFINED)

Denial of Service Attack on Hubs (DOS_ATTACK)

Assets (IDs) involved in this threat:
Threat actors:
Threat Description

An attacker sends a large volume of requests to overload the network.

Impact

A flood of transactions could overwhelm ARK hubs and degrade service.
AVAILABILITY

CVSS
Base score: 7.5 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Counter-measures for DOS_ATTACK

RATE_LIMITING Rate Limiting on Hubs

Implement rate limiting and anomaly detection to mitigate attacks.

Countermeasure in place? ❌ Public and disclosable? ✔ Is operational?✔ (operated by UNDEFINED)

Requests For Information

    Operational Security Hardening Guide

    SeqCountermeasure Details
    1

    Title (ID): Distributed Hub Network (HUB_DECENTRALIZATION)
    Mitigates: Hub Collusion Attack (HUB_COLLUSION)

    Description: Encourage a decentralized set of hubs to reduce collusion risks.
    2

    Title (ID): Rate Limiting on Hubs (RATE_LIMITING)
    Mitigates: Denial of Service Attack on Hubs (DOS_ATTACK)

    Description: Implement rate limiting and anomaly detection to mitigate attacks.
    3

    Title (ID): Refund Transactions After 4 Weeks (REFUND_TRANSACTION)
    Mitigates: Funds Locked Due to Hub Unresponsiveness (FUND_LOCKUP)

    Description: Implement automatic refund transactions to return locked funds to the original owners after a pre-defined timeout period (e.g., 4 weeks).
    4

    Title (ID): Timelocks on Transactions (TIMELOCKS)
    Mitigates: Double Spending in Off-chain Transactions (ARK_DOUBLE_SPENDING)

    Description: Implement timelocks to prevent double-spending attempts.

    Testing guide

    This guide lists all testable attacks described in the threat model

    SeqAttack to testPass/Fail/NA

    Keys classification