Enzo Michelangeli writes: > In the world of international trade, where mutual distrust between buyer > and seller is often the rule and there is no central authority to enforce > the law, this is traditionally achieved by interposing not less than three > trusted third parties: the shipping line, the opening bank and the > negotiating bank.
Interesting. In the e-gold case, both parties have the same bank, e-gold ltd. The corresponding protocol would be for the buyer to instruct e-gold to set aside some money which would go to the seller once the seller supplied a certain receipt. That receipt would be an email return receipt showing that the seller had sent the buyer the content with hash so-and-so, using a cryptographic email return-receipt protocol. > > You could imagine a trusted third party who would inspect the code and > > certify it, saying "the source code with hash XXX appears to be > > legitimate Cisco source code". Then they could send you the code bit > > by bit and incrementally show that it matches the specified hash, > > using a crypto protocol for gradual release of secrets. You could > > simultaneously do a gradual release of some payment information in the > > other direction. > > But it's hard to assess the value of partially-released code. If the > gradual transfer bits-against-cents is aborted, what is left to the buyer > is likely to be unusable, whereas the partial payment still represents > good value. Actually you can arrange it so that neither the partially-released code nor the partially-transferred ecash is of any value until the whole transfer finishes. For example, send the whole thing first in encrypted form, then release the encryption keys bit-by-bit. If someone aborts the protocol early, the best each side can do is a brute force search over the untransferred bits to try to find the key to unlock the data they received. > A more general issue is that source code is not a commodity, and > intellectual property is not "real" property: so the traditional "cash on > delivery" paradigm just doesn't work, and looking for protocols > implementing it kind of moot. If the code is treated as trade secret, > rather than licensed, an anonymous buyer may make copies and resell them > on the black market more than recovering his initial cost, at the same > time undercutting your legitimate sales (see e.g. the cases of RC4 and > RC2). This can cause losses order of magnitude larger than refusing to pay > for his copy. That's a good point. Maybe you could use some kind of DRM or trusted computing concept to try to force the buyer to lock up his received data. For source code that would be pretty difficult though, it needs to be handled in flexible ways. Hal
