----- Original Message ----- From: ""Hal Finney"" <hal@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