All Issues - Wallet Documentation

This issue is part of a series to demonstrate the wallets features.

Using Notaries (draft)

Wallet Howto 2 Using Notaries (draft) A5023d27b0e3fce3ee0b12b79e7e337ce 2014-10-17 14:37:51

Choosing Notaries

The wallet is kept rather simple as in both the functionality if provides and the code implementing it. We can verify by simply trying that the advertised logic works as expected.

This could be enough to just use it. But how can we be sure that there are no bad surprises lurking?

Examining the code reveals: The wallet's balance is kept in a simple SQL table. It would be at a single individual discretion to issue a statement in some arcane computer language termed SQL to change the balance.

Whom could Alice and Bob trust to maintain the wallet? There is no reasonable choice: Assuming only Alice and Bob care about a particular issue, both had an incentive to cheat and hence would not trust the other one to have physical access to the underlying database. Relying on a single third party to mediate only shifts the risk around.

A consensus protocol is needed to assure both peers the other will not cheat, and to avoid having to route the transaction and trust fallible third parties with data.

Consensus Protocol

A popular consensus protocol these days is Bitcoin. The Bitcoin protocol ensures that C=everyone can verify the exchange. This makes it rather hard (though not completely impossible) to cheat. Unfortunately it's rather slow, expensive, requires an ever growing so called block chain and maybe A+B don't really need this much followers on their private business.

The better alternative is to mimic double entry bookkeeping.

Using pen and paper Alice and Bob would each keep their own books. Both Alice and Bob actively replicate the calculation: they archive their receipts and maintain their own idea of the balance. To avoid an ever growing archive they periodically verify consensus about the current balance. At this point old receipts can be safely thrown away. Thus Alice and Bob can reach consensus without having to trust any other party.

That's what we do. Just the verification period we use is rather short: just one transaction. The wallet will hold on receipts longer than technically required: until the user actually requests their disposal.

We need to introduce some terms here: The electronic equivalent the "pen and paper" is a device, e.g., a users smart phone including a software stack. We term it the "notary device", for short "notary", here. Alice and Bob's individual wallets are applications of the notary devices. Notaries can be designated and authorized to to broadcast input from a user. Notaries in this special role are called "representative devices" for that user.

Both Alice representative and Bobs representative maintain the whole wallet's SQL database for both their wallets (so in practice this might be just the wallet A uses to send to B and vise versa). They will allow A's representative to control A's wallet and B's representative to control B's wallet only.

As long as A+B continue to act benevolent it should be possible to agree that both know precisely who owns how much of the asset.

Except that is is not that easy. If the connection is gone, you can't send your order. The scientist in you might dive deeper into the topic to learn: this leads to cases which can not be resolved without human intervention. Adding that notary devices may not follow high security standards, factoring in honest mistakes and assuming benevolence and veracity may not be given we skip a few steps for laziness and learn: we need at least five notaries to reliably audit the balance. The solution is known under the name "byzantine fault tolerance" thanks to Leslie Lamport's work. (Remark: byzantine consensus itself requires only four notaries for one faulty; but groups of four degrade badly on the second failing.)

Commissioning Notaries

The wallet's menu has an entry Notaries which has to sections. (Tab the titles to open them.)

At the time of writing this tab is seen as subject to further development. Please bear with me.

The first section allows to attach nick names to the OID's of notaries. This is pure convenience for the wallets user and has no technical use.

The second section lists all notaries commissioned to the wallet and enables two operations:

  1. Enable one more: enter the OID and submit.
  2. Switch one off: push the Off button next in the entry.

Note that the "wallet skin" should notify the user that expansion of the notary set is not allowed when the wallet has a positive balance for any asset. This restriction was introduces to enforce the check against sybil attacks. See below.

Users learn about usable notaries usually from the audit record in to messages and contracts. This is a manual process for now and normally includes additional conversation to inform the user about the security assumptions for the device.

What Is Sybil?

A sybil attack is an attempt to cheat on a group of notaries by providing fake evidence approved by a large enough group of "sock puppet" - notaries under control of the attacker.

This is not an issue for our wallets. As we've seen it is precisely clear which notaries audit which wallet.

When a message is sent from Alice to Bob, her wallet will commission the all notaries of her wallet and all of Bobs wallet to her it. This assures that those message will be deliverable to all relevant notaries but no others.

But what if there is in incoming order claiming a large set of notaries having audited it but Bob does not trust any of them? Bob does not want to accept it.

The underlying replication protocol in BALL can not simply reject such messages since the decision depends on the application semantics.

Therefore the wallet must account for this case. Beware: currently it will reject all possibly sybil orders.

The predicate we are currently using might not be the final one: we classify as possibly sybil according to the relationship to the applicable ricardian contract since the latter is supposed to define the instrument and the managing parties. If size of the notary set of the incoming message exceeds double the size of notary set commissioned to audit the asset, it is possibly sybil. This leaves control of the notary set to 50% into the hands of the issuer. Enough to block fraudulent orders but not enough to create them.

Nevertheless will obviously lead to situations where Bob does not share enough notaries with an instrument to receive an order. The only way to transfer a value among them in this situation is to create an intermediate wallet acting like an exchange. This intermediate would hold the foreign instrument and issue derived instrument within a notary set compatible to Bob.

Don't care too much about typos etc. in these memos: those can not be updated anyway.