1994-06-19 - Hardware RN generators, data volume requirements

Header Data

From: “Pat Farrell” <pfarrell@netcom.com>
To: cypherpunks@toad.com
Message Hash: dd0d7301c95c24b070f4d1f755e3c6f1c86b38e1a4dee260f33cf81ce5816480
Message ID: <49814.pfarrell@netcom.com>
Reply To: N/A
UTC Datetime: 1994-06-19 17:54:08 UTC
Raw Date: Sun, 19 Jun 94 10:54:08 PDT

Raw message

From: "Pat Farrell" <pfarrell@netcom.com>
Date: Sun, 19 Jun 94 10:54:08 PDT
To: cypherpunks@toad.com
Subject: Hardware RN generators, data volume requirements
Message-ID: <49814.pfarrell@netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


I'm quite happy about the volume and quality of responses I've
received. So here is another question:

What data generation rate should we aim for?

I guess I should be more precise, given that costs are usually
directly proportional to data rates, what are the minimum,
hoped for, and high end data rates needed?

For example, Tony Patti's RANGER has a very high data rate,
but is big and costs more than two cases of beer.

Is a good bit a second sufficient? 100 b/s? ???

Right now, I've only generated a few of Pr0duct Cypher's magic money
tokens. So if I had a daemon process collecting bits for me in the
background, then 3600 per hour is plenty.

I am sure that when Perry uses digicash for online trading of eurodollars,
he (and his user community) will need orders of magnitude more. But I'd
expect them to be willing to pay at least an order of magnitude more
for the gear too.

I'd like to hear grounded justification for rates, and/or
a rate/dollar tradeoff.

Don't worry about the exact monetary exchange rates. Estimates in
bits per second per case of beer are accurate enuff for this
level of design.

Thanks
Pat

p.s. I just got up to the chapter of Bruce's _Applied Crypto_ that
addresses some of the approaches to this. It really is a FAQ for
serious cypherpunks.

Pat Farrell      Grad Student                 pfarrell@cs.gmu.edu
Department of Computer Science    George Mason University, Fairfax, VA
Public key availble via finger          #include <standard.disclaimer>





Thread