December 2003 - cypherpunks-legacy

Real-world digicash
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I agree with Mike Ingle's points re NetCash. I had some pretty strong criticisms of their proposal when it first came out. They didn't seem too familiar with the literature on digital cash. Their system was more like cashier's checks than cash. The anonymity was not strong. Nick has some interesting ideas re the use of "reputation capital" to discourage double-spending of dcash. You wouldn't want to destroy your reputation by cheating on a small sum of money, not if the reputation was one which you had built up over a period of time. In considering these ideas, there are a lot of questions about the whole infrastructure in which the dcash is being used. Is this something which we would see occuring in the near future, the next couple of years, in which case current systems of electronic communication would be used? In that case, we might imagine people purchasing items via the more progressive on-line services, like the new MUD-based systems people are working on (metaverse, virtual city, ...). Or companies might simply advertise items for sale on the internet and accept orders by email or perhaps TCP connection. One technical detail is that dcash systems require a multi-step protocol for spending and withdrawal. This would make email orders more difficult to deal with since mail would have to bounce back and forth. Actually, Chaum's simplest dcash scheme has a one-step protocol for spending (just send the cash), but that requires on-line verification. TCP connections can handle the back-and-forth very quickly so that may be a preferred communications method. Today, most credit card transactions do an on-line check, so I don't think that on-line systems should be ruled out, although eventually a dedicated network separate from the internet would probably be needed. The total data transfer per transaction is not large, a few hundred bytes. One question in considering whether double-spending is likely to be a problem is whether bank accounts are anonymous. One possible system is for bank accounts to be non-anonymous, but for transactions to be untraceable. Then if someone double-spends the cheating is traced, not to a "nym", but to a real person. (There is still the possibility Mike raised of stealing someone's cash, similar to how you might steal someone's PGP secret key today, but perhaps this will not occur often enough to be a problem.) In this case you don't have to have an infrastructure of reputations and credit ratings in order to use the cash. Nick's idea sounds like it would take some time to develop. Our hundreds of years of experience in giving credit will require some readjustement to a world in which "nyms" can disappear much more easily than physical people can. Another technical detail with the two forms of digital cash that I am more familiar with, Chaum's on-line and off-line systems from his Crypto 88 paper, is that even the off-line system requires the vendor to communicate with the bank for every transaction. He has to send in the spent cash, as well as the results of his protocol with the customer, for every piece of cash he gets. The difference is that he doesn't have to do it right away. So this off-line system will actually require more bandwidth for communication with the bank than Chaum's on-line system would (because of the extra transaction information that has to be sent). It seems that on-line and off-line cash systems both have pros and cons. Initially my feeling is that an on-line system might be preferable because there is less need for trust between the parties involved. Each person checks at each stage to make sure he is not being cheated. There is no need for a legal system to prove double-spending and force cheaters to make good. The protocols are much simpler and easier to understand. And the bandwidth requirements are less. The main disadvantage is the need for enough redundancy in the bank to allow continual accessibility, although even this would not be an issue for purchases which are delivered after a delay, typical of electronic purchases today. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLN0b86gTA69YIUw3AQEw+wP/daSj1lrRoYB/YuXVq1JGVvqxANOwVEyb KeG53eOaauxn4BlhG6z7jMZYLeTJO1Ct045ZbeKwfgMEDKFyDJyfwquDz7VcgtQH 5N1E4yLRYiIyy6UEiIz6Vg2BLOp1yYqux4h/n6F13xY7HgXYSzHTwZAp+9UFvh5v lUxNkVkC8Tk= =n4aj -----END PGP SIGNATURE-----

2 1

Re: some newbie DC-net questions
by an41418＠anon.penet.fi 17 Dec '03

17 Dec '03

How do you implement people seeing their neighbors coin, but nobody else seeing it? Does it require a secure channel between every adjacent person? Wonderer ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

2 1

Re: some newbie DC-net questions
by pierre＠shell.portal.com 17 Dec '03

17 Dec '03

> From: Jim McCoy <mccoy(a)ccwf.cc.utexas.edu> > > > 3) What happens when two members of a "table" attempt to transmit at the > > same time? How is this case handled? > > They will get a collision. If an even number of members transmit at once > then the bit will be the opposite of what each expects to see, if an odd > number then it will be an undetected collision. There are fairly standard > protocols for backdown on distributed broadcast networks. > Actually, it seems to me undetected collisions are not as likely as this makes it appear: Every person trying to transmit is monitoring at the same time to make sure the message they transmit does appear in the "sum of differences". If you tried to transmit and any bit comes out wrong, it's that there was a collision. Only an odd number of completely identical messages transmitted at the same time would appear as one un-collided message. Of course, if you are only considering very short messages (like 1 bit answers to questions) you are looking for trouble... but if you are sending around longer messages similar to email, then un-noticed collisions are unlikely because messages include signatures and such. When you detected that your message collided, typically, you stop transmitting. You then decide on a random time delay, wait for that duration and try again if the way is clear (all zeroes carrier). Pierre. pierre(a)shell.portal.com

2 1

