Offline Payments with Bitcoin

Offline Payments and SPV in Bitcoin (BSV)

Bitcoin can support offline-style payments, and this is actively used in BSV. The basic idea is that a merchant and a customer can build and verify a transaction locally, then push it to the network once both sides are satisfied.

A typical flow looks like this:

• The merchant presents an invoice template for the goods or services.

• The customer uses their wallet, often through an NFC device or a Bluetooth/WLAN link, to fill in the transaction:

  • They add their signed UTXOs as inputs.

  • They specify a change address for any remaining balance.

  • They include an extra data envelope that contains the Merkle path proofs for the UTXOs being spent.

The merchant then performs a Merkle path authentication against their locally stored block headers. This proves that the UTXOs being spent come from a valid block that is deep enough in the chain to be considered settled.

Once the merchant is satisfied, they broadcast the transaction and its accompanying Merkle proofs to the network. Shortly after, an SPV (Simplified Payment Verification) check can confirm that the transaction is seen and accepted by honest nodes. If other nodes are relaying and treating it as valid, it is reasonable to expect that the transaction will be mined into a future block on the longest proof of work chain.

Risks: Mempool Conflicts and Dishonest Chain Tips

Two main risks need to be considered:

1. Mempool double spend:Someone may have already tried to spend the same UTXOs elsewhere, and that conflicting transaction is in another node’s mempool but not yet mined.

2. Dishonest chain tip:An attacker controlling significant hash power may be extending an alternative chain tip that hides or omits earlier valid transactions, effectively presenting a fake version of recent history.

The first risk can be reduced by having the merchant’s system quickly query a random set of nodes after broadcasting the transaction. If those nodes agree that this is the first valid spend of those UTXOs, the odds of a successful double spend drop significantly.

The second risk is mitigated by relying on identity and callback mechanisms such as minerID and mAPI. These allow miners to signal which version of the chain they are extending and to notify merchants about the status of specific transactions. An alert system can warn participants when an apparently longer chain is actually an attack.

Double Spend Attack Scenario

Consider the diagram described in the original text. Alice attempts to spend UTXOs J and K again, even though they were already spent in earlier transactions on the honest chain. A malicious miner with a majority of hash power is extending a competing chain tip that does not include the original spends of J and K. On that dishonest branch, Alice’s new transaction appears valid.

If a merchant is only looking at that attacker’s chain, with no extra checks, they may be misled into accepting Alice’s second spend as valid because the history they see does not show the earlier transactions.

SPV as a Post-Broadcast Check

SPV is best understood as a verification step that happens after the transaction is broadcast. It confirms that the transaction is either already in a block or being carried by honest nodes that are likely to get it into a block.

However, SPV alone cannot protect a merchant who is unknowingly connected to an attacker’s chain tip. In the earlier example, Bob is the merchant. He verifies the Merkle path for Alice’s transaction and gets a correct result, because the Merkle proof is valid on the attacker’s chain. He then performs an SPV check that also appears valid, because he is talking to nodes that are following the attacker’s longer, but dishonest, chain.

If Bob is not checking miner identities or using mAPI callbacks from known, honest miners, he cannot see that he is on the wrong side of a fork. In that situation, Alice can successfully spend UTXOs that are already spent on the honest chain, and Bob will only discover the problem later when the legitimate chain overtakes the attacker’s.

When Bob does use minerID and mAPI callbacks, the picture changes. He may still get a valid Merkle proof for the transaction, but the SPV callbacks from honest miners will indicate that they are not going to include that transaction in their blocks. This tells Bob that the transaction is riding on an attack chain, and he can refuse it.

Operational Practices for Merchants

Merchants who process a high volume of transactions should treat this as an operational problem, not just a theoretical one. Good practices include:

• Running a transaction listener or subscribing to a broadcast and alert service that tracks which chain tip is considered honest by known miners.

• Using minerID and mAPI callbacks to confirm that transactions will be mined on the legitimate chain.

• Watching for alerts about chain splits or suspected attacks.

An attacker can only keep a dishonest chain tip alive while they continue to burn energy extending it beyond the honest chain. Once the attack stops, the honest chain catches up and becomes the longest chain again. At that point, the attacker’s branch and its transactions stand out as evidence of attempted fraud.

The protocol also adds friction for attackers with the block maturity rule. Newly mined coinbase rewards cannot be spent until 100 more blocks have been built on top of the block that created them. This means an attacker cannot quickly cash out the rewards from their attack blocks. They have to continue committing hash power for a long period if they want access to those coins, which makes sustained attacks more expensive and less attractive.

ELI5(ish...)

Here is a simpler way to think about all of this.

On BSV, you can pay someone even if one of you is offline or not directly connected to the main network. The merchant shows you a bill, your phone signs a transaction, and you hand them a little proof that your money really exists in the blockchain. The merchant checks that proof against a local copy of block headers, then sends the transaction to the network. If other nodes echo back that they see it as valid, the merchant can be pretty confident it will end up in a block soon.

The main dangers are:

• You might have already tried to spend the same money somewhere else.

• The merchant might accidentally be looking at a fake version of the blockchain run by an attacker.

To reduce the first risk, the merchant quickly asks a few other nodes if they have seen another transaction using the same coins. If they have not, it is probably fine.

To reduce the second risk, the merchant asks known miners, through IDs and callbacks, “Are you going to include this transaction in your real chain?” If the honest miners say yes, the merchant knows they are on the right side of the network. If the honest miners say no, the merchant has probably bumped into an attack and should not trust the payment.

Attackers can try to build a longer fake chain, but it costs them real money in electricity and hardware. They also cannot spend their mining rewards from that fake chain for 100 more blocks. That delay makes it harder to profit from the attack. Over time, the honest chain almost always wins, and the fake one becomes evidence of who tried to cheat.