# 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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://hub.bsvblockchain.org/higher-learning/bsv-academy/bitcoin-primitives-merkle-trees/merkle-trees-and-simplified-payment-verification/offline-payments.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.