|
Digital cash will not be implemented in
Vela mainly because the backing assets would still be
centralized, so an anonymous currency doesn't seem to help gain
much freedom.
Insider attacks are very dangerous for the same
reason. Although their risk can be reduced by using several
distinct "sub-mints" to sign the issued coins, this
would dramatically increase the costs for both the mint and for
the users (who now would have to contact online all "sub-mints"
to be sure that a coin has been signed by all).
Legend
Mint: the entity which creates digital coins.
Minting: the creation of new coins by the mint.
The creation is made by simply signing blinded coin cores.
Blinding: operation which allows a digital
signature to be applied on some data, without knowing the actual
data, but knowing only an "encrypted" form of the data.
After unblinding, the signature verifies as if the actual data
was signed.
Coin core: data which describes a digital coin.
This is to be blinded and signed by the mint.
Exchange / spend / payment: in exchange for some
given digital coins, the mint creates new coins whose total value
is the same as the total value of the given coins, minus the
minting fee. The given coins are marked as spent and can never be
spent again. The returned coins are split in two parts: the part
which is given to another entity as payment, and the remainder
part.
Description
There are all sort of ways to do digital
cash, but they all break trust at some point. Signing makes trust
hold in adverse environments.
This is a digital cash protocol which provides
anonymity.
The protocol assures that if any party involved
in a payment makes false claims, the real facts can be
cryptographically proven. The mint, the payer, the recipient,
none can lie about a payment and get away with it.
For example, the mint can't lie about a specific
coin to have been spent. This is because the coin has an owner,
and the mint may mark the coin as spent only if it has a signed
document from the coin owner, document which specifies that the
coin is to be exchanged into another coin (owned by someone
else). Basically, the mint can't deny redemption to anyone who
presents a digital coin signed by the mint.
The most important feature of the protocol is
that only the recipient of a payment knows the identifiable form
of the coins he will receive, and therefore is under no danger of
having his money frozen by the mint, at least not with a greater
chance than the mint randomly stating that any coin is frozen.
This means that any coin you own can "rust"
in your ewallet, and the mint would be unable to ever freeze it
or to identify you by examining it when you spend it.
But anonymity is useful, on a large scale, only
when coupled with the ability of the spender to prove that he did
pay the recipient. The spender can't prove that the recipient has
received the digital cash, but only that he has sent the digital
cash to the recipient, and that nobody but the recipient can
spend that digital cash.
If the recipient claims that he didn't receive
the digital cash, the spender can simply give the digital cash to
the recipient, in an arbitrated context. As such, the arbitrators
can know with cryptographic certainty that the recipient has
received a specific amount of digital cash from the spender, and
therefore he must fulfill the contract which is attached to the
payment document.
The spender can remain unknown to the recipient,
if he wants that. Also, the mint is unable to link the spender to
the recipient, not even by IP. This is because the recipient
never communicates with the mint. Also, the recipient never has
to reissue the coins he receives, and therefore the mint can't
even connect a spender and a recipient by matching identical
amounts of digital cash which are being transacted in a short
time frame.
The anonymity is achieved by using temporary
asymmetric key pairs, symmetric encryption keys, and session
identifiers. The only necessary long-term digital identities are
the presentation identities of the recipient and of the mint,
which are used only for communication.
The existence of the long-term presentation
identity of the recipient doesn't imply that the recipient's
physical identity must be known. However, in the absence of known
ways to physically reach the recipient, the proof of payment
becomes useless. Therefore, spenders should generally spend
digital cash only to the presentation identities of the entities
which can be physically reached.
The costs of the protocol are high, but the
result is worth it. In practical terms, a payment made from a PDA
and received on a PDA needs about 10...30 seconds to be initiated
by the spender (because a temporary asymmetric key pair is
created), 10...30 seconds to be accepted by the recipient
(because a temporary asymmetric key pair is created), and 2
seconds for minting. An organization which needs to receive
digital cash for their group identity, don't have to create a
temporary asymmetric key pair, but simply use a predefined group
identity which is not known outside the organization.
All minted coins are signed with two asymmetric
key pairs in order to ensure that if a key pair is cracked (by
sheer luck), the cracker can't simply mint himself any amount of
digital cash.
If the protocol is used only to store and pay
large amounts of digital cash, the costs are acceptable.
On average, the mint could process some 40'000
spends per day, per computer, but the protocol is scalable. A
network traffic redirector application which runs on a dedicated
computer may redirect the spend requests which are sent to the
mint, to other computers which execute the spend requests. This
way, the minting performance is multiplied by the number of
computers.
Coin denomination
Each coin must have a specific denomination.
Ideally, there would only have to be a denomination of 1 unit of
digital currency. However, in order to exchange large amounts of
currency, a large amount of coins would be required, and this
would mean a large amount of signatures to apply and a large
amount of data to transfer through the Internet.
Therefore, an optimal denomination mechanism is
one which minimizes the number of coins returned by an exchange.
This can be achieved by using power of 2 denominations.
Consider that "coin weight" is a
number from 1 to 32. The associated coin denomination is equal
with 2 ^ "weight" – 1.
Now, any value between 0 and 2 ^ 32 – 1
can be represented as an array of 32 weights, where each weight
can be either present or absent. This means that each weight is
represented by the bit with the index equal with "weight"
– 1, from the amount of currency to represent in
denominated coins.
A unit of currency which is small enough to be
useful in most payments, is 1 / 100 grams of gold. This means
that the biggest denomination of a coin is about 42 millions
grams of gold.
Technical description
The service descriptor of the mint contains 2
sets of 32 asymmetric key pairs (which are used only for signing
coins). There are 2 sets because a coin is signed by one identity
from each set, so that if a key pair is cracked (by sheer luck),
the cracker can't simply mint himself any amount of digital cash.
The position of each key pair, in the set, is
equal with the coin weight represented by the key pair, and is
used only to sign coins of the same weight.
Various details
Coins in circulation
The coins in circulation are the coins which
were ever minted but which have not yet expired.
The mint must keep a history of all the coins in
circulation, and make them public in order for anyone to see what
is the total amount of currency in circulation, and compare that
with the total value of the backing medium of the currency. This
can happen because all these coins are blinded (and the blinding
factor is known only to the owner of each coin).
If anyone can show a coin in circulation which
is not published, that would be proof that the mint has minted
more coins than it publicly states. Of course, this could also
indicate that some of the asymmetric key pairs used for signing
coins, have been cracked, but this is unlikely.
Coin expiration
The minting identity has an expiration time.
After that time, the identity may not be used to sign coin cores,
and all coins which were signed with it may never be spent. When
a minting identity expires, all coins signed by it expire.
Expired coins are not coins in circulation.
Therefore, the mint may delete them and reuse their associated
backing medium for minting other coins.
Reuse of the backing medium
The total value of the coins in circulation must
be smaller than (or equal with) the total value of the backing
medium (of the coins).
The mint can reuse at any time the backing
medium in value equal with the difference between the total value
of the backing medium and the total value of the coins in
circulation, for minting other coins.
Double-spending protection
The mint must keep a history of the spent coins,
so that they would not be spent again. These coins must be kept
in the history until each they expire, after which they may be
deleted.
Reputation services
Reputation services can collect proofs of
payment in order to calculate reputation scores for merchants.
Protocol
Step 1
The spender generates new temporary asymmetric
key pair to use to sign documents sent to the recipient.
The spender creates a spend-intent request which
includes:
A spender-recipient session identifier.
A temporary symmetric encryption key (with
which the recipient will encrypt his responses for the spender).
The public part of the temporary asymmetric
key pair.
The currency name to spend.
The currency value to spend.
The minting fee. The mint will check if
this is the fee it has to charge for fulfilling the spend
request, and if it's not, it rejects the transaction.
The time of creation of the request.
The contract (= reason of payment).
The spender sends the signed request (with his
temporary asymmetric key pair) to the payment recipient.
The request is encrypted for the long-term
communication identity of the recipient. The session identifier
of the encrypted envelope is the spender-recipient session
identifier.
Step 2
The recipient generates new temporary coin-owner
identity to represent the owner of the coins he will have when
the spend will be settled. Organizations which want to have the
coins owned by their group identity, must not generate the
temporary identity, but use their existing group identity to
represent the owner of the coins.
The recipient creates the coin cores with the
total value equal with the total value of the coins which he will
receive (= own when the payment will be settled). A coin core
must contain:
A hash for a "coin owner appendix".
The appendix includes the public part of the digital identity
which represents the owner of the coin. The recipient sends this
appendix only to the mint, and only when he wants to spend the
coin. The mint guarantees to allow the coin to be spent only if
the signature of the spend request is verified by the owner
identity.
A hash for a "coin inheritor
appendix". The appendix describes the inheritors of the
coin, and includes the public part of the digital identity of
each inheritor, and the date after which each inheritor may
spend the coin. The inheritance information is not put in the
owner appendix so that the inheritors would be visible to the
mint only when they actually spend the inherited coin. The
recipient never sends this appendix to the mint.
The recipient creates a response which contains:
The recipient sends the signed response (with
his long-term communication identity) to the spender.
The response is encrypted with the temporary
symmetric encryption key from the spend-intent request. The
session identifier of the encrypted envelope is the
spender-recipient session identifier.
Inheritance note
The inheritable coins have to be put in an
escrow service. It's not a problem if anybody sees the coins,
because only their owner can spend them, and after the
inheritance date its inheritors too.
The coin inheritor appendix is sent by the owner
of the coin only to the escrow service. The escrow service sends
the coin to its inheritors when they can inherit the coin.
When an inheritor wants to spend his inherited
coin, he has to send the inheritor appendix to the mint, together
with the coin.
The owner has to consider that if he still lives
when the coins are about to enter their inheritable time frame,
he must spend them (to himself) before that time and set a new
date for inheritance.
Step 3
The spender creates the remainder coin cores
which he will own after the payment is settled. The remainder
value is equal with the total value of the coins to spend minus
the value which is intended to be paid, minus the minting fee. A
coin core must contain:
The spender creates a spend request which
includes:
The coin owner appendix for each coin to
spend.
The blinded coin cores from the recipient,
also blinded by himself. The double blinding is necessary so
that if the mint and the recipient collude, they would be unable
to know who the spender is.
The blinded remainder coin cores, also
blinded by himself.
The spender sends the signed request (with the
identities which represent the owners of the coins to spend) to
the mint.
The request is encrypted for the long-term
communication identity of the mint. The session identifier of the
encrypted envelope is the spender-mint session identifier.
Step 4
The mint checks if the spend request is signed
by all the identities which represent the owners of the coins to
spent.
The mint guarantees to allow coins to be spent
only if the signature of the spend request is verified by the
owner identity of each coin, or if the coins are in their
inheritable time frame and the signature of the spend request is
verified by the identity of an inheritor of the coins (the
inheritor must be able to inherit all the coins from the spend
request).
If the public part of the long-term presentation
identity of the spender was specified in the spend request, the
mint creates a proof of spend which contains:
The time when the spend was made.
The public part of the long-term
presentation identity of the spender.
The spent currency name.
The spent currency value.
The mint creates a spend response which
includes:
The (unencrypted) spend request.
The signed proof of spend (with its
long-term communication identity). This is not signed with the
rest of the response.
The signed coins to spend (with its minting
identity) from the spend request.
The signed remainder coins (with its
minting identity) to spend from the spend request.
The mint sends the signed response (with its
long-term communication identity) to the spender.
The response is encrypted with the temporary
symmetric encryption key from the spend request. The session
identifier of the encrypted envelope is the spender-mint session
identifier.
Step 5
The spender sends the (unencrypted) response
received from the mint, to the recipient.
The response is encrypted with the temporary
symmetric encryption key from the spend-intent request. The
session identifier of the encrypted envelope is the
spender-recipient session identifier.
The spender must keep all temporary resources
until the payment is settled.
Step 6
The recipient unblinds the coins he received and
stores them.
Optional actions (which prove that the
recipient has received the digital cash sent by the spender)
The recipient creates a spend-settled response
which contains:
The recipient sends the signed response (with
his long-term communication identity) to the spender.
The response is encrypted with the temporary
symmetric encryption key from the spend-intent request. The
session identifier of the encrypted envelope is the
spender-recipient session identifier.
The recipient may clean-up all temporary
resources, but this is automatically done some time later, 7 days
by default.
Alternative
There is an alternative method which provides
some very interesting features: escrow and recovery.
Escrow means that mint would accept to spend the
escrowed coins only if they spend request is accompanied by a
certification from the escrow service.
Recovery means that if the recipient doesn't
reissue the received coins, the spender can himself reissue the
coins. This is useful if the recipient becomes unable to fulfill
the action for which he is being paid. This means that the
recipient must reissue the coin that he receives, before the
recovery date comes. Of course, the recovery date could be a year
after the payment, but that still means that there has to be a
reissue.
In this protocol, the spender (not the
recipient) creates the coin cores, blinds them and sends them to
the mint for signing.
The coin core may contain a hash for a "coin
escrow appendix". The appendix includes the presentation
identity of the escrow service.
The coin core may contain a hash for a "coin
recovery appendix". The appendix includes the public part of
the digital identity of the recovery agent.
No coin appendix is sent to the mint so that it
would not serve later to associate spends. However, when a coin
is spent, the coin appendix must be sent to the mint. Since its
hash is already in the signed coin, it's certain that the correct
appendix accompanies the coin.
The critical problem of this method is that the
spender knows the digital identity of the owner of the coins, and
can therefore convince the mint, under whatever fantasist
reasons, to freeze those coins.
Chosen text attack
To protect against chosen text attacks, the
random data from coin cores has to be replaced with hashes of
random data. The hashes are checked by the mint, against the
provided random data, on exchange, and invalid coins are
rejected.
This mechanism still allows chosen text attacks,
but it makes them expensive because invalid coins can't be
exchanged, so every chosen coin core costs at least one unit of
currency.
Note the one unit of currency should not have a
value which is too small, or else the attack would be cheap.
Distributed mint
A group of organizations / individuals can get
together and create a (federated) mint, and issue one kind of
digital cash. Each member of the federation has equal legal
rights, within the federation, and is considered trustworthy, by
the other members, to sign coins.
However, this trustworthiness is (and must be)
limited. No single member can issue digital coins which can be
redeemed. In order for a coin to be redeemable, it must be signed
by all members of the federation.
This mechanism not only protects the currency
from insider attacks and from corrupt members of the federation,
but it also protects the currency from the compromised computers
of the members. It is impossible for a single member of the
federation to forge (redeemable) coins because a valid
(redeemable) coin must be signed by all members of the
federation.
When a user makes a spend request to the mint,
he must give some coins he has in order to obtain others (with
different properties). Each coin he gives must be sent to all
members of the federation.
Each member verifies that each coin he receives
was signed by all members (himself included). Finally, he marks
the received coin as spent, and signs the coin which is to be
sent back to the user.
The disadvantage of a distributed mint is its
cost: the mint needs a different computer for every member, and
users need to be able to access, through the Internet, the
computers of all members and must wait for all to respond with
the signed coins.
|