Offline Payments

BSV also has the capacity for offline payments. A merchant can present an invoice template to the customer for goods or services and then through the use of key pairs on an NFC device or bluetooth/WLAN connectivity, the customer then simply adds their signed UTXOs, change address and an additional data envelope with proofs for the Merkle path. The merchant performs a Merkle path Authentication Proof against their locally stored block headers to verify the UTXO came from a validly mined block of a suitable depth in the blockchain. The merchant then broadcasts this and the relevant Merkle proofs to the network. The SPV check is performed shortly after and if the transaction sits validated with some other nodes on the network, then it is safe to assume the transaction will be included in a later block in the longest proof of work chain.

The only risks would be that of an earlier spend of the same funds in the current mempool of another node that are yet to be included in a block or if the chain is under an attack that is promoting an invalid chain tip that may not include a previous transaction that spent the funds. The former is mitigated by querying other random nodes shortly after the transaction has been broadcast by the merchant to see if they have deemed it the valid first-time funds are spent while the latter relies on honest nodes being able to alert the network of such an attack through minerID, callback functions from mAPI, or an alert system of sorts.

The above illustration shows Alice trying to double spend UTXO (J) and (K) that have already been spent, while a dishonest chain tip that excludes those earlier spends is being extended by a malicious node with a majority of hashpower.

In effect, SPV is a post-broadcast check on a transaction to verify that it has been or will be included in a block. It is still important for a merchant to understand that without the proper tools they could be unknowingly connected to a version of the ledger that is promoted under an attack from a dishonest node with a majority of hash power, which may not include a recent spend of the funds you are receiving. An example of this can be seen in the above diagram where if Bob is not checking minerID or using mAPI call back, he gets a correct valid result for the Merkle authentication proof he performs, but a fake valid result from the SPV check because he is unaware that he is connected to an attacker's longer chain tip. Therefore, Alice can spend funds from UTXOs that have already been used as inputs in transactions recorded to the valid version of the chain maintained by the honest nodes. When Bob employs the additional measures of mAPI call back from minerID identifiable nodes, the Merkle Authentication Proof may yield a valid result, yet the SPV check will alert him to the attack and that they will not be including the invalid transaction from Alice.

Merchants who accept a lot of transactions should consider running at least a transaction listener or subscribing to an alert system where any ambiguity around which is the honest version of the chain can be announced. Such an attack as illustrated above can only be sustained for as long as a dishonest node can expend enough energy to extend their chain tip beyond the legitimate one and through the use of minerID and mAPI callback, once the attack ceases the legitimate chain will catch up and extend beyond the attackers, while that tip can then be used as incriminating evidence for the attempted double spends upon merchants. An additional protective measure is the block maturity rule which prevents a node from being able to transfer coinbase rewards until 100 blocks have been built upon the one the reward came from. This means that if an attacker is attempting to extend the chain for some kind of gain, they will have to continue to expend hash power to do so, yet will be unable to spend their renumeration for 100 blocks having the effect of increasing the cost of maintaining their attack.