fairCASH - the first true digital cash solution

The fairCASH Core Protocol (or short fCCP) is the name of the teleportation paradigm involved in the transfer of secrets (eCoins) between (previously) mutually agreed partners. This can take place between two nano-safe based eWallets or alternatively between an eWallet and an eCoins emitting instance (electronic Mint or eMint).

Due to the fact, that all message channels are to be assumed unrealiable ones, the result of any untreated Byzantine transfer is either a potential loss or overspending of the transferred (singleton) items, in this case the value of the eCoin(s). Taken as a challenge to computational fairness in the field of electronic commerce, the presented solution firstly separates all ‘good’ transfer cases from the 'failed' ones. It should be mentioned that the transfer itself is scaled to a heuristic policy of ‘no profit from any failure’ with the effect to increase the loss probability. These ‘bad’ transfers are post-processed by the local eWallet ‘enjoying’ a ‘controlled annihilation’ of all affected eCoins and the creation of an affidavit for the external arbiter (eMint).

This separation causes temporal unfairness to one or even both protocol entities because of the value loss connected to such an action. That is the reason to call this a ‘delayed-true two-party fair exchange’. The loss proofs can be turned into new value (e.g. exchanged against eCoins) in a succession step at any time outside the transfer protocol. This mechanism disconnects the transfer from the necessity of being online. The reimbursement process has to be negotiated with the eMint in the need to be done online. All this is achieved in an automated and user transparent way.

Workflow of fCCP in a message oriented form.
Workflow of fCCP in a message oriented form.

fCCP can be divided into five steps, arranged in top-down ascending ordered timeline of interactions for the payer and the payee. The protocol steps for an entity are depending on being an initiator or a responder in combination of spending or receiving money. The message flow as shown in the presented graphic relates to the sub case, where the originator is a payer. It shows the simplified transaction workflow. We see the message flow for the initiator to the left side (colored in light blue) and to the right the one for the responder to the right (colored in light orange). As a first action, the originator collects all information needed to conduct the protocol. This is done before entering into the pairing phase. On the other side, the recipient has to provide all requisite information before the pairing phase can be acknowledged, including his authorization for the deal. It is possible to make this anticipatory available.

The main task of fCCP is to arrange the combating of errors during the teleportation of eCoins between Alice and Bob on the one hand and the achievement of a consistent termination for both on the other hand. In principle, it is quite simple for both processes to come to the same stage of knowledge: One single successful acknowledge message is sufficient to achieve that. However, we cannot set up reliable communication over an arbitrarily unreliable medium, hence coordination of Alice and Bob under any communication protocol is still not possible. This requirement causes our fundamental problem: Both processes must come to an identical state of knowledge being able to fulfill the deal behind the transaction.

fCCP solves this problem within the fairCASH environment.