Your source code, for sale

Enzo Michelangeli em at em.no-ip.com
Fri Nov 5 03:10:56 EST 2004


----- Original Message ----- 
From: ""Hal Finney"" <hal at finney.org>
Sent: Friday, November 05, 2004 7:01 AM

> "Tyler Durden" writes:
> > So my newbie-style question is, is there an eGold that can be
> > verified, but  not accessed, until a 'release' code is sent?
> >
> > In other words, say I'm buying some hacker-ed code and pay in egold.
> > I don't  want them to be able to 'cash' the gold until I have the
> > code. Meanwhile,  they will want to see that the gold is at least
> > "there", even if they can't cash it yet.
> >
> > Is there a way to send a 'release' to an eGold (or other) payment?
> > Better  yet, a double simultaneous release feature makes thing even
> > more interesting.

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. First, the buyer asks his bank to open an irrevocable
letter of credit (L/C), which is a letter sent to the seller's bank
instructing it to pay the seller once the latter presents a given set of
documents: these usually include the "bill of lading" (B/L), issued by the
shipping line to declare that the desired cargo was indeed loaded on
board. The seller gets the letter of gredit from his bank and is now sure
that he will be paid by the latter (which he trusts); so he purchases or
manufactures the goods, delivers them to the shipping line getting the
B/L, passes it together with the other documents to his bank, and draws
the payment. The seller's bank sends by mail the documents to the buyer's
bank (which it trusts due to long-standing business relationships),
knowing that it will eventually receive the settlement money. The buyer's
bank receives the documents, debits the buyer's account, remits the monies
to the seller's bank, and delivers the documents to the buyer. When the
ship arrives to the buye's seaport, the buyer goes to the shipping line,
presents to it the B/L and in exchange gets the cargo (in sea shipments,
the B/L represents title to the goods).

> I've been thinking about how to do this kind of thing with ecash.

That's way trickier because there are no trusted third parties, not even
e-gold Ltd. / G&SR, Inc. The trust chain with the L/C works well because
delegation of trust is unnecessary: every link in the chain bears
responsibility only to its adjacent links.

[...]
> In the case of your problem there is the issue of whether the source
> code you are buying is legitimate.  Only once you have inspected it and
> satisfied yourself that it will suit your needs would you be willing
> to pay.  But attaining that assurance will require examing the code in
> such detail that maybe you will decide that you don't need to pay.

Interestingly, with L/C's this problem is addressed by involving yet
another third party: an internationally-recognized inspection company
(e.g., the Swiss SGS) that issues a document certifying that the cargo is
indeed what the buyer expects and not, i.e., bricks. Banks and shipping
lines don't want to get involved in these issues; the seller's bank will
only check all the documents requested by the L/C (possibly including the
inspection certificate).

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

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.

Enzo


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list