to mark re: MoD tapping
by Cdt Pvt Dan Doughty 17 Dec '03

17 Dec '03

well from what I have read, an observer watched as one of the members loaded a program, called a local telephone system, (the utility was a phone utility produced by the phone company) and then whala he could hear the people voices or if data he could watch it scroll down his menu. I was amazed when I heard this. No tech available but I thought I should mention that it was a hardware utility available through the modem. Dan

1 0

Re: Mostly offline digicash
by Joe Thomas 17 Dec '03

17 Dec '03

Alan (Gesture Man) Wexelblat <wex(a)media.mit.edu> writes" > Nick asks: > > Why haven't people backed away from credit cards despite $10's of billions > > in fraud? > > A very good question. The reason is largely > because it's a very profitable business *for the > card merchants* (banks, mostly). They get their > percentage no matter what, and losses don't eat > into it all that much. > > I agree with much of what Nick says, but I think > we have to consider ways to help make digicash pay > for its own implementation and enforcement, or it > will not take hold. Hmmm. Couldn't digicash issuers simply charge up front for their digicash notes, adding a percentage on top like travellers checks? Let the people who want the convenience and anonymity of digital cash pay for it; let the merchants redeem it for free. Sound okay? Joe

2 1

No Subject
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

i've heard rumors that one or more pgp key servers have been shut down due to lawyers letters from bidzos and/or pkp. anyone have any facts?

1 0

TV scremblers.
by blaster＠rd.relcom.msk.su 17 Dec '03

17 Dec '03

Hi! How can I receive any information about TV scremblers (and hacking of one)? --- Victor A. Borisov aka blaster; Relcom R&D; Email: blaster(a)rd.relcom.msk.su; Phone: +7(095)-943-4735; +7(095)-198-9510; === Don`t panic! ===

1 0

Article in biz.clarinet.sample
by Lyle_Seaman＠transarc.com 17 Dec '03

17 Dec '03

I don't know whether forwarding Clari articles posted to ...sample is permitted or not, so I am posting just a pointer. Trot on over to biz.clarinet.sample, and check out this article: > Subject: Software you can buy but can't sell > Message-ID: <biz-computerUR971_3N1(a)clarinet.com> > Date: Sat, 6 Nov 93 18:08:02 PST > In mid-October, the House Subcommittee on Economic Policy, Trade and > Environment began a round of hearings on legislation to reauthorize the > Export Administration Act, which sets export control policy for the > United States. There's not a lot of information, but it's a favorable article. Peeve: I wish tech editors wouldn't insist on spelling out acronyms that nobody ever (ever! Well, except tech writers/editors) uses in their spelled out form. If they must spell them out, do it in parens, and bury it. I *hate* having to try to figure out what "the Transmission Control Protocol / Internet Protocol suite" is (eg). > It wasn't that Iraq's dictator had hired the world's best technical > wizards to work for him. It was because the technical minds which were > already in Iraq recognized the fact that standard Internet Protocol > routers were designed well. Knock one out and another takes over, > invisibly. The computer network keeps running.

1 0

Re: Remailer Abuse?
by nobody＠cicada.berkeley.edu 17 Dec '03

17 Dec '03

hh(a)cicada.berkeley.edu says: > Harassing other users is considered abuse, and sending chain letters is a > form of harassing other users. However, it's not a very serious form of > abuse. If I found conclusive evidence that someone were sending something > like childporn through my remailer, I would take some pretty drastic > actions. Interesting. I wonder what those drastic actions would be? People sending serious death threats and the like through anon remailers should be aware that those actions are considered seriously anti-social and may cause them some problems. But I don't view "kiddie porn" the same way. Its very definition is VERY ill-defined, and there is widespread disagreement on how much of an evil threat to truth, justice, and the American Way it really poses. This makes me start to think that borderline policies like this should be well publicized by the operator of the remailer. I don't support the kiddie porn witch hunt going on in the U.S. currently, and would not have assumed that posting what many people consider to be harmless photos of kids under 18 would get someone automatically turned in to the cops. (Again, keep in mind that the definition is very fuzzy. Some people who have been busted as kiddie pornographers have been busted for extremely mild and un-pornographic material that no reasonable person would consider harmful.) .....Cindy

1 0

Mark Abene (Phiber Optik) sentenced
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

In article <9311080705.AA15339(a)toad.com> newsham(a)wiliki.eng.hawaii.edu writes: > I have heard that tapping high speed modems can be a little tricky > because of the adaptive filtering done. The modems both have > adaptive filters that adjust to the line as they see it. If you > are tapping at some other point the filtering will not be optimimal > for your case. I believe these filters take care of smearing and > echos and things of that nature. > > Maybe someone in the know can elaborate and clear up all the > bad data I probably just spewed :) Dunno if this is how they did it, but you get *perfect* data tapping if you record digitally off the exchange trunks... G -- Personal mail to gtoal(a)gtoal.com (I read it in the evenings) Business mail to gtoal(a)an-teallach.com (Be careful with the spelling!) Faxes to An Teallach Limited: +44 31 662 4678 Voice: +44 31 668 1550 x212

1 0