Cypherpunks defeat?
At 10:02 AM -0500 9/24/98, Albert P. Franco, II wrote:
I think perhaps a tougher question is, "Is there a way, without resorting to bloodshed, to regain control of our private property and private lives?" That's not a troll! I know that there are a lot people on this list with their assault rifles at the ready, that are convinced that only armed resistance will work. But. I think that's the "easy" way out. (How) can it be done another way?
It's ironic that you would have to ask that question here. The cypherpunks group was founded on this very premise: that through the use of cryptography, people would become able to engage in a wide range of voluntary transactions, outside of the reach of meddling interlopers. Most cypherpunks have become disillusioned about their dreams, and you will seldom hear them defend the notion that cryptography offers any kind of alternative to a society based on coercion. The past few years have been hard ones. The failure of digital cash, the gradual trend towards a debate over when and how (rather than whether) to regulate domestic cryptography, widespread abuse of anonymity, all these make the original cypherpunk goals seem even more distant today than in the past. Is the cypherpunks dream dead? Is the movement over? Maybe it is time to give up. Throw in the towel, admit that we lost. Sure, there are still battles to be fought, rear-ground actions where we can perhaps delay the inevitable outcome. But the vision has been lost, and all that is left is the post-mortem analysis of the failed dream.
-- Anonymous wrote:
Most cypherpunks have become disillusioned about their dreams, and you will seldom hear them defend the notion that cryptography offers any kind of alternative to a society based on coercion. The past few years have been hard ones. The failure of digital cash, [....]
Is the cypherpunks dream dead? Is the movement over?
Maybe it is time to give up.
We are not defeated. We have won many key victories, and only one, though the biggest one, remains to be accomplished. Our failures have had obvious and remediable causes. Few people use encryption technology today, because few people have real need of it. Few people have real need of it, because there is no reasonably liquid net money. People are not making, spending, transferring, and promising, money through the net, so they have little need to encrypt their messages or care for the reputation of their nyms. And that is the big remaining battle. Net money. Net money that is reasonably liquid, that many people acquire, that many people spend, money that is readily convertible to worthwhile goods and services. Don't worry about blinding and all that. Once any sort of net money is flowing in large amounts, all that stuff then becomes possible and desirable. If there is no liquidity, nobody cares about blinding, and if you have blinding it does you no good anyway without liquidity. Once we get that, we will shortly get it all. As long as we do not have that, we have very little. Digicash failed because it was proprietary. For net money to be a success we need a standard for transferring promises to pay that is separate from the software issuers, and thus separate from the issuers of promises to pay or deliver. It has to be a standard such that anybody can play, anyone can write software that will interoperate with software written by others, and anyone can issue promises to deliver anything, so that Ann, Bob, and Carol can transfer and exchange promises between each other subject only to the need to trust each other, without needing permissions or licenses from anyone else. And it has to have software that is competitive with existing methods of transferring value. Credit cards are very competitive for transactions of modest size, because of the additional services, in particular dispute arbitration and resolution provided by the card issuers, and because of their large installed base. Smaller players cannot hope to compete in that area. We have however no adequate means for small payments, five dollars to fractions of a cent. This offers a fertile opportunity for the development of netmoney. We also have no entirely satisfactory means for large low margin payments.. The large payment problem could be addressed by some system that provided a tight connection between internet money and US dollars in US banks, or, better, a system that provided a tight connection between internet money and US dollars in non US banks, or, if we had a large and liquid micropayment system, it could be provided by a tight connection between micro and macropayments. If several banks in some moderately popular banking haven allowed people to transfer funds instantly and cheaply from one account to another within the haven, through digitally signed messages passing through https protocol, this would make it possible to readily solve the large payment problem by offering the means to create a tight connection between net dollars and offshore dollars. If this were done then the revolution would ensue within a few years. So far none have been willing to do this, perhaps out of fear of reprisals, more likely out of sheer inertia. The offshore dollar system is probably larger and more liquid, and is certainly considerably more free, than the onshore dollar system, but it is inconvenient for modest payments. People use it primarily for transfers of many thousands of dollars. Also the connection between the offshore dollar and the onshore dollar is weak, because it is inconvenient, slow, and costly, to transfer dollars between the offshore and onshore banking systems. I see no possibility that anyone will be permitted to create a strong connection between an internet dollar and the onshore dollar, whereas it is quite possible that someone will get away with creating a strong connection between the internet dollar and the offshore dollar. Alternatively, (and perhaps more likely) a satisfactory solution to the micropayment problem automatically brings in its train a solution to the large payment problem, since the software must accumulate many small promises into a few large promises, and provide means to transfer these large promises through numerous intermediaries, thus a large volume of micropayments will create the liquidity for macropayments. We do not need the banks to win this one, though they would be very handy. Large promises to pay could acquire value not through a fast and cheap connection to the banking system, whether onshore of offshore, but through a fast and cheap connection to the micropayment system, resulting in an internet dollar that derives its liquidity from the internet market, and is coupled to the US dollar no more strongly, and no less strongly, than the offshore dollar is coupled to the onshore dollar. Of course for this to work, we will need a large and liquid market for aggregated micropayments. The existing finance systems for self publishing, dirty pictures, and gambling, really do not work very well, so there seems an obvious and large market for micropayments. Jakob Nielsen, an apparently well informed internet commerce pundit who claims familiarity with lots of market research and has himself done lots of market research has argued that there is a large and compelling market for micropayments "The Case for Micropayments" http://www.useit.com/alertbox/980125.html Jakob Nielsen: Some analysts say that users don't want to be "nickeled and dimed" while they are online. In fact, the problem is being dimed; not being nickeled. Unfortunately, some sites that currently charge for content do so at a level of a dollar or more per page. Such pricing is obviously unpleasant and will only be acceptable for highly value-added content that users can predict in advance that they will benefit significantly from buying. Regular articles (like this column) cannot be that expensive. Long-distance telephone calls and electricity are both metered services. Many people do feel a tension while they are on the phone, at least while making an international or other expensive call. At the same time, very few people worry about powering a lightbulb, even though doing so costs a few cents per hour. Electricity charges mainly serve to make people turn off the lights when they go to bed. The difference is clearly in the level of pricing: less than a cent per minute and people use as much as they need (electricity) 10 cents per minute, and people ration their usage a little (long distance phone calls) 40 cents per minute, and people ration their usage a lot (international calls) On the Web, users should not worry about a cent per page. If a page is not worth a cent, then you should not download it in the first place. Even as the Web grows in importance in the future, most people will probably access less than 100 non-free pages per day (in June 1998, heavy users visited an average of 46 pages per day). Most users will have $10-$30 in monthly service charges for Web content. One cent, or half a cent, is probably the sweet spot for pages and dirty picture, with quarters being the sweet spot for games and gambling. Obviously pay pages cannot and should not be searched by search engines, so the typical design would be a free, searchable, index page containing lead in paragraphs and pay links to the non free pages on the site, or a collection of free summary pages each containing a pay link to the corresponding non free page, or (better) both a free index page and also a collection of free summary pages. We want the payment system to introduce no additional delays when we click on a link, so the index page should cause any necessary negotiations between the browser and server so that the server is ready to accept the coins of this particular user, so that the user can get the pay page with a single message, a single URL containing a coin. The server then immediately starts downloading the page without waiting for any further messages to complete, and simultaneously attempts to deposit the coin. Suppose you are browsing dirty pictures, and both you and the server are clients of the same token issuer. Then the token issuer knows that you are browsing the dirty picture pages, and knows how much money the dirty picture issuer is making. But for the scheme to be successful, we need many token issuers, and the means to transfer aggregated token values between issuers, so that in general the entity that takes your bank money and provides you with net money, and the entity that takes the dirty pictures servers netmoney and provides it with bank money, will be very different entities, probably in very different jurisdictions, separated by a chain of intermediaries, who have an economic incentive to aggregate transactions, thus obscuring individual spending and getting. If any creditworthy person can issue tokens, privacy is not such a big problem, and if the aggregated values representing large numbers of tokens are readily transferable in a large liquid market intermediary market, it is not a problem at all, since the dirty picture issuer and the guy looking at the dirty pictures are likely to be anonymous to the token issuer. The IBM token scheme provides for intermediaries. Previous token schemes did not. This is an important step forward. Until now, no one has issued a micropayment scheme that had a ghost of a chance. The IBM scheme seem basically workable, though I need to examine it further. Micropayments have not failed. They have not yet been tried. We still have not seen a scheme attempted that had all the requirements that real netmoney will need. It is simply quite a bit of work to design these things, and to get them deployed in a form that ordinary mortals can use. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG NPL9VZbCi5pP9i/NPYToSVmWYTnX2mbqCxE3CBmj 4RNCFUvHIWJi/I6WQfi1zBE3fjEMJNMx41wskrUiI ----------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the omnipotent state. http://www.jim.com/jamesd/ James A. Donald
-- At 05:10 PM 9/27/98 -0700, James A. Donald wrote:
But for the scheme to be successful, we need many token issuers
At 10:32 PM 9/27/98 -0400, Robert A. Costner wrote:
Is there existing open software available for this?
IBM is proposing that anyone, or many people, will be free to act as issuers of promises to pay in their proposed microcash system. Obviously their system is not very open, but unlike previous amateurish proposals for microcash, it does support a rich system of intermediaries transferring aggregated promises to pay. We really need an open system, which IBM is not, which goes down to millicent values, which IBM does not, and which supports intermediaries moving aggregated transactions, so that customer and server to not have to be clients of the same intermediary, which IBM does support, and previous proposals for micropayment did not. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Wew5mzbrzY0w3HicOSQ4AfZq5mUz1m+2tsx31B+Z 4qFN1ClYcfHx6uSYTNssozZoWye7rdANKGzzp16kS ----------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the omnipotent state. http://www.jim.com/jamesd/ James A. Donald
-- At 08:43 PM 9/27/98 -0700, James A. Donald wrote:
IBM is proposing that anyone, or many people, will be free to act as issuers of promises to pay in their proposed microcash system.
At 12:22 AM 9/28/98 -0400, Robert A. Costner wrote:
I don't think you gave a URL for the IBM system.
http://www.hrl.il.ibm.com/mpay
Since you got me interested, I went and looked at the "MilliCent" branded product from Digital/Compaq.
http://www.millicent.digital.com/
Millicent is currently free in that scrip is not cash. I have to laugh in that MilliCent has a granularity of 1/10 of a penny. So why call it millicent?
It looks like millicent could be used to pay for web based sending of anonymous messages, but only if you have an NT server (or use theirs) and only if you browse from windows.
Maybe if I find a millicent type system that works with a Linux server, especially a "non money" one, I might setup a web based mailer that works with it. It would make a nice weekend project. I'm been thinking of revamping the dragoncon.net mailer anyway.
What we really need is an open standard with very fine potential granularity and the intermediary capabilities of Microsoft. Such a project is quite large. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG zRXCi1S3PQe8A82QKJfHfUZKc6zitJTY6L/I82Tu 4VsX/hdqg717QA4khZefRZ8nu2RJD3DzKv9ZNLjdK ----------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the omnipotent state. http://www.jim.com/jamesd/ James A. Donald
On Sun, 27 Sep 1998, James A. Donald wrote:
We really need an open system, which IBM is not, which goes down to millicent values, which IBM does not, and which supports intermediaries moving aggregated transactions, so that customer and server to not have to be clients of the same intermediary, which IBM does support, and previous proposals for micropayment did not.
--digsig James A. Donald
Sound like we need something like a GPL for digital cash protocols/algorithms. That would keep it from being monopolized by a few power players. Someone has to be working on this. jim
At 9:32 PM -0500 9/27/98, Robert A. Costner wrote:
At 05:10 PM 9/27/98 -0700, James A. Donald wrote:
One cent, or half a cent, is probably the sweet spot for pages and dirty picture, with quarters being the sweet spot for games and gambling.
I would suggest millicent to 1/100 of a penny for web page access. A penny a click would make me think twice, 1/100 of a penny would not cause me to consider it. But to be honest, today I would avoid a pay site and go to the free sites.
That being the case, I'd say a penny is just right. Enough to make one think, but not too hard.
But for the scheme to be successful, we need many token issuers Is there existing open software available for this?
The problem isn't issueing the tokens, it's the wallets. Token generation would be relatively straight forward, it's the user end. -- petro@playboy.com----for work related issues. I don't speak for Playboy. petro@bounty.org-----for everthing else. They wouldn't like that. They REALLY Economic speech IS political speech. wouldn't like that.
Christopher Petro writes on cypherpunks:
That being the case, I'd say a penny is just right. Enough to make one think, but not too hard.
Make it 1/100 of a penny; then if someone wants to charge 1p they can charge 100 of them, the other way is not as easy to arrange.
But for the scheme to be successful, we need many token issuers Is there existing open software available for this?
The problem isn't issueing the tokens, it's the wallets. Token generation would be relatively straight forward, it's the user end.
The biggest problem is buying ecash, instantly. It has to be instant, and accountless, because otherwise people are going to walk off in disgust and try somewhere else. You want to buy ecash tokens with plastic. Ideally you want to be able to buy ecash tokens with an ATM card because you don't want to incur any withdrawal fee (ATM withdrawals incur no transaction fee the UK, US may be different.) Buying ecash tokens with a credit card is going to result in the cash advance minimum fee, plus unwanted (and typically double digit APR) interest on the "advance". Debit cards are a bit cheaper, but still incur some fee (unless a bank could be persuaded to waive it for this class of transaction). Due to the instant, accountless requirement, you need to say implement it as a signed java applet, which implements a protocol allowing you to authenticate yourself to the ATM network with your PIN and card number. Problem: it's rather easy to hack, would take some fraction of a second to try all 10,000 pin numbers, although if the check is online, they could disable the card after 3 tries or so. Still the problem persists: attacker obtains (or generates) valid (or possibly valid) credit card numbers, uses up the 3 tries on each card number, and moves onto the next number. They will get a sucess every 3,333 card numbers on average. (This attack is as a by-product going to annoy a lot of people who have their cards disabled as a result.) Artificial delays won't work because the attacker can parallelise via multiple IP addresses on card numbers and PINs in randomised sequences. So because of the inherent naffness of ATM security, you are stuffed. David Birch suggested that the European smart card based credit/debit cards (EMV cards) would be better because they are more secure. However this has the start up cost of a smart-card reader, and violates the requirement for instant, accountless (and especially hardwareless) use. Ideas for beefing up ATM PIN based security using existing hardware (deployed Cards and PINs), to get it to an acceptable level of security with a low enough user interaction overhead. Adam
On or about 11:49 PM +0100 9/28/98, Adam Back wrote:
You want to buy ecash tokens with plastic. Ideally you want to be able to buy ecash tokens with an ATM card because you don't want to incur any withdrawal fee (ATM withdrawals incur no transaction fee the UK, US may be different.)
In the case of my US bank it's the opposite: ATM withdrawals, unless I use a machine owned by my bank, cost me US$1.50. Credit card fees on the other hand are paid by the merchant, who is contractually bound NOT to pass them on to me.
Buying ecash tokens with a credit card is going to result in the cash advance minimum fee, plus unwanted (and typically double digit APR) interest on the "advance".
Debit cards are a bit cheaper, but still incur some fee (unless a bank could be persuaded to waive it for this class of transaction).
My debit card functions as both ATM and credit card. When given a choice I will always prefer to use it as a credit card, which costs me nothing. -Lazlo
Lazlo Toth writes:
On or about 11:49 PM +0100 9/28/98, Adam Back wrote:
You want to buy ecash tokens with plastic. Ideally you want to be able to buy ecash tokens with an ATM card because you don't want to incur any withdrawal fee (ATM withdrawals incur no transaction fee the UK, US may be different.)
In the case of my US bank it's the opposite: ATM withdrawals, unless I use a machine owned by my bank, cost me US$1.50. Credit card fees on the other hand are paid by the merchant, who is contractually bound NOT to pass them on to me.
Not directly as an added charge. But they do indeed pass it on. The card associations won't let them directly charge an added amount for using a credit card, because that would remind consumers that they're paying for the privlidge.. and that might discourage them from using plastic. But it's ok for the merchant to offer 'discounts' for buyers who use cash instead of credit cards. That 'discount' is the real price of the goods with the credit-card surcharge subtracted. Often that's 3-4%, sometimes as low as 1.2%.
Buying ecash tokens with a credit card is going to result in the cash advance minimum fee, plus unwanted (and typically double digit APR) interest on the "advance".
Debit cards are a bit cheaper, but still incur some fee (unless a bank could be persuaded to waive it for this class of transaction).
My debit card functions as both ATM and credit card. When given a choice I will always prefer to use it as a credit card, which costs me nothing.
It still costs you the credit fee, hidden inside the purchase price. Visa and MasterCard don't have massive staffs and huge office buildings because they're dumb. -- Eric Murray N*Able Technologies www.nabletech.com (email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5
At 05:10 PM 9/27/98 -0700, James A. Donald wrote:
Few people use encryption technology today, because few people have real need of it.
I would tend to disagree with this. Instead, few people use encryption technology today because encryption technology is seldom transparent to the user. Few users "think" encryption when they use SSL. It is transparent. I suspect that if you were to survey recent users of SSL pages, you would find that most believe they have not used encryption in the last week. When PGP 5.x came out, suddenly encryption became, not widely used, but much more widely than before. Encryption in email became somewhat transparent in the sending process of email, but still non transparent in the transport and receiving of the email. The user can easily tell the difference between an encrypted and a non encrypted message. This non transparent quality is still a problem. Compare this with forged headers (which mainly are hidden in most email clients). Forged headers are transparent to the receiver until a closer look is made. To compare the two, with encrypted email the message is not readily apparent. An action must be taken (with Eudora/PGP and S-Mime about four actions) to see the text of the message. On the other hand, with forged headers the message is apparent, and an action must be taken to determine that it is not a valid message. If my email came to me encrypted, only decipherable with my private key with no passphrase or other action by me, I would be happy. My computer sits next to a drawer containing a pile of cash. I perceive the cash to be secured. I also perceive my computer to be secured. I want my encryption transparent.
reasonably liquid net money... so they have little need to encrypt their messages
I personally would like all my cell phone, cordless phone, and email communications transparently encrypted. If it were an option, and was seamless transparent, and the same price, then I suspect most people would as well.
If several banks in some moderately popular banking haven allowed people to transfer funds instantly and cheaply from
Yes, this has been a big problem. Teller machines are now at about $1 per transaction to cross networks. Most of the internet payment systems require a large chunk of the money be retained by the processing system. Secure servers often want 12% to 50% of the transaction. PC banking has monthly charges.
One cent, or half a cent, is probably the sweet spot for pages and dirty picture, with quarters being the sweet spot for games and gambling.
I would suggest millicent to 1/100 of a penny for web page access. A penny a click would make me think twice, 1/100 of a penny would not cause me to consider it. But to be honest, today I would avoid a pay site and go to the free sites.
Obviously pay pages cannot and should not be searched by search engines
If my pages were for pay, I would want them to turn up in the search engines. This is easy enough. When I examine my logs, I can easily see when certain search engines come looking. The micropayment software simply has to be configurable to allow certain IP addresses to be allowed to pass without paying.
But for the scheme to be successful, we need many token issuers
Is there existing open software available for this? -- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key
At 08:43 PM 9/27/98 -0700, James A. Donald wrote:
IBM is proposing that anyone, or many people, will be free to act as issuers of promises to pay in their proposed microcash system.
I don't think you gave a URL for the IBM system. Since you got me interested, I went and looked at the "MilliCent" branded product from Digital/Compaq. http://www.millicent.digital.com/ Millicent is currently free in that scrip is not cash. I have to laugh in that MilliCent has a granularity of 1/10 of a penny. So why call it millicent? It looks like millicent could be used to pay for web based sending of anonymous messages, but only if you have an NT server (or use theirs) and only if you browse from windows. Maybe if I find a millicent type system that works with a Linux server, especially a "non money" one, I might setup a web based mailer that works with it. It would make a nice weekend project. I'm been thinking of revamping the dragoncon.net mailer anyway. -- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key
-- At 04:06 PM 9/28/98 -0500, Petro wrote:
The problem isn't issueing the tokens, it's the wallets. Token generation would be relatively straight forward, it's the user end.
On the contrary, it is the server end that is hard. Token generation is trivial. Paying for tokens and getting paid for them is not trivial. The problem is that we do not want to force everyone in the universe to be the clients of a single giant issuer. That would bring us right back to the old problem of the tyrannical and oppressive central bank. Visualize the following situation. I buy tokens from Bob, who may be my local ISP. I spend them on a server on a site in Sri Lanka. The owner of the server cashes them with Evonne. My money, aggregated with a multitude of other peoples money in a multitude of other peoples transactions flows by some complex and indirect route to through several different people, and eventually to Evonne, and finally to the owner of the server in Sri Lanka. This is the problem that IBM software, for all its faults, does address, and it is a hard problem. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG RP+4+If1PSzkOerZiquLbdw7GFRzWkLNjIpl59ZX 4XzwciXVO1P+jKBeMQjD7fwhYVJqnuMtiNYJ/PnL2 ----------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the omnipotent state. http://www.jim.com/jamesd/ James A. Donald
participants (8)
-
Adam Back
-
Anonymous
-
Eric Murray
-
James A. Donald
-
Jim Burnes
-
Lazlo Toth
-
Petro
-
Robert A. Costner