December 2003 - cypherpunks-legacy

digital cash/legal tender
by F_GRIFFITH＠CCSVAX.SFASU.EDU 17 Dec '03

17 Dec '03

Legal tender is a quality given by government to certain forms of money such that a creditor who refuses to accept that money in payment of a debt loses certain rights (e.g. to collect further interest. In our system, federal reserve notes are legal tender,your personal check is not. It is acceptability, not government edict wich makes something money. (Note the development of NOW accounts, e.g.). Credit cards are not money. When you use a credit card, you are promising to pay in the future. The merchant sells this promise to the credit card issuer. In order for electronic money to be true cash, it must be able to circulate from Alice to Bob to Carl to Dave without the need to contact the issuing bank. Otherwise, it is merely an electronic check, perhaps anonymous. If Bob must deposit or validate the money first in order to make sure Alice doesn't double spend it, then it is no different from Alice having $200 in her checking account and writing a $150 check to Bob and a $150 check to Carl. The first one who gets it to her bank collects, the other one has it bounced back.

3 3

Re: digital cash/legal tender
by nobody＠alumni.cco.caltech.edu 17 Dec '03

17 Dec '03

F. Griffith argues that a digital cash system in which the cash must be exchanged at the bank between transactions is really just an electronic checking system. It is true that this is an inconvenient attribute of some digital cash systems, but there is still an important difference between these systems and digital checking. The cash exchanges are anonymous. Bob, the merchant, does not know who is sending him (or handing him) the digital cash. With a checking system, OTOH, you know who is giving you the check, because they sign their name to it. There have been some cash proposals which don't require this bank exchange at each step. Barry Hayes had one which was analogous to a check which was endorsed over from one person to the next at each transaction. Alice would write the check to Bob, who would endorse it over to Charlie, who would endorse it over to Delores, and so on. This doesn't sound very anonymous, but Hayes was going to let people use pseudonyms rather than their real names. He used a variation on Chaum's double-spending detec- tion that I posted that long message about to catch people who cheated. This system was described in the AusCrypt proceedings. It's important to be aware of the difference between digital cash and other forms of digital money. Cash protects privacy; most other proposals would impair it. Our goal here, insofar as we can still be said to have one, is to protect privacy. As far as the acceptability of digital cash, there are two issues that I see. One is whether the cash is legal, and the other is whether it would be accepted. My opinion is that if digital cash is or could be made legal, it would be accepted. As others have argued, we have many examples (travelers checks, credit cards) where people accept money substitutes without government backing. As for its legality, I posted some research results on this earlier this year. Until the 1860's, private banks created and circulated their own banknotes. Around the time of the civil war, a 10% tax was created on these notes by the federal government to drive them out of circulation, which it did. This tax is still on the books, but I'm not familiar with its details. The other way banks can issue cash is by holding certain kinds of gold-backed federal certificates, but these certificates don't exist any more. So at this point my conclusion was that it would not be legal for a bank to issue its own cash other than by paying the 10% tax, which was considered prohibitive. Hal Finney hfinney(a)shell.portal.com

1 0

Re: "reputation"
by swc＠uc1.ucsu.edu 17 Dec '03

17 Dec '03

Reputation is not the only thing available to depend upon when using digital cash. Escrow accounts coupled with Shamir sharing can push the difficulty of cheating way beyond where it is profitable. ------------------------------------------------------------------------ Stuart W. Card, Consultant, Card & Associates -- Research & Development Box 153 RR 1 Newport Rd Utica NY 13502 315-735-1717 / FAX -8469 swc(a)uc1.ucsu.edu or cards(a)top.cis.syr.edu "Who is John Galt?"

1 0

uniqueness
by cme＠ellisun.sw.stratus.com 17 Dec '03

17 Dec '03

>what really is our assurance that all these email addresses actually >exist and represent *unique* people? there really is very little currently. I see no way to guarantee uniqueness of the person unless you manage to incorporate some unique characteristic of a person (right hand print, for example) into a digital signature. PEM's key certificates might be an attempt to guarantee uniqueness but even there I can cheat by having a second job under a second name, for example, and getting a certificate in both. - Carl

2 1

solving polynomials modulo P
by L. Detweiler 17 Dec '03

17 Dec '03

Matthew J Ghio suggested an encryption scheme based on polynomials mod P. I haven't looked at this too thoroughly yet, but a quick read seemed to suggest that it relies on the intractability of solving polynomial equations mod P. If so, realize that this is a very tractable problem with efficient (polynomial time) algorithms given by e.g. Knuth. If anyone wants more info I'll post the reference. It's in his sections on computer arithmetic. The algorithm was discovered by a researcher at Bell Labs as I recall; the name escapes me.

1 0

Big Brother stickers..
by ad620＠freenet.buffalo.edu 17 Dec '03

17 Dec '03

I recently had a problem with my internet mailbox and I lost some important posts to the list..ALso, bedcause of lack of time I have had to drop the net..but I read a post a short while back about somebody had a bunch of stickers made up of that gif that says Big Brother INside Would you email me with the price of the stickers..I'm interested in buying some... Thankyou Nick

1 0

RISKS of using email for dcash
by nobody＠alumni.cco.caltech.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [It is with some trepidation that I try, for the third time, to send this to the list. Ever since I tried the first time my email to the list has silently failed. This is pretty strange, given the topic of the mail!] If we have digital cash, we may want to send it through the mail. Sending regular cash through regular mail is not safe, as we all know. The cash could get lost or stolen. With digital cash, stealing can be made less of a problem; it can be encrypted with the public key of the person who wants to receive it. But loss is still a problem. Email is not perfectly reliable. All too often we experience mail bounces, errors, or mysterious disappearances. Given the heterogenous nature of the net and the many systems through which mail must often pass, this is not too surprising. People have to learn to adapt to the vagaries and inconsistencies involved and take special care when they are sending something important. (I've been trying for the last three days to send a particular message (part 7 of a 13-part archive) from my school account to my work account. So far I've sent it three times. I'm hoping it will come through today.) With digital cash, this problem will come to the fore. Many people never send anything too important through email, but once they start sending cash, they will care if it disappears. Losing money gets people's attention. The solution, generally, is to keep a copy of whatever important mail you send, so that you can re-send it if it doesn't appear. Then, if and when you get confirmation that the mail has arrived, you can delete the copy. It will complicate any implementation of digital cash if it has to be aware of and concerned with this problem. The protocols involved with a secure cash system can be complicated enough on their own without having also to deal with an unreliable transport system. My suggestion is that this problem should be solved at the level of the email system. There should be a protocol for reliable email. Software to implement reliable email would save copies of outgoing mail, automatically send receipts when mail arrives, re-send mail which does not arrive after a certain period of time, handle duplicate mail arrivals, and so on. It would present to the user a model of an email system which is reliable as far as message delivery. All the issues of dealing with an unreliable network would be hidden by the reliable email system. This would be analogous to how network protocols implement reliable stream connections on top of unreliable datagram packet connections. Imagine how difficult it would be to write network software if all we had to work with were unreliable packets. The stream abstraction makes it far easier to use the network. It lets programmers concentrate on the protocols specific to their application. Reliable email would have advantages beyond digital cash, of course. As we move to a world where more commercial data travels on the network the impact of lost email will increase. I'm sure we can all think of applications which would benefit from a truly reliable mail model. I recognize that implementing reliable email would not be easy given the vast range of mail agents which exist on the net. I think the first step would be to specify a protocol for receipt and re-transmission so that "reliable-aware" mail agents would have the tools needed to implement the reliable transmission. Then it would be a matter of time and user pressure to get this support built into more mail agents. The real point of my suggestion is that implementors of digital cash should not worry about message transmission. I was trying to work out a dcash system some time back and this became a big headache - when to safely delete a digital "banknote" which had been sent to a vendor. My feeling now is that the digital cash system should ignore this problem, encouraging users to put pressure on their email servers to provide them with reliable mail. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLMFPPKgTA69YIUw3AQEWoQQAg5v20Y4yZkd2GAF0hZgcRAHG30sJcAXS zDhc7qNesbkR2o7ym7f84Z2zxHE/q6UOf50mWLJn5/dU79HLmwvwtlzq8RfCSy1A UsYtaAk23Nh+pMjUTxUYrCVt3IgvlcbC+qP/+hOyIixgANgv96bKZXRWnUmovpof vtGYytp0qv4= =3RLN -----END PGP SIGNATURE-----

1 0

Re: Crypto Technique
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I think that the proposed one-way function is too easy to invert. To decrypt a message requires producing the inverses for each function, which in turn requires knowing the constants (c1, c2, ...). But these constants can be easily obtained from expanding the general form of the equation and setting coefficients equal to one another. The resulting equations are in an easy to solve form (I think it's called upper triagonal form in linear algebra (?)). As it turns out, only a fraction of the simultaneous equations generated are needed to solve for the constants. For instance, at the end of this message is the polynomial obtained from the following nested equations: a = 1/2 x^2 + 1/2 x + c1 b = 1/2 a^2 + 1/2 a + c2 c = 1/2 b^2 + 1/2 b + c3 d = 1/2 c^2 + 1/2 c + c4 d is then the resulting 16th degree polynomial at the end of this message. [By the way, I used Mathematica to do this - the Expand[] function.] The reason the resulting simultaneous equations can be solved so easily is they are in a form convenient for back-substitution: The coefficient for x^14 is (9/8192 + c1/2048) x^12 is (139/16384 + c1 7/512 + 7/2048 c1^2 + c2/1024) etc. The first equation immediately yields c1; this in the next yields c2, etc. So the various constants can be obtained with no trouble. Here is the polynomial d: c1/8 + (7*c1^2)/32 + (7*c1^3)/32 + (25*c1^4)/128 + c1^5/8 + (5*c1^6)/64 + c1^7/32 + c1^8/128 + c2/4 + (3*c1*c2)/8 + (9*c1^2*c2)/16 + (7*c1^3*c2)/16 + (3*c1^4*c2)/8 + (3*c1^5*c2)/16 + (c1^6*c2)/16 + (3*c2^2)/8 + (3*c1*c2^2)/8 + (9*c1^2*c2^2)/16 + (3*c1^3*c2^2)/8 + (3*c1^4*c2^2)/16 + c2^3/4 + (c1*c2^3)/4 + (c1^2*c2^3)/4 + c2^4/8 + c3/2 + (c1*c3)/4 + (3*c1^2*c3)/8 + (c1^3*c3)/4 + (c1^4*c3)/8 + (c2*c3)/2 + (c1*c2*c3)/2 + (c1^2*c2*c3)/2 + (c2^2*c3)/2 + c3^2/2 + c4 + x/16 + (7*c1*x)/32 + (21*c1^2*x)/64 + (25*c1^3*x)/64 + (5*c1^4*x)/16 + (15*c1^5*x)/64 + (7*c1^6*x)/64 + (c1^7*x)/32 + (3*c2*x)/16 + (9*c1*c2*x)/16 + (21*c1^2*c2*x)/32 + (3*c1^3*c2*x)/4 + (15*c1^4*c2*x)/32 + (3*c1^5*c2*x)/16 + (3*c2^2*x)/16 + (9*c1*c2^2*x)/16 + (9*c1^2*c2^2*x)/16 + (3*c1^3*c2^2*x)/8 + (c2^3*x)/8 + (c1*c2^3*x)/4 + (c3*x)/8 + (3*c1*c3*x)/8 + (3*c1^2*c3*x)/8 + (c1^3*c3*x)/4 + (c2*c3*x)/4 + (c1*c2*c3*x)/2 + (15*x^2)/128 + (49*c1*x^2)/128 + (159*c1^2*x^2)/256 + (45*c1^3*x^2)/64 + (155*c1^4*x^2)/256 + (51*c1^5*x^2)/128 + (21*c1^6*x^2)/128 + (c1^7*x^2)/32 + (21*c2*x^2)/64 + (57*c1*c2*x^2)/64 + (39*c1^2*c2*x^2)/32 + (39*c1^3*c2*x^2)/32 + (45*c1^4*c2*x^2)/64 + (3*c1^5*c2*x^2)/16 + (21*c2^2*x^2)/64 + (27*c1*c2^2*x^2)/32 + (27*c1^2*c2^2*x^2)/32 + (3*c1^3*c2^2*x^2)/8 + (3*c2^3*x^2)/16 + (c1*c2^3*x^2)/4 + (7*c3*x^2)/32 + (9*c1*c3*x^2)/16 + (9*c1^2*c3*x^2)/16 + (c1^3*c3*x^2)/4 + (3*c2*c3*x^2)/8 + (c1*c2*c3*x^2)/2 + (35*x^3)/256 + (109*c1*x^3)/256 + (95*c1^2*x^3)/128 + (105*c1^3*x^3)/128 + (185*c1^4*x^3)/256 + (49*c1^5*x^3)/128 + (7*c1^6*x^3)/64 + (43*c2*x^3)/128 + (27*c1*c2*x^3)/32 + (87*c1^2*c2*x^3)/64 + (35*c1^3*c2*x^3)/32 + (15*c1^4*c2*x^3)/32 + (21*c2^2*x^3)/64 + (21*c1*c2^2*x^3)/32 + (9*c1^2*c2^2*x^3)/16 + (c2^3*x^3)/8 + (7*c3*x^3)/32 + (7*c1*c3*x^3)/16 + (3*c1^2*c3*x^3)/8 + (c2*c3*x^3)/4 + (305*x^4)/2048 + (127*c1*x^4)/256 + (855*c1^2*x^4)/1024 + (495*c1^3*x^4)/512 + (755*c1^4*x^4)/1024 + (21*c1^5*x^4)/64 + (7*c1^6*x^4)/128 + (21*c2*x^4)/64 + (243*c1*c2*x^4)/256 + (339*c1^2*c2*x^4)/256 + (15*c1^3*c2*x^4)/16 + (15*c1^4*c2*x^4)/64 + (75*c2^2*x^4)/256 + (9*c1*c2^2*x^4)/16 + (9*c1^2*c2^2*x^4)/32 + (c2^3*x^4)/16 + (25*c3*x^4)/128 + (3*c1*c3*x^4)/8 + (3*c1^2*c3*x^4)/16 + (c2*c3*x^4)/8 + (69*x^5)/512 + (475*c1*x^5)/1024 + (801*c1^2*x^5)/1024 + (447*c1^3*x^5)/512 + (35*c1^4*x^5)/64 + (21*c1^5*x^5)/128 + (135*c2*x^5)/512 + (207*c1*c2*x^5)/256 + (15*c1^2*c2*x^5)/16 + (15*c1^3*c2*x^5)/32 + (3*c2^2*x^5)/16 + (9*c1*c2^2*x^5)/32 + (c3*x^5)/8 + (3*c1*c3*x^5)/16 + (497*x^6)/4096 + (837*c1*x^6)/2048 + (1437*c1^2*x^6)/2048 + (345*c1^3*x^6)/512 + (175*c1^4*x^6)/512 + (7*c1^5*x^6)/128 + (231*c2*x^6)/1024 + (153*c1*c2*x^6)/256 + (75*c1^2*c2*x^6)/128 + (5*c1^3*c2*x^6)/32 + (15*c2^2*x^6)/128 + (3*c1*c2^2*x^6)/32 + (5*c3*x^6)/64 + (c1*c3*x^6)/16 + (391*x^7)/4096 + (663*c1*x^7)/2048 + (531*c1^2*x^7)/1024 + (105*c1^3*x^7)/256 + (35*c1^4*x^7)/256 + (81*c2*x^7)/512 + (45*c1*c2*x^7)/128 + (15*c1^2*c2*x^7)/64 + (3*c2^2*x^7)/64 + (c3*x^7)/32 + (2337*x^8)/32768 + (123*c1*x^8)/512 + (675*c1^2*x^8)/2048 + (105*c1^3*x^8)/512 + (35*c1^4*x^8)/1024 + (99*c2*x^8)/1024 + (45*c1*c2*x^8)/256 + (15*c1^2*c2*x^8)/256 + (3*c2^2*x^8)/256 + (c3*x^8)/128 + (101*x^9)/2048 + (311*c1*x^9)/2048 + (175*c1^2*x^9)/1024 + (35*c1^3*x^9)/512 + (25*c2*x^9)/512 + (15*c1*c2*x^9)/256 + (259*x^10)/8192 + (85*c1*x^10)/1024 + (147*c1^2*x^10)/2048 + (7*c1^3*x^10)/512 + (21*c2*x^10)/1024 + (3*c1*c2*x^10)/256 + (9*x^11)/512 + (77*c1*x^11)/2048 + (21*c1^2*x^11)/1024 + (3*c2*x^11)/512 + (139*x^12)/16384 + (7*c1*x^12)/512 + (7*c1^2*x^12)/2048 + (c2*x^12)/1024 + (7*x^13)/2048 + (7*c1*x^13)/2048 + (9*x^14)/8192 + (c1*x^14)/2048 + x^15/4096 + x^16/32768 -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLMGZfoOA7OpLWtYzAQHZ7QP8Dl0YlZaDCcOmloRmxVH7s3eGaARM6xBx q38k3ck6zw6bCFRxR2rQFflokxauEZ455l8sJv3iMJYTimORoetq6zEygZ8Wchsa 5/P1kZJL4sIQYkMuc/+iZqad9WJZz5nerHRQ/nu+2kfBJCCl8Xrvytwg9xhO4s4G sCUccLBHuIA= =BE17 -----END PGP SIGNATURE-----

1 0

encryption
by slacker＠netlink.nix.com 17 Dec '03

17 Dec '03

Is PGP hard to set up, use? does it wok with all communication software? could you send me a copy, info? Thanks a ton....SLACKER -- INTERNET: slacker(a)netlink.nix.com (John Witteborg) UUCP: ...!ryptyde!netlink!slacker Network Information eXchange * Public Access in San Diego, CA (619) 453-1115

2 1

RE: PROBLEMS OF ANONYMOUS . . .
by Sandy 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT Reply to: ssandfort(a)attmail.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Punksters, Hal Finney wrote: It's not even impossible that the government could someday try to paint the cypherpunks themselves as a subversive organization. Gee, Hal, that can't be right. I've always thought we were a subversive *dis*organization. According to my online dictionary: THE AMERICAN HERITAGE DICTIONARY OF THE ENGLISH LANGUAGE Third Edition Copyright 1992 Houghton Mifflin Company. All rights reserved. subversive ======================================== sub*ver*sive adjective (1) Intended or serving to subvert, especially intended to overthrow or undermine an established government: "Sex and creativity are often seen by dictators as subversive activities" Source: Erica Jong Sounds good to me. Say! Do you think we could work that sex part in somehow? ("I'll show you mine, if you'll show me yours . . . public key, that is.") S a n d y >>>>>> Please send e-mail to: ssandfort(a)attmail.com <<<<<< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0