147 lines
8.1 KiB
Markdown
147 lines
8.1 KiB
Markdown
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.
|
|
|
|
-------
|
|
|
|
Appendix A: alternative b-money creation
|
|
|
|
One of the more problematic parts in the b-money protocol is money
|
|
creation. This part of the protocol requires that all of the account
|
|
keepers decide and agree on the cost of particular computations.
|
|
Unfortunately because computing technology tends to advance rapidly and
|
|
not always publicly, this information may be unavailable, inaccurate, or
|
|
outdated, all of which would cause serious problems for the protocol.
|
|
|
|
So I propose an alternative money creation subprotocol, in which account
|
|
keepers (everyone in the first protocol, or the servers in the second
|
|
protocol) instead decide and agree on the amount of b-money to be created
|
|
each period, with the cost of creating that money determined by an
|
|
auction. Each money creation period is divided up into four phases, as
|
|
follows:
|
|
|
|
1. Planning. The account keepers compute and negotiate with each other to
|
|
determine an optimal increase in the money supply for the next period.
|
|
Whether or not the account keepers can reach a consensus, they each
|
|
broadcast their money creation quota and any macroeconomic calculations
|
|
done to support the figures.
|
|
|
|
2. Bidding. Anyone who wants to create b-money broadcasts a bid in the
|
|
form of <x, y> where x is the amount of b-money he wants to create, and y
|
|
is an unsolved problem from a predetermined problem class. Each problem in
|
|
this class should have a nominal cost (in MIPS-years say) which is
|
|
publicly agreed on.
|
|
|
|
3. Computation. After seeing the bids, the ones who placed bids in the
|
|
bidding phase may now solve the problems in their bids and broadcast the
|
|
solutions.
|
|
|
|
4. Money creation. Each account keeper accepts the highest bids (among
|
|
those who actually broadcasted solutions) in terms of nominal cost per
|
|
unit of b-money created and credits the bidders' accounts accordingly.
|