The question of using digital money in the event of a network outage comes up again and again. Here is an overview of the options and their pros and cons.

More information on digital money, digital assets and blockchain is available here. Auch auf Deutsch 🇩🇪: «Digitales Offline-Geld?»

Tamper-proof hardware

The first ATMs had offline capabilities, either as standard or as a fallback in case of network failure. In this context, both the ATM itself and the magnetic stripe on the bank card were considered tamper-proof, as magnetic stripe readers were not widely available at the time.

Many years ago, magnetic stripes lost their tamper-proof aura. Chip cards, which are much more difficult (but not impossible) to manipulate, have replaced them.

Many modern processors also allow software to run in a special environment to make tampering with that software and its data difficult or impossible, approximating tamper-proof hardware on consumer devices.

If only tamper-proof systems are used on both sides of a financial transaction, that transaction can be executed offline. Only a connection between those two devices is necessary at the time of transaction. However, this requires a very high level of trust in the supplier of the relevant systems, as they cannot be independently inspected due to the nature of the system, especially not by the customer.

Transparent solutions

But as soon as the system should be independently inspectable (e.g. FOSS), the playing field change and we have a Distributed System. In particular, we need the ability to prevent — or at least detect — the attempt of spending a digital asset more than once. To protect against this double spending, someone has to keep records of the spending. As a result, we have a trusted third party, which is only reachable over a network.

Two levels

It should be noted that we have distributed systems at two levels:

1. The transaction system between the two payment parties, the (accounting) witness and the network connecting them.
2. The witness’s database system where the transactions are stored; the distributed system also including a network to connect them.

The structure, scaling, and failure tolerance of the database system is left to the “witness” (classically a payment service provider). Without loss of generality, we can think of it as a centralized system, i.e., a single database master. (Typically, the system is likely to be a computer cluster with primary/secondary or active/active replication).

(There is nothing fundamentally preventing the database to be implemented as a blockchain. However, the complexity, lack of predictability or tuning options for system properties, poor manageability, difficulty to assess behavior in the event of an error (network failure/partitioning), and costs must be weighed against a solution implemented by clearly defined players with transparency, accountability, and defined responsibility.)

We are mainly interested in the transaction system, which we will now examine in more detail:

Basic solution (“centralized”)

In this system, both payment participants contact the witness. As long as the witness is reachable and functional, the transaction is executed.

In this case we have maximum consistency (“Consistency”), however, in case of a network failure (“Partition”) the availability (“Availability”) is zero.

Quorum

The database system is often implemented using a quorum and geographical distribution. Even if a single data center were no longer accessible, transactions could still be carried out.

Even if individual network connections fail, the system can remain consistently available.

(This case could also have been mapped to a change in internal structure of the database system; however, it allows for an helpful intermediate step before the next point).

Regional resilience

Often, some of the digital coins, similar to real-world cash, mainly circulate locally. Then, a regional data center can be assigned the sole (or, at least, main) responsibility for keeping track of these monetary items. This would allow the system to continue to operate even if global network connections are disrupted; as long as they still work locally.

In many cases (money acquired locally is also re-issued locally), this results in higher availability in the partition case, while fully maintaining consistency.

Offline: Consistency

If the network is not available at all, consistency and availability cannot be achieved at the same time. If consistency is indispensable, availability will be omitted, i.e.:

Payments are no longer possible. (Identical to “central” in case of failure).

Offline: Availability (“opportunistic”)

If availability is key, we get an opportunistic payment system: the merchant must trust customer’s promise that she has not yet spent that particular coin. If a trust relationship exists and the payment amount is small, the risk of failure can be kept negligible. Once the network is back up and working for everyone again, the merchant gets the certainty, one way or the other.

Payments are possible, but only based on trust.

In the eCash anonymous payment system and its derivatives, such as GNU Taler, the customer is automatically deanonymized if one of her coins is spent multiple times. Thus, the bilking customer can be identified and prosecuted. If needed, this process could also be automated; however, so far the offline operation is only provided as a stopgap.

Conclusion

Offline financial transactions seem to be possible only in black box payment systems. As soon as insight into its functions are requested, offline transactions are possible only opportunistically or not at all.