BALL

Why Trust It?

Technical

The wallet code is written in BAIL and runs on BALL. We discuss the verification strategy for those in the next section. Assuming those working "good enough" the wallet code must not fail wrt. these bullet points:

• Every "wallet" is a (sqlite) database holding a balance table of two columns: amount and currency. (Together with some user interface.)
• Users can create orders (documents) to transfer some amount to some other wallet. The receiver can either accept or reject.
• Users may change their notaries. Restrictions apply when orders are transfered: the receiving and sending wallet must share at least half the notaries with the Ricardian contract. (Intermediary wallets acting like a bank are required to transfer values between wallets lacking such "common trust" .)
• Irrelevant here is all the code to maintain per account nick names for wallets, notaries, currencies etc.

The wallet code make sure that it no order exceeds the senders balance and no receiver can accept the same order twice.

A well defined set of chosen peers, termed notaries, audits and backs up the process ensuring important properties: A) They verify the users signature at transfer time, sign a verification record strongly linked to the document and archive the record together with the document. This is a refined form of a signature, which we term booked multivalent (or multi-party) signature. Such a signature is more reliable in the long term than signatures schemes secured by secrets under control of the signatory. B) They replicate the calculation according to the contract, thereby tolerating byzantine faults to counter both dishonest accounting and failing devices. C) Preserve the privacy: the ledger is shared only among the notaries entrusted by the sender and receiver.

The full audit trail of all transactions relating to an account is available from the respective account until the user expunges the listing. The "notaries" actively verify that no account will create orders exceeding the balance and no payment is recorded twice.

Verification Strategy

TBD

• The wallet code (a.k.a. contract, application): "probably" correct. Intended to express the correct meaning. In case of dispute verbatim linked. Self-contained, intended to be stable over long periods of time.
• BAIL, BALL, Operating System, Hardware: The implementation assumed to be too complex to verify formally. Bugs to be changed even if they break backward compatibility. Instead of verification of these layers, we resort to "observational correct" at time of use plus a dispute policy: "pull the plug". (See also social support contract in the next section.)

Threat Model

It is the duty of the receiver to verify that an incoming payment originates from a trustworthy source and decide whether or not to accept a payment. Nevertheless this responsibility goes only so far. If an attacker could provide a pristine looking order, we could not blame the receiver.

How could we inject a fake payment? This would require to inject it into the network of notaries. The payment document is required to be available from a qualified majority of the notaries for a transaction to commence. However peers (notaries) check incoming document with the list of commissioned notaries of the Ricardian contract. (See "Using Notaries" in the Howto.) The document is deemed acceptable only if the majority of those peers confirms that the hash references a document available in the local archive of this notary (plus the hash is correct wrt. the document content itself).

Therefore: an attacker needs to circumvent the host security of the majority of a known set of peers (no Sybil attack) and fabricate a fake payment. This would be enough to fool the receiver.

Further note that in normal use, user would not run their account entirely from external peers as the demo does. They want to make sure to have their own peer device commissioned as a notary (and keep it off when not in use). Sudden updates from the network to their own account would be rejected, triggering a dispute and manual audit.

Thus the attacker is back at the problem: how to insert a fake node into a Merkle tree without breaking the hash tree's consistency. This given the additional complication that not all copies are within reach to clean the trace of the attack.

Dispute Policy

An important part of any payment system is a dispute policy in case of doubt. TBD: In case of dispute, the user may set an anonymous access code with permissions to only explore the account. No modifications will be possible using this code. (That's the "public" password, which lets you log into the examples.)

Epilogue

I know: everyone can design a system, which they can't break. Naturally I don't know how to break this. If you got a better idea, please let me know!