From: Hal <hfinney@shell.portal.com>
To: cypherpunks@toad.com
Message Hash: d8f5e865994db055db48ae02e56547f6e481639ff2b19335cb9b6356a27465f6
Message ID: <199407221914.MAA18128@jobe.shell.portal.com>
Reply To: N/A
UTC Datetime: 1994-07-22 19:13:21 UTC
Raw Date: Fri, 22 Jul 94 12:13:21 PDT
From: Hal <hfinney@shell.portal.com>
Date: Fri, 22 Jul 94 12:13:21 PDT
To: cypherpunks@toad.com
Subject: Re: Voice/Fax Checks
Message-ID: <199407221914.MAA18128@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain
JWS writes:
>Well here are the answers that I'm working with in my model:
>First, what you set up has to work off-line. At the same time, validation,
>by its very nature, is a process that can only be accomplished online. The
>part of my code that I am in the middle of right now (and strugling with)
>uses a distributed dynamic hashing scheme (with some attempt at periodic
>space minimalization [this is what is making it tricky]) whereby information
>is recorded in the public system such that if one part of a bill is used
>twice, the cheat's identity is revealed.
>[...]
>For types of small transactions that will be executed frequently, the
>best idea is to establish accounts. In my system, when ever an agent
>enters somebody else's computer, it gives the local wizard (the agent
>with the final say on computational cycles, storage space, and
>communications) a deposit which neither the agent nor the wizard can
>cash without agreement by both [do public validation and recording
>but hold off on the last steps which allow the wizard to use the money].
>The money is thus recorded globally as having been spoken for. Then, for
>all transactions on the local machine, the agent simply uses its local
>account, just as anybody would in a much simpler bank-based protocol,
>like the ones we have now.
This seems like a good approach for a lot of cases. You end up having
three classes of transactions: small, medium, and large, with slightly
different strategies for each. For large, you do on-line checking; for
medium, you detect double-spending after the fact and use crypto to find
his identity; and for small you set up an account and dip into that a bit
at a time. I am curious about whether you are focussing more on some size range
in your plans.
One problem I still see is the small transaction where you don't tend to
use the same provider again and again. On the net there are a few sites
(well, quite a few, I suppose) which are heavily used, but there are a
lot of places I might like to just browse through. Paying a penny per
site isn't going to bother me much, but if I have to set up an account
for each one ahead of time I'm probably not going to bother. So I still
think there are problems with the fractional-cent-per-web-site model
which I have been hearing about.
>I don't agree on this point. I prefer license based e-cash which is modified
>on each transaction (and unfortunatelly gets slightly bigger -- the downside
>of this method). If we're going to make the conversion to ecash, we might
>as well make it as powerful as mathematics will allow.
Is this an approach where you determine to whom you will be sending the cash,
then make it into a "check" which can only be spent by that recipient?
Doesn't that require the bank's (cash issuer's) help? Or is this something
else?
Hal
Return to July 1994
Return to “solman@MIT.EDU”