your favorite protocols

dmolnar dmolnar at hcs.harvard.edu
Sat Dec 30 01:28:24 PST 2000




On Fri, 29 Dec 2000, Greg Broiles wrote:

> I realize that the original citation was meant as an example of the
> difficulty of reaching crypto standards, but this "smart contracts"
> crap is really sticking in my throat this week. 

I agree with you that the term is stretched a bit thin. Still, there seem
to be at least two major things which fall under it in the work I've seen

	1) "Digital Rights Management" - which you mentioned below
	2) Contract languages like E (www.erights.org) and 
	the Haskell combinator library discussed in
 
Simon Peyton Jones, Jean-Marc Ebert, and Julian Seward in ICFP 2000 
``Composing Contracts: an Adventure in Financial Engineering.''
http://riss.keris.or.kr:8080/pubs/articles/proceedings/fp/351240/p280-jones/p280-jones.pdf
(thanks to Norman Ramsey for the reference)

It's unfortunate that the Franklin and Durfee paper focused on 1) as their
raison d'etre for their protocol -- for all the reasons you cited. It's
not clear that 1) will fly, and even if it does, the end user won't be
doing much meaningful negotiation...

Even so, it seems to me that their techniques will have wider application.
Suppose Alice wants to selectively reveal parts of her contact with Bob to
Carol -- maybe she wants to convince Carol that Bob didn't give Alice a
better price than Bob did to Carol in order to win Carol's goodwill. 
The techniques in the paper seem to  allow Alice to do that without having
to reveal exactly what her price from Bob was (or learn what Carol's price
was, for that matter) -- and have it backed up by a contact signed by Bob. 

Then again, I don't know how often these kinds of situations come up in
real life...or will come up in the future. 

 > 
> It's really unfortunate that the crypto community seems determined to
> take words which have relatively specific and nuanced legal definitions
> and overload them with cartoonish definitions - the math tricks described
> therein are interesting, but bear no relationship to contracts as 
> lawyers and courts understand that term. The behavior described is 
> closer to licensing, but is unlikely to create an actual license without
> careful attention.

Where would I go to learn about the difference between contracts and
licenses so as to understand what you mean here? (Besides law school;
that's still an option for me, but not now). Because I'd like to avoid
contributing to this problem if that's possible...

Thanks, 
-David






More information about the cypherpunks-legacy mailing list