Fwd: [gsc] Digital cache with extended features

[Steve Schear]

[Some interesting thinking going on.  Wasn't there some similar ideas 
presented/published at a past FC conference?]

Subject: [gsc] Digital cache with extended features
Date: Sun, 06 May 2007 12:57:08 +0300
From: George Hara <georgegabrielhara at fastmail.fm>
Reply-To: gold-silver-crypto at rayservers.com
To: gold-silver-crypto at rayservers.com

It seems that, finally, the pieces fit together, and although the design
is not as good as for account based systems, it's good enough.

I have been pondering for some time about digital cash, but the pieces
never fit. However, with a special design, it's possible to integrate
the necessary features in digital coins.

Basically, it's necessary for the owner of a coin to create the coin
(core), blind it and send it to the mint for signing. In the core, the
user must include a hash for a "coin appendix". The coin appendix
includes various information, but the most important is the asymmetric
public key pair of the recipient.

The coin appendix is not sent to the mint so that it would not serve
later to associate exchanges. However, when a coin is exchanged, the
coin appendix must be sent to the mint. And since its hash is already in
the signed coin, it's certain that the correct coin appendix is
associated with the coin.

The mint guarantees to exchange the coin only if the signature of the
exchange request is verified by the key pair which is in the coin
appendix.

This way, the spender can be sure that only the intended recipient can
later spend the coin, and also have the best thing next to a proof of
payment. If an online store publishes its public key pair, then even if
the store claims to never have received the coin, the spender can simply
publish coin (note that only the store can spend the coin, so everyone
can see the coin) and tell the store to take it.

This methods provides two features in one step: proof of payment and
ability of organizations to secure every coin they receive with the
public identity of the organization (not of individual members).

A problem of this method is that the mint can monitor how much currency
a specific digital identity exchanges. Of course, the mint can't know
the total amount of currency received by a digital identity because
there is no need to reissue a coin, and the recipient might never
exchange some coins he received.

Of course, everybody can just change their asymmetric key pair, but
since they need to publish it, it can still be monitored.

Now, there is certainly no need to use identities for recipients, but in
practice most people would do it.

The coin appendix could also contain a descriptor of its inheritors. But
the problem here is that the coin would have to be put in an escrow
service. It's not a problem if anybody sees it, because only it's
current owner can exchange it, and in the future (after a date specified
in the descriptor) only its intended inheritors can exchange it.

The owner has to consider that if he still lives when the coin is about
to enter its inheritable time frame, he must exchange it before that
time and set a new date for inheritance.

The coin appendix could also include an escrow identity. The mint must
then guarantee to exchange the coin only if it's accompanied by a signed
certificate from the escrow service.

The coin appendix could also include a recovery identity, usually that
of the original owner. This way, if the recipient never uses the coin
because he dies, for example, the spender can take it back after a
specified date. But this means that users must reissue the coins (for
themselves) they receive, before the recovery date comes. Sure, the
recovery date could be a year after the payment, but that still means
that there has to be a reissue.

The actual implementation of this design, requires two independent parts
of the coin appendix, and therefore two hashes:
* One part which contains the identity of the owner of the coin. This
part is sent to the mint when the owner spends the coin.
* One part which contains the identities of the inheritors of the coin.
This part is sent to the mint when an inheritor reissues the coin.
This way, inheritors are visible to the mint only when they actually
inherit.

All nice and cozy, but this design means that each transaction would
take on average 1 to 2 seconds for the mint, plus about 8 times more
traffic than for account based systems. (This considers that coin
denominations are power of 2, so as to minimize the number of coins from
each transaction.)

One thing I am still unable to solve is how to hide coins. With account
based systems it is simple: each "visible" account from the identity
manager application had, automatically created, a hidden account (well,
rather data which looked random to anyone without the right passphrase).

I still have to think about these things to see if it's a path worth
pursuing.

(http://www.gardenerofthoughts.org/ideas/axiomaticid/digitalcache.htm)

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com