[Lucrative-L] lucrative accounts revisited

[Patrick Chkoreff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday, April 24, 2003, at 10:28 AM, R. A. Hettinga wrote:

> ... Since we're literally moving title to an asset around the net 
> instead
> of changing records in a database somewhere (remember the
> double-spend database at the mint is only *redeemed* notes, not
> copies of what's out there), ...

I am taking a different approach, where the server stores RIPEMD-160 
hashes of all the redeemable coins "out there."  It completely forgets 
redeemed coins.

Because the server only stores hashes, the entire contents of the 
server database could literally be published on the web in streaming 
live form without seriously reducing the security of the system.  Of 
course, this would be stupid because it would needlessly invite 
collision attacks, but in principle the idea of avoiding security 
through obscurity could be applied to the database itself.  But then, 
why not hide the hash file behind a Unix password, and behind an 
AES-256 key while we're at it?  :-)

So a coin consists of an lseek position in the server data file, 256 
bits of random gibberish, and 64 bits representing the amount.  When 
you present the coin to the server, the server hashes it and looks at 
the given lseek position.  If it matches, it manufactures a new coin at 
some other lseek place and sends it to you.  You store the coin, 
compute the RIPEMD-160 hash yourself, and send that to the server, at 
which point it kills the old coin and enlivens the new coin.

Obviously all the smart folks who talk about storing only the redeemed 
notes and even using probabilistic double-spend detection methods have 
reasons for doing so.  I expect my scheme will be slapped down 
forthwith.  :-)

> Finally, I would also strongly recommend that we try like hell not to
> invent new cryptographic conventions, much less new cryptography,
> here.

You're preaching to the choir here.  I haven't seen any snake oil 
proposals lately (unless I just gave one above.  :-)


> First, crypto is hard. :-), and our chances of actually inventing
> something new that isn't trivially broken on its face is even harder.
> Obviously, if you're one of those big swinging di-, er, big giant
> heads, who actually do the math, understand what cryptography
> protocols do, and see something that's wrong, or that you can do
> better, that's different, but there's a whole lot of time that can be
> wasted in reinventing the wheel here that won't get us to code that
> earns money. ...

Good C libraries for existing crypto protocols are always welcome.  I'm 
just getting Rijndael, RSA, RIPEMD, BBS, etc. into a shape I like.  
Mostly, I don't like routines that declare *anything* on the stack -- 
all of my working space is allocated on a single 4k mlocked page up 
front and Mersenne-twisted before munlock and free.


> Second, and in that vein, there is a whole published language of
> crypto that's already being used, and if we don't use it from the
> outset, nobody will understand us later if we get stuck. In
> particular, a trusted third party, or trusted entity, is "Trent", for
> some reason, probably because Schneier had it in Applied Cryptography
> 10 or 12 years ago. :-).

Ah, Marvin for "medium" considered non-standard.  :-)  OK, Trent it is.


> We should change nomenclature only when we've added to it, yes?
>
> Believe me, we'll get there, especially after we're actually
> operating this code the way we want it to run, at a profit, in an
> open market. That's certainly something that nobody's done before,
> :-), and we're going to have our hands full when we make it happen.

Truly.

- -- Patrick
http://fexl.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqf+F1A7g7bodUwLEQISIgCfTVhs4Q+8xc4w5xuH1z5+DPMb/EAAoK/j
al4Clq6VA/dR5aFIb0ZxPsEe
=pNFb
-----END PGP SIGNATURE-----