From: Ian Grigg <iang@systemics.com>
Date: Mon, 18 Nov 1996 09:12:04 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: Crypto Bounties: Another Thought that crossed my mind.
In-Reply-To: <199611172011.PAA17213@alpha.pair.com>
Message-ID: <3290992F.2781E494@systemics.com>
MIME-Version: 1.0
Content-Type: text/plain


snow@smoke.suba.com said:
>       Well, I was thinking, what if a "Crypto Software Bounty Server"
>  were set up, so that someone could propose a tool that they would like
>  to see, along with an initial bounty. Others could contribute toward that
>  bounty (anonymously if they wish) until either the tool was delivered.
> 
>       The original issuer sets standards for the software (i.e. "easy to
>  use interface to mixmaster remailers for Macintosh", then must define
>  easy to use; Software considered delivered when in [alpha beta late-beta
>  &etc.]). The first to present software meeting these qualifications gets
>  the bounty, with the caviate that the software must be either gnu-copylefted,
>  or some similar "free use" copyright, after all, "The Net" paid for it...

Hmmm.  This is a one shot game (is that the term?) whereas software
generally has implications that escape a single sale scenario.  For
example, the more difficult the software, the more risk there is that
someone else will beat you, thus lowering the real risk-adjusted payoff
dramatically.   For this reason, more complex stuff would need some sort
of contract+reputation scenario that allows a repeating game to work.

A contractual alternative could work like this.  I (the initial desirer)
write a contract specifying my requirements.  I publish this as a market
tender, where other desirers can contribute funds, and this becomes a
cumulative sum that grows.  Programmers can offer to supply by naming a
price.  The market clears when the pot of desire equals or exceeds the
lowest offer to supply.

In a simplistic scenario, the contract is now sealed and the work is
done and paid for.

In order to overcome project failure, I could write my contract as a
multi-supplier seed project (often done by governments).  That is, the
pot gets shared around, say, the three best alternatives.  Once
supplied, all are free to pick from the alternatives.

In order to overcome the low silly bid, somehow reputation would have to
be built into the market.  That is, your efforts in the past as
programmer will cause your solution to be better valued than mine.

So perhaps we should turn this around.  Programmers would write
contracts to supply the given requirements at clearance+T, also
specifying the clearance price.  Your price is 2000 for the widget, mine
is 1000.  (That makes three contracts, a widget spec, my work plan and
your work plan.)  The market (the desirers) would then push funds back
and forth between the two until it became clear that one or the other
cleared.  As more pressure increases, more funds pour in.

Then, deliverables could be phased, with monies similarly phased, so
that the market has a chance to monitor.  Now, if it is not delivered,
reputation suffers, and you have to lower your price for the next job
(or hide in shame).

There's a lot of aspects of newbies and switching funds that I havn't
really thought through here.  However, I like this viewpoint because it
eliminates the need for judges.  History shows that a good market
microstructure will beat an authority approach in the long run.

Also note that if you drop the free software assumption, and make it,
say, moneyware, then the market becomes much more workable - the asset
being traded is a share of future revenues.  This has more ramifications
than might be obvious:  Propose a market to write a GAK killer for
e$10,000.  If it clears and is built, is the Dept. of Justice forced to
buy the rights out?

> Has anything like this been proposed before?

I don't know if this has been proposed before, but it is a logical
conclusion of the CP world.  If the Internet transaction costs make
single-person economic entities the most efficient unit in the machine,
and e$ in all its forms provides the oil, then we need some way to
connect up the parts for grand projects where there are hard cash
incentives.  There has to be some mechanism to distribute that cash in
the most efficient manner to produce the result.

BTW, this is a here and now issue, not a hypothetical future.  We have
already found that there is too much work on our plate, and limited
efficiency in farming it out.  Others may have found the same.

-- 
iang
iang@systemics.com