Re: Pricing Mojo, Integrating PGP, TAZ, and D.C. Cypherpunks
Greg Broiles writes:
And that problem seems to be at the center of Nomen Nescio's sotto voce suggestion that some unnamed cypherpunks work up a currency which can be used to "pay" people for providing information which is of value -
It's not a matter of unnamed cypherpunks doing a favor, but rather a proposal offered to see if there is support. If a few people spoke up with agreement that such an effort were worth doing, the next step would be to put together a project, perhaps on sourceforge, and get some code into play. But if you run the flag up and no one salutes, then you should wait for a better idea.
I get the impression that s/he is imagining some magic fairy would mint up piles of the currency, and assign it equally to every subscriber, who would then be empowered to pay it to the content providers they liked best.
That's very warm and fuzzy and hippy-like, but if these tokens are handed out for free, then what, exactly, is their value?
This is the problem of initial distribution. Ideally there would be some way to give every person a fixed initial allocation, but in practice this will allow people to create new identities ("nyms") and get more than their share. It seemed that part of MojoNation's reason for backing away from mojo-as-money was the problem of fairly giving an initial allocation. Here's an idea which has been proposed before: use hashcash to purchase e-coins. Hashcash is a hash collision generated by a certain number of standard CPU hours of work. To enter into the ecash economy you could generate hashcash and send it to the server, getting ecash in exchange. Ecash is more suitable than hashcash as a form of currency as it can be transferred and exchanged at the bank with little effort or expense. But the problem is acquiring the initial ecash without the overwhelming inflation that Greg Broiles implicitly warns against. By basing ecash on hashcash which involves a significant expense to generate, you avoid inflation. In this system, the ecash "bank" would not be a bank at all. It would have two functions: give out some ecash given hashcash; and give out some (fresh) ecash given other ecash. The latter would use the double spending database and all that. If you received some ecash as payment you would immediately exchange it at the bank which will simultaneously verify that the cash is good and give you fresh coins for later spending. The ecash server is simply an exchanger. These are serious proposals. With Ben Laurie's lucre library and a berkeley db for the double spending database, a basic server could be put together in a few hours' work. Adam Back's hashcash software can be used as a client to generate the initial requests. The basic pieces are all here, no magic fairies required. The main question is again whether there exists an initial market which could be enticed into trying out this package on an experimental basis.
At 08:55 PM 11/24/2001 -0600, Incognito Innominatus wrote: <snip>
These are serious proposals. With Ben Laurie's lucre library and a berkeley db for the double spending database, a basic server could be put together in a few hours' work. Adam Back's hashcash software can be used as a client to generate the initial requests. The basic pieces are all here, no magic fairies required.
The main question is again whether there exists an initial market which could be enticed into trying out this package on an experimental basis.
Look at the significant uptake for e-gold (current transaction rate about $1 million day) as an example of how to bootstrap a creditable value system. As for how to get value into the system and avoid inflation the answer is to use a recognized value store as backing: U.S. currency. IMHO, the code code isn't the hard part but all UI, back office systems and logistics of running such an operation. Ian Grigg has toiled for many years to create open source components for value store, payment and transaction systems. A look at his http://www.webfunds.org is a good place to start. At the July BA CP meeting an attempt was made to develop a consensus of where the opportunities for ecash lay. The strongest and most informed opinions are in general agreement with Tim May's 8/25 posting "The Privacy/Untraceability Sweet Spot" The second reason for the meeting was to assess interest in creating an ecash API and a reference open source implementation. AFAIK no progress on these second purpose has been made but if anyone is looking to get involved please count me in. steve
participants (2)
-
Incognito Innominatus
-
Steve Schear