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

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

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

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