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:
Double Spending: A customer might attempt to spend the same UTXO in a separate transaction already present in another node’s mempool.
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.
Last updated