From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 6 Dec 1998 03:55:55 +0800
To: cypherpunks@cyberpass.net
Subject: Wei Dei's "b-money" protocol
Message-ID: <199812051937.TAA12780@server.eternity.org>
MIME-Version: 1.0
Content-Type: text/plain




Wei Dei recently announced (on cypherpunks) his "b-money, a new
protocol for monetary exchange and contract enforcement for
pseudonyms".

Below is the text of his proposal.

Comments to follow.

Adam

======================================================================
http://www.eskimo.com/~weidai/bmoney.txt
======================================================================

I am fascinated by Tim May's crypto-anarchy. Unlike the communities
traditionally associated with the word "anarchy", in a crypto-anarchy the
government is not temporarily destroyed but permanently forbidden and
permanently unnecessary. It's a community where the threat of violence is
impotent because violence is impossible, and violence is impossible
because its participants cannot be linked to their true names or physical
locations.

Until now it's not clear, even theoretically, how such a community could
operate. A community is defined by the cooperation of its participants,
and efficient cooperation requires a medium of exchange (money) and a way
to enforce contracts. Traditionally these services have been provided by
the government or government sponsored institutions and only to legal
entities. In this article I describe a protocol by which these services
can be provided to and by untraceable entities.

I will actually describe two protocols. The first one is impractical,
because it makes heavy use of a synchronous and unjammable anonymous
broadcast channel. However it will motivate the second, more practical
protocol. In both cases I will assume the existence of an untraceable
network, where senders and receivers are identified only by digital
pseudonyms (i.e. public keys) and every messages is signed by its sender
and encrypted to its receiver.

In the first protocol, every participant maintains a (seperate) database
of how much money belongs to each pseudonym. These accounts collectively
define the ownership of money, and how these accounts are updated is the
subject of this protocol.

1. The creation of money. Anyone can create money by broadcasting the
solution to a previously unsolved computational problem. The only
conditions are that it must be easy to determine how much computing effort
it took to solve the problem and the solution must otherwise have no
value, either practical or intellectual. The number of monetary units
created is equal to the cost of the computing effort in terms of a
standard basket of commodities. For example if a problem takes 100 hours
to solve on the computer that solves it most economically, and it takes 3
standard baskets to purchase 100 hours of computing time on that computer
on the open market, then upon the broadcast of the solution to that
problem everyone credits the broadcaster's account by 3 units.

2. The transfer of money. If Alice (owner of pseudonym K_A) wishes to
transfer X units of money to Bob (owner of pseudonym K_B), she broadcasts
the message "I give X units of money to K_B" signed by K_A. Upon the
broadcast of this message, everyone debits K_A's account by X units and
credits K_B's account by X units, unless this would create a negative
balance in K_A's account in which case the message is ignored.

3. The effecting of contracts. A valid contract must include a maximum
reparation in case of default for each participant party to it. It should
also include a party who will perform arbitration should there be a
dispute. All parties to a contract including the arbitrator must broadcast
their signatures of it before it becomes effective. Upon the broadcast of
the contract and all signatures, every participant debits the account of
each party by the amount of his maximum reparation and credits a special
account identified by a secure hash of the contract by the sum the maximum
reparations. The contract becomes effective if the debits succeed for
every party without producing a negative balance, otherwise the contract
is ignored and the accounts are rolled back. A sample contract might look
like this:

K_A agrees to send K_B the solution to problem P before 0:0:0 1/1/2000.
K_B agrees to pay K_A 100 MU (monetary units) before 0:0:0 1/1/2000. K_C
agrees to perform arbitration in case of dispute. K_A agrees to pay a
maximum of 1000 MU in case of default. K_B agrees to pay a maximum of 200
MU in case of default. K_C agrees to pay a maximum of 500 MU in case of
default.

4. The conclusion of contracts. If a contract concludes without dispute,
each party broadcasts a signed message "The contract with SHA-1 hash H
concludes without reparations." or possibly "The contract with SHA-1 hash
H concludes with the following reparations: ..." Upon the broadcast of all
signatures, every participant credits the account of each party by the
amount of his maximum reparation, removes the contract account, then
credits or debits the account of each party according to the reparation
schedule if there is one.

5. The enforcement of contracts. If the parties to a contract cannot agree
on an appropriate conclusion even with the help of the arbitrator, each
party broadcasts a suggested reparation/fine schedule and any arguments or
evidence in his favor. Each participant makes a determination as to the
actual reparations and/or fines, and modifies his accounts accordingly.

In the second protocol, the accounts of who has how much money are kept by
a subset of the participants (called servers from now on) instead of
everyone. These servers are linked by a Usenet-style broadcast channel.
The format of transaction messages broadcasted on this channel remain the
same as in the first protocol, but the affected participants of each
transaction should verify that the message has been received and
successfully processed by a randomly selected subset of the servers.

Since the servers must be trusted to a degree, some mechanism is needed to
keep them honest. Each server is required to deposit a certain amount of
money in a special account to be used as potential fines or rewards for
proof of misconduct. Also, each server must periodically publish and
commit to its current money creation and money ownership databases. Each
participant should verify that his own account balances are correct and
that the sum of the account balances is not greater than the total amount
of money created. This prevents the servers, even in total collusion, from
permanently and costlessly expanding the money supply. New servers can
also use the published databases to synchronize with existing servers.

The protocol proposed in this article allows untraceable pseudonymous
entities to cooperate with each other more efficiently, by providing them
with a medium of exchange and a method of enforcing contracts. The
protocol can probably be made more efficient and secure, but I hope this
is a step toward making crypto-anarchy a practical as well as theoretical
possibility.

======================================================================