-minor corrections to the corrections

This commit is contained in:
Christian Grothoff 2015-10-08 20:47:17 +02:00
parent 2ce2c1dac7
commit 99865ad6d4

View File

@ -160,8 +160,8 @@ believe needs a payment system with the following properties:
%Taxation is necessary for the state to
%provide legitimate social functions, such as education. Thus, a payment
%system must facilitate sales, income and transaction taxes.
This requires that merchants, or anybody receiving electronic transfers,
is easily identifiable, so that the state can ensure that its
This requires that merchants are easily identifiable and that
an audit trail is always generated, so that the state can ensure that its
taxation regime is obeyed.
\item[Verifiability]
The payment system should try to minimize the trust necessary between
@ -203,16 +203,22 @@ We give a concise example of how these properties interact:
A customer may want to pay \EUR{49,99} using a \EUR{100,00} coin.
the system must thus support giving change in the form of spendable coins,
say a \EUR{0,01} coin and a \EUR{50,00} coin.
A merchant cannot simply give the customer their coins in another transaction
A merchant cannot simply give the customer their coins in another transaction,
however, as this reverses the role of merchant and customer, and
our taxability requirement would deanonymize the customer.
our taxability requirement would deanonymize the customer. The customer
also cannot withdraw exact change from his account from the mint, as this
would allow the mint to link the identity of the customer that is revealed
during withdrawal to the subsequent deposit operation that follows shortly
afterwards.
Instead, the customer should obtain new freshly anonymized coins that cannot be
linked with this transaction, the original \EUR{100,00} coin, or each other.
Instead of using cryptographic methods like $k$-show signatures
\cite{brands1993efficient} to achieve divisibility,
Instead of using cryptographic methods like $k$-show
signatures~\cite{brands1993efficient} to achieve divisibility,
Taler's fractional payments use a simpler, more powerful mechanism.
In Taler, a coin is not simply a unique random token, but a private key.
In Taler, a coin is not simply a signed unique random token, but signature
over the hash of a public key where the private key is only known to the owner
of the coin.
A customer transfers currency from a coin to a merchant by cryptographically
signing a deposit message with this private key. This deposit message
specifies the fraction of the coin's value to be paid to the merchant.
@ -221,11 +227,11 @@ a customer to exchange the residual value of the exchanged coin for
unlinkable fleshy anonymized change.
Taler mints ensure that all transactions involving the same coin
do not exceed the total value of the coin, thereby
requiring that merchants process transactions online.
do not exceed the total value of the coin simply by
requiring that merchants clear transactions immediately with the mint.
This improves dramatically on systems that support offline merchants with
cryptographic threats to deanonymizing customers who double-spend, like
restrictive blind signatures \cite{brands1993efficient}.
restrictive blind signatures~\cite{brands1993efficient}.
In such schemes, if a transaction is interrupted, then any coins sent to
the merchant become tainted, but may never arrive or be spent.
It becomes tricky to extract the value of the tainted coins without linking
@ -519,7 +525,7 @@ available for signing, each representing a different coin
denomination.
These coin signing keys have an expiration date, before which any coins
signed with it must be spent or refreshed. It follows the mint can
signed with it must be spent or refreshed. This allows the mint to
eventually discard records of old transactions, thus limiting the
records that the mint must retain and search to detect double-spending
attempts. Furthermore, the mint is expected to use each coin signing