On Fri, Dec 29, 2000 at 04:25:05AM -0500, dmolnar wrote:

In view of the recent thread ("That 70's Crypto Show") turning into yet another call for protocol building blocks -- and Wei Dai pointing out very sensibly the problems involved in turning protocols into building blocks -- I think it might help to compile a list of our favorite protocols and problems. Then maybe we can see what common components they share, if any. Finally see if we can make some progress in overcoming the problems that Wei Dai mentioned, or if it really isn't worth the bother.

Earlier you mentioned another problem that I left out, which is that even when two protocols use the same kind of component, they'll use subtly different versions of it to obtain certain performance or security properties or just to "fit in" with the rest of the protocol. I think eventually the problem will turn into how to redesign all of these protocols to use only components from a standard set. Rather than wait for that, I think anyone who wants to implement a protocol should just do it with the currently available tools. My perspective may be warped, but I think even without higher level building blocks, the crypto part of such a project is easy compared to other problems like OS integration, scaling, UI design, business planning, marketing, etc., etc. The fact that most interesting crypto protocols are not being used is almost certainly due to a combination of these other problems rather than the difficulty of implementing the crypto.

middlemen and contracts - Franklin and Durfee

Do you have a citation for Franklin and Durfee? Neither Google nor CiteSeer turned up anything.

On Fri, Dec 29, 2000 at 06:17:07AM -0500, dmolnar wrote:

"Distribution Chain Security" M. Franklin and G. Durfee ACM CCS 2000 http://citeseer.nj.nec.com/332962.html

It's actually a not-bad example of how a "standard" crypto component is taken and then tweaked for use in a particular protocol. The standard component is a homomorphic commitment scheme designed by Cramer and Damg*rd and published in 1998. This paper shows how to use it to prove a series of contracts satisfies certain relations w/o revealing the contracts - and then adds a method to make the particular relations they care about more efficient.

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. 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. The citations to support the authors' claims that "Systems to enforce digital contracts are already in place or will be available soon" are to three websites for CPRM-ish schemes - Xerox' "ContentGuard" at <http://www.contentguard.com>, Intertrust at <http://www.intertrust.com>, and SDMI, brainchild of the RIAA, at <http://www.sdmi.org>, and a print citation to an article by Mark Stefik (the person behind the Xerox and Intertrust copy protection schemes) entitled "The Bit and the Pendulum: Balancing the Interests of Stakeholders in Digital Publishing". (I'm not kidding. Those URL's - without links to specific documents - are the references which support the authors' claims about the feasibility of enforceable digital contracts.) One can guess exactly how "balanced" the outcome is likely to be where one stakeholder gets to design and implement (without reverse engineering, thanks to the DMCA) the technical apparatus which will be used to "enforce" the "contracts" between the parties. Stefik's reference to Poe's torture apparatus is perhaps more apropos than he intended. -- Greg Broiles gbroiles@netbox.com PO Box 897 Oakland CA 94604

On Sat, Dec 30, 2000 at 04:28:24AM -0500, dmolnar wrote:

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/... (thanks to Norman Ramsey for the reference)

Thanks for the reference - I'll look at it over the weekend.

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.

I have a hard time imagining this being useful in real life - I'm not interested in seeing only part of a contract, because I've got no idea what the rest of the contract says. The fact that there's language on one page which appears to set particular terms doesn't mean that the language is operative - perhaps it was prefaced with conditions which aren't presently applicable, or are now but won't be in the future. Or perhaps the contract has expired, or is void, or is voidable, or has been breached, or terminated. This seems pretty much exactly comparable to showing a programmer parts of a computer program and asking them to reach a conclusion about the behavior or correctness of the entire program, including the omitted or obscured parts. I can't imagine any sensible person who would act on a contract shown to them by someone else if the someone else refused to show them the entire document - but that's what's proposed in the scheme described in the Durfee and Franklin paper. They do discuss being able to prove (instead of guarantee) that certain terms of the license (which they insist on calling a contract) are within the boundaries of a pre-existing master "contract", which is a good beginning, but they're avoiding a lot of the hard work by assuming that every important term can be represented as a single value, and ignoring the interrelationships between terms or values. For example, "This license is terminable on 30 days' notice at licensor's option if the royalties paid in any calendar year are less than $10,000.00 USD." isn't an uncommon term in a license agreement - how is a sublicensor to prove to a prospective sublicensee that the license hasn't been terminated? They'd need to prove a negative - nonreciept of the notice of termination - which is notoriously difficult. (The middleman could produce proof tending to show that they had not breached, leading to the inference that notice, if given, would have been inappropriate - but that's not the same result.)

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.

My hunch is that it won't - I do still think it's a neat trick, but it sounds a lot like a solution searching for an applicable problem, instead of the other way around.

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

If you are in the mood to read, "Understanding Copyright Law" by Marshall Leaffer is about $30 and hopefully accessible; my favorite reference for contract law is Farnsworth's "Contracts" hornbook, though I fear it may not be as friendly to people who don't have a compelling reason to make their way through it. I am having a hard time thinking of a good way to learn what the books don't explain, which is how to figure out which body of law is applicable to a given problem. I am only getting better at that some 5 years out of law school, and it's not even something where experts agree. Questions about how to organize transactions to minimize the incidence and consequences of failure are very old questions, and legal and insurance people have evolved some pretty detailed approaches to solving common (and uncommon) problems - it's something of a waste of time for people to start working on those problems without learning about what's been tried in the past. That certainly doesn't mean that what's done now is perfect, or efficient - but in many cases it's been shaped by tens or hundreds (or maybe thousands) of years of experience and testing, which does have some value. Mostly I think it's unfortunate that relatively common words like "signature" or "contract" get reused - initially it's not a big problem, because the people close to the theoretical work understand the gulf between their models and the real world - but 5 or 10 years out, we end up with questions like "are digital signatures really signatures" or "is a smart contract a contract" or "do you mean you signed it with a pen, or with your browser?". I guess this is the same process that called cars "horseless carriages" for awhile - people who think of new technologies name them after older things which serve many of the same goals, leading to confusion. That doesn't seem so terrible, but I do think that the "smart contracts" trend ignores the real role of contracts, which is their social role - which is that they're agreements which society will force people to fulfill, not agreements enforced by technology. Both the DRM and the E-rights technologies assume that there can be no meaningful external review of the agrements or the actions of the parties to an agreement, and proceed to limit people's behavior accordingly. That may be a reasonable assumption to make - but it is not law, at least in the way that people talk about "the rule of law". It does limit human behavior - which is the purpose of law - but it does it in a different way (the same way that fences or handcuffs do). Larry Lessig's book "Code" talks a lot about how technology can create its own limits for human action, though I think it's unfortunate that he calls it "law". In any event, it's confusing to a lot of people to mix those two approaches to governing human conduct (or human conduct as expressed through machines) - one consists of verbal expressions which are interpreted by human beings (where that interpretive process may be recursive), another consists of physical things which need or permit no interpretation (though they may contain Turing machines). My own interests and biases lean towards the former model (though I am not such a purist that I refuse to employ locks or guns if necessary), but the second model is also certainly legitimate. My real beef is with people who accidentally or deliberately confuse the two models, because that leads to unproductive thinking and behavior. -- Greg Broiles gbroiles@netbox.com PO Box 897 Oakland CA 94604