# Offline Payments
#### **How Offline Payments Work**
BSV supports **offline payments**, enabling transactions even when one party is temporarily disconnected from the network.
A **merchant** can present an **invoice template** to the customer — for example, for goods or services — while the customer uses **key pairs** stored on an **NFC device** or connected via **Bluetooth/WLAN**.
The customer then adds:
* Their **signed UTXOs** (unspent transaction outputs),
* A **change address**, and
* A **data envelope** containing **Merkle path proofs**.
The merchant uses these to perform a **Merkle Path Authentication Proof** against **locally stored block headers**, confirming that the UTXO originates from a **valid block** of sufficient depth in the blockchain.
Once verified, the merchant **broadcasts the transaction** and its **Merkle proofs** to the network. Shortly after, an **SPV check** is performed to confirm whether other nodes have validated the transaction.
If it appears in those nodes’ mempools, the merchant can safely assume the transaction will soon be included in a block within the **longest proof-of-work chain**.
***
#### **Recognizing and Mitigating Risks**
While SPV helps confirm transaction validity, two main risks remain:
1. **Double Spending:**\
A customer might attempt to spend the same UTXO in a separate transaction already present in another node’s mempool.
2. **Dishonest Chain Tip Attack:**\
A malicious node with significant hash power may promote an **invalid chain tip** that omits earlier legitimate transactions.
To mitigate these risks:
* Merchants should **query random nodes** after broadcasting the transaction to ensure the funds are being spent for the first time.
* They should also rely on tools such as **minerID**, **ARC callback functions**, or other **alert systems** to detect attacks and dishonest chains.
***
#### **Understanding the SPV Check**
An **SPV check** serves as a **post-broadcast verification** step, confirming whether a transaction has been — or soon will be — included in a block.
However, merchants must be cautious:\
Without proper tools, they could unknowingly be connected to a **dishonest chain** maintained by an attacker with majority hash power.
In this situation:
* The **Merkle Authentication Proof** may appear valid (since it checks only local block headers).
* But the **SPV check** could return a **false positive**, misleading the merchant into believing the transaction is legitimate.
When a merchant uses **minerID verification** and **mAPI callbacks** from identifiable, trusted nodes, the system can detect inconsistencies between the **Merkle proof** and the **SPV check**.
This allows the merchant to **spot attacks in real time** and avoid accepting invalid transactions.
***
#### **Defensive Measures for Merchants**
For merchants handling frequent or high-value transactions, several protective strategies are recommended:
* **Run a transaction listener** or subscribe to an **alert system** to be notified of potential forks or chain conflicts.
* Use **minerID and ARC callback integrations** to verify that transactions are recognized by honest, high-hash-power nodes.
* Understand that any attack on the chain can only persist while the attacker continues expending enough energy to maintain their **dishonest chain tip**.
Once the attack ends, the **legitimate chain** — extended by honest nodes — overtakes the attacker’s version.
At this point, the dishonest chain tip can serve as **legal evidence of attempted double spends**.
#### **Block Maturity Rule**
An additional protection comes from Bitcoin’s **block maturity rule**.\
This rule prevents miners from spending **coinbase rewards** until **100 blocks** have been built on top of the block containing the reward.
This means:
* Attackers must **maintain their fork** for at least 100 blocks to benefit financially.
* This dramatically **increases the cost and difficulty** of sustaining an attack, discouraging dishonest behavior on the network.
***
#### **Key Takeaways**
* **Offline payments** on BSV allow transactions to occur without constant Internet connectivity.
* **Merkle proofs** and **SPV checks** ensure transaction authenticity and connection to the valid proof-of-work chain.
* Merchants must guard against **double spends** and **dishonest chain tips** using tools like **minerID**, **ARC callbacks**, and **alert systems**.
* The **block maturity rule** increases the cost of sustaining attacks, protecting the network’s integrity.
