December 2003 - cypherpunks-legacy

RE: In Search of Genuine DigiCash
by p.v.mcmahon.rea0803＠oasis.icl.co.uk 17 Dec '03

17 Dec '03

> >If there were already a fully identified digital money system, > Is there one? > > I don't think there is any digital money system at all, neither > anonymous nor fuly identified. > > There certainly are digital funds transfer systems, almost all fully > identified. These are not digital money systems, although they may be > precursors. Clearly there is existing practice in vendor-supplier EDI - but most financial service organisations have not yet even been able to cost-justify electronic processing of remittance information (for which the manually-shipped lockbox is deemed adequate ...) > Eric, for the last three months, you have said that there was no way to > prove whether digital cash was more cost effective than other forms of e$, > and thus potential efficiency was useless as an economic argument for its > adoption. > > I still agree that you cannot really _prove_ that it will be more > efficiently, at least not from armchair business planning. Given a > few million for a good study though, I'm sure answers might be > forthcoming. There has to be a business reason for change to any existing practice; a general infrastructure for electronic payments is not going to be adopted by banks just because there are available or emerging technologies. One agent for change *may* be threat to the banks through extension of existing EDI arrangements to include transmission of remittance data on a bilateral or hub-spoke basis. The attractions of a fast growing (albeit currently 500m USD) servide provider market, and real concerns about loss of business, have spurred the establishment by partnerships of banks of a number of check and remittance data clearing houses. With the increase in the number of trading partners, and the opportunity for the banks' commoditization of the electronic financial transaction, there may be benefit in marketing an electronic "cash" product - even if it's not transferable. But technology underlying this may be little more than an extension of existing solutions unless there are compelling countervailing business reasons to change. [Consider: who bears the cost burdens of the status quo with increasing use of EDI by business + (mostly) manual remittance mechanisms? What will drive this status quo to alter ...?] - pvm

1 0

Rising Above Petty Illiberalism
by John Young 17 Dec '03

17 Dec '03

Responding to msg by karn(a)qualcomm.com (Phil Karn) on Sat, 27 Aug 10:1 AM >It really gives one pause. Is government really the >enemy of personal freedoms, or does it merely reflect >an intolerant and unenlightened general population? >It's easy to make a government that responds to the >will and whim of the majority, but how can one create a >government that rises above the petty illiberalism of >the people it governs to protect the rights of the >individual? Phil, I really liked this. Perhaps you can find a way to stitch into other topics like you did here. Don't know what the list reception will be since the recent thread on government got thumped for disobeying the sirens of crypto and technology. Hope yours will catch fire. Fan the embers. John

1 0

Re: Cash, cheaters, and anonymity
by Rick H. Wesson 17 Dec '03

17 Dec '03

I've finished implementing the GNU mp library in perl of which I've already extended to work with an Object Relational Database. All this together gives me very fast access to numbers in the order of 8192 digets in base 36, geesh I have no clue as to how many base 10 digits that is but I feel that its proabably enough to play with some digital cash prototypes... So those that want to start formulating some REAL implementations of protocols of digital cash I'm offering to run the "virtual bank" and implement the server side protocols. I'd like to see how some of these theries realy work in practice, yes I'd encourage double spending as soon as we can get some apps up to accept whatever we decide upon for the cash protocol. I'd like to see if all the discussions about digital cash can realy work!!! would anyone else like to put their (virtual) money where their mouth (or keyboard) is ? -Rick

2 1

filtering this list
by tim werner 17 Dec '03

17 Dec '03

Hi, Well, I've had procmail running for some time now, and it helps a lot, but I still need to do some kind of post-procmail processing. So I'm asking anyone who feels helpful today to give me a short howto or some pointers. I don't use gnus, but I tried starting it up with my crypto folder as input, and it didn't work. I'm not sure yet where I made my mistake. Before I spend a couple of hours re-inventing the wheel, can someone tell me the preferred method for reading a mail folder that allows one to do things like marking a subject as read? Right now, I'm using rmail (in emacs) to read my crypto folder, and it's just not that easy to kill off a thread once I've had my fill. For instance, I enjoyed the nuclear thread for awhile, but I would have liked to be able to just 'k' it at one point. thanks in advance, tw

1 0

Cash, cheaters, and anonymity
by Anonymous User 17 Dec '03

17 Dec '03

