1996-11-19 - Re: Crypto Bounties: Another Thought that crossed my mind.

Header Data

From: snow <snow@smoke.suba.com>
To: iang@systemics.com (Ian Grigg)
Message Hash: 25e592b93c0a349ed5878c67d5078594c7cc47ec19bb035d1102983f5b97a3b0
Message ID: <199611191105.FAA00216@smoke.suba.com>
Reply To: <3290992F.2781E494@systemics.com>
UTC Datetime: 1996-11-19 10:48:21 UTC
Raw Date: Tue, 19 Nov 1996 02:48:21 -0800 (PST)

Raw message

From: snow <snow@smoke.suba.com>
Date: Tue, 19 Nov 1996 02:48:21 -0800 (PST)
To: iang@systemics.com (Ian Grigg)
Subject: Re: Crypto Bounties: Another Thought that crossed my mind.
In-Reply-To: <3290992F.2781E494@systemics.com>
Message-ID: <199611191105.FAA00216@smoke.suba.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

     Correct term, but not necessarily accurate. 

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

     Not necessarily. It could be set up to keep the Bounty open, to provide
a revenue stream for upgrades, or second, third & etc. bounties for upgrades
bug fixes and new features. 

> 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

     <snip>

> eliminates the need for judges.  History shows that a good market
> microstructure will beat an authority approach in the long run.

     Reputation could also eleminate the need for judges. If Matt Blaze, 
or Randall S. were to try to claim a specific bounty, people would be 
more likely to accept their claim than if I were to do so. 

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

    If it is GNU'd, then there is no one to buy out. I like the idea of 
"free" software. As it stands now, there is a lot of very high quality 
software free software out there (hell, all of the software I use _daily_
is "free" software), and if no one owns it, the government can't use 
copyright laws to restrict it. The feds _can't_ buy it out for a million 
dollars. 

     The other thing about the "bounty server" is that it is simpler to
set up (at least as far as I can see) than your contract model. 

     All you would need is to settle up the details, set up a web server
with the ability to handle ecash, and some sort of accounting and you are
off. Maybe, just to prove you are legit, a performance bond. 


Petro, Christopher C.
petro@suba.com <prefered for any non-list stuff>
snow@smoke.suba.com





Thread