-----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-----