(my apologies if you've seen this twice -- whizzywig) I thank Hal Finney for his thoughtful reply, and Tim May for his excellent essay. It looks like we can start to draw a stronger conclusion: there are serious holes in the assumptions made by offline digital cash protocols when applied to computer networks rather than manually operated smart cards. Hal's comparison of coin theft to digital signature protection and repudiation is apt, but usually Irving only has one or a few keys to protect, while he might have thousands of coins, issued by various banks. I doubt digital signatures will ever be used alone much for signing expensive contracts. A digital signature on an expensive contract, in addition to being repudiable, will be suspicious, since if few people accept such signatures as strongly binding (the initial state), they will not be widely used on expensive contracts, and thus their existance on an expensive contract will be suspicous. I predict it will become common practice, or even law, that digitally signed contracts over a certain amount are automatically invalid unless further precuations have been taken (signatures of notary witnesses, or perhaps some better crypto protocol designed for this purpose). The trouble with offline cash in a network environment is that the upper limit for fraud liability can be incredibly high. If there are hundreds of thousands of vendors on the net, a situation CommerceNet predicts before the end of the decade, and they are using this offline protocol, then even with small transactions the fraud could run into the millions of dollars. There's plenty of incentive for Irving to steal Jane's coins, run off to some place on the net that has no extradition treaty, and pump good change out of the vendors and into his Lichtenstein account to his heart's content. We may yet find protocols to mitigate or limit this kind of fraud -- make change traceable if linked to double spending, do random online checks as a cypherpunks poster suggested last year, or similar precautions layered on top of the basic protocol. But so far these problems haven't been put on the front burner of digital cash design, and already we have people out there selling offline cash on the network as a superior solution! Reliance on law enforcement flies in the face of cypherpunk goals, and indeed against the goals of good cops as well -- one of their most vocal complaints is about people setting up systems that are vulnerable to crime, putting them in unecessary danger. It also goes against political reality to think that a startup operation can lobby governments all across the globe to protect a system that is ideal for money laundering and tax evasion. Ain't gonna happen -- they'll let those "dirty money banks and money laundering net sites" rot; they may even give Irving a helping hand. I disagree that "there is no excuse" for double spending. If the software is implemented badly (no fault of the user), it might get mixed up with systems programs in such a way as to cause double spending. For example, if the system crashes and one must recover from a month old backup, one has to go through that old purse and determine which coins have been spent. If the software and/or user makes a mistake in this process, we get double spending. If a network burps and sends a vendor two coins where there should have been one, we get double spending. The possibilities for accident are legion and cannot all be foreseen. "Shit happens". A protocol that treats common accident the same as criminal fraud, when the stakes are so high, is pathological. In the online system the consequences of double spending (or million spending) are far more benign. At worst one customer is out stolen coins. In a networked offline system those same few coins are a potential loss for every vendor on the net. As Tim May noted, we may not even need to recongize fraud in online cash -- just treat all online double spending as accident. No bonding, secured accounts, investigators, ID badges or cops with guns busting down Janes's door after Iriving has million-spent her coins. Here we both have a simple liability system and much less chance of fraud. Tim May also suggested that most offline protocols are intended for manually used smart cards. This makes sense -- unlike an network environment with automated spending agents, the scope of multi spending for manually used pruchases in small amounts is quite limited. On the network even fraud of a few cents per transaction can quickly add up to big $$$ across thousands of vendors. What are the communications costs of online clearing anyway? Don't credit card clearings cost about two cents per transaction these days? If clearing costs are less than plausible offline cash fraud and fraud prevention costs, online cash is a winner, both now and increasingly in the future as bandwidth becomes even cheaper. sincerely, -- An Unauthenticated Agent with no credentials: whizzywig

1 0

anonymous mail
by nobody＠ds1.wu-wien.ac.at 17 Dec '03

17 Dec '03

> I think this says is that it is important to apply the appropriate > tools when it is apropos and the situation calls for it, but not when > there isn't sufficient cause to warrant the time & trouble. Interesting. I beleive this attitude will probably be what the future holds for crypto, just using it when it is necessary, like for carrying out commercial transactions via email. Which is to say crypto will not be in main stream "cypherpunks" usage, but just something extra to use once in a while. And if it only needs to be used once in a while, there will be no good reason to implement some of the more interesting protocols, or implement the "maximum strength" possible. See, the problem with the above attitude (not attacking who wrote it, just the attitude itself!) is that when there is sufficient cause to warrant the time and trouble, there will be an even more appealing alternative, which asks you to trade a bit of the advantages of the former. Months ago, Tim May posted about outlawing cash, and how it may be disguised as an effort to stamp out crime, check on welfare recipients, etc. For the overwhelming majority of people, the benefits of "digital cash" will not be worth the time and trouble over "digital cash with anonimity removed", which is probably what kind of digital cash the future will bring. As for encrypting all email, much like people use envelopes? Be honest, there isn't sufficient cause to warrant the time and trouble. It's easy and convenient for people to use envelopes. But encryption needs to be integrated into mailers and communications software before it will even start to be convenient for everybody to use, and even then the security is an illusion on multi-user systems. I guess crypto suffers from the problem computers had several years ago: they were solutions searching for problems. Time needs to go by, and by then, it will be too late. Nor is there sufficient cause to warrant the time and trouble of signing messages sent to mailing lists or usenet. Nobody cares or will even check the signature of posts; most see signature info as irritating extra lines and wasted bandwidth. Nor is there sufficient cause to warrant the time and trouble of communicating via anonymous remailers, except for say folks like Pr0duct Cypher. Which is one person out of how many people using the internet? Nor is there sufficient cause to warrant the time and trouble for banks and stores to offer digital cash. Where is the advantage for them? The advantages for individuals is clear: keep dossiers and info from being tabulated about them. Jim Choate asked this question a few days ago, and got no responses (or maybe it was drowned out among the atomic bomb posts). I agree with what he said, unless there is some good advantage for the bank or store, it isn't going to happen. As for dc-nets, give me a solid example why you ever need to communicate with one. A good enough example to explain why the man-months or man-years need to be put into developing one. Of course, on a multi-user system, the security is again illusory since the system operator can tap you anyway. A while ago somebody (I think I remember but don't want to put words in their mouth since I'm not 100% positive) doubted the future impact of crypto. Me too, I see a limited deployment, and almost no fundamental restructuring of society. So basically the protocols are interesting in an academic way, and we could sit here and discuss the possibilities, but then I suppose a discussion about atomic bombs will likely be of greater impact on our future than crypto anarchy will. Cypherpunks write code, but if there is sufficient cause to warrant the time and trouble!

1 0

?-line cash
by Rick H. Wesson 17 Dec '03

17 Dec '03

It seems that off-line cash is dead or so the latest posts assure me, is there a way to incorporate some of the anonymity with off-line cash into on-line cash? I've stoped tring to code up an off-line experenemt unless anyone thinks it worthwhile. The last on-line cash system I tried to work up didn't have a drop of anonymity to it, and I don't know how to blind the bank to the transactions but keep the thing reliable and secure... I liked brands cash untill some of the holes were poked into it, so any suggested on-line systems to model? As far as crypto not being promoted you may want to check out the RFC on Secure HTTP which uses PGP or RIPEM. CommerceNet is codeing the stuff up and is supposed to give a finished implementation to NCSA late in sept. CERN has come out with a nother spec thich uses the SecureDE implementation of Public-Key crypto... As far as the WWW goes it's full steam ahead on using crypto for business transactions. See the electronic check writing demo at commerce net (http://www.commerce.net) -Rick

1 0

Re: PGP availiable on magazine cover
by nobody＠kaiwan.com 17 Dec '03

17 Dec '03

This is a good thing. By being published in that fashion, PGP thus meets the requirements under ITAR to be classified public domain, and can thus now be legally exported from the US.

2 1

Re: e$: e-cash underwriting
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 11:41 AM 8/27/94 -0700, Eric Hughes wrote: >Why does everyone think that the law must immediately be invoked when >double spending is detected? It's obvious I gave that impression. I regret the error. Anybody who bounces digital cash accidentally (in most accidental cases that I can imagine) isn't to blame, especially if software is at fault. That's equivalent (economically) to the bank thinking that a person's checking account has less money in it than the depositor put there. It's safe to see that an underwriter could make up losses if they're made in this fashion on software they certify, for instance. However, there is a special case in checking where someone thinks that they've the money, and they don't really. There is probably an analog to this in a digital cash transaction and I can't think of it at the moment. The spender should be held liable for something like that, at any rate. If someone deliberately double (or million) spends, then they should get busted for fraud. Period. As protocols and software gets "burned in", multiple spending should happen less and less, except when people do it in purpose. When that happens, put 'em in the airlock. ;-). >One solution is clear and direct: charge for each redemption attempt. >In that situation, multiple attempts get rejected, and the issuer is >recompensed for the attempt. No morality need be invoked. I agree. This solution is hard to remember in the heat of argument, but it's quite simple. I have argued elsewhere that there are all sorts of ways to catch multiple spenders who do it on purpose, but if there's a way to prevent it in the first place, in a financial manner, that's even better. I got sat on about this early on over on www-buyinfo, and my response there was, catch them using plain old police work, and book them for fraud. There has been significant discussion here and there about the use of governmental entities to enforce fraud laws when people get ripped off in a double spending scam, but for the time being I still think that this is the way to go. > Are there any non-proprietary, public sources of information on these legal > and regulatory research efforts? Are there archives of the c'punks traffic > on this subject that I can look at? > >The research efforts are basically my own, Hal's, and Perry's. There >is no reference other than back traffic, which others can provide. Cool. Is there anyone out there who has these "back issues"? Thanks! Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

2 1

e$: A prima facie business model for a digital cash underwriter.
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 3:07 PM 8/27/94 -0700, Rick H. Wesson wrote: >I've finished implementing the GNU mp library in perl of which I've >already extended to work with an Object Relational Database. All this >together gives me very fast access to numbers in the order of 8192 >digets in base 36, geesh I have no clue as to how many base 10 digits that >is but I feel that its proabably enough to play with some digital cash >prototypes... Rick, I've been thinking a little about what we all may see as business models for e-cash use. The least complex model I see, and the one I like the most, is that people simply buy digital cash from an underwriter through a link to some off-net financial entity. NetBank uses a 900 number phone call which generates so-many netbux. My favorite one, and the one which may be most apprehendable to the public, is an ATM-card gate in which the purchaser swipes his card into a secure mosaic screen using a card reader at home (they're pretty cheap these days, and could get cheaper if this became prevalent). If the underwriter could assure the bank in some fashion (maybe it's the bank's gate?) that they can't "sniff" the card key/pin number, then the bank could simply authorize the generation of digital cash from the underwriter to the purchaser on a "pay ya later" basis . That is, the money would be forwarded by the bank from the purchaser's account to the underwriter's suspension account by wire or whatever, trade settled in same-day funds, of course. This is somewhat analogous to the way traveller's checks are generated now, in the sense that the bank functions as an intermediary (buying the checks on a discount, and selling them for a premium) to an underwriter (the issuer of the check). In our case, the bank is just referring a customer and collects a fee for each customer sent to the underwriter. Pricing of the cash at purchase will probably be based on a combination of discounting the costs of the operation of the underwriter, the commission paid to the "sponsoring" bank, and the returns from holding on to the cash in a suspension account (however small that may be). As is the case in traveller's checks, there isn't a fee for using them with a seller, and there are hardly any ID requirements, because the signature's on the check. I believe that a traveller's check is as good as cash at a bank, so the check is "loaded" like a mutual fund at the front of the transaction. In keeping with Eric's point for charging a fee to exit the net, we could also put an additional exchange fee (which would be figured into the same equation which generated the front end fee). The beauty of this method is that the underwriter need not keep any "account" data per se. It has a database of outstanding cash, and it simply honors outstanding cash coming in. When a double-spent digital bank note comes, then the protocol for identifying the double spender is followed, and it's up to the redeemer to settle up with that person. Having said all that, my question is, will your machine handle all the routine activities of an underwriter in the above scenario? We'll ignore interacting with banks for the time being, because that's done in the financial markets already, and interbank operations methods will be different for different underwriters anyway. That means anything put up on your spiffy Sparc machine and it's attendant code should be able to: 1. Generate to purchasers and take in digital cash from sellers. 2. Identify double spenders. That's it. That's obviously a tall order, as lots of people have said here more than once. 1.) It implies an interface to the customer who buys the digital cash which ensures privacy between a bank and a customer, even though an ATM swipe and a PIN goes through it. 2.) It implies a wallet and a register with which to transact business offline, with the assurance that cash is not accidentally double spent. 3.) It implies the managment of what may be a large database of unspent cash that's out there representing contingent claims on a suspension account. It probably also means the need to keep at least sample statistics on spent certificates so that they can be used to determine the longevity of a piece of cash on the net, so that proper management of the suspension account can occur. Obviously, you don't have all that stuff. More to the point, I think 1.) and 2.) above are already out there somewhere. But from talking to you, I'd also think that you have most of the foundation for 3.) taken care of. Obviously, the problems are in legal and regulatory issues, folks. Whoever's algorithm is used to gen up digital cash will want their piece from whoever underwrites digital cash. That's pretty straightforward. Pay them royalties. The banks are going to want to make sure that they get a piece of this, so that they don't disappear (fat chance!). Pay them comissions. Regulators are going to want make sure, well, I don't know what they're going to want, but it'll probably be silly. Given them what they want within reason. Then pay them taxes. If they ask for a total audit trail on off-line transactions, tell them it's impossible. If they forbid off-line transactions because of decreased tax revenue, show them the potential for increased taxes on your operation to make up for it, and show them that you'll follow IRS cash handling protocols just like banks do. Like I've said before, it's a rare parasite which kills its host. If somebody tries to send out a million-quarter attack, it's known how to detect it and to stop it. If someone gets away with it, it's known how to hunt them down and send them to jail. No matter where they are. The point is, we're closer to digital cash than we think. I think that estimates for the delivery of working code for all of the above are way overestimated. I think that the cost of regulatory compliance is way overrated, especially if banks can see a way to make a moderately risk-free living from it. I think the cost of catching a thief and proving he stole money is the same it has always been. I'll sit down now. ;-). Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

2 1