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!