RE: Your source code, for sale
"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.
I've been thinking about how to do this kind of thing with ecash. One project I'm hoping to work on next year is a P2P gambling game (like poker or something) using my rpow.net which is a sort of play-money ecash. You'd like to be able to do bets and have some kind of reasonable assurance that the other guy would pay up if he loses. 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. 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. If you don't have a TTP, one idea for using ecash is Markus Jakobsson's "Ripping Coins for a Fair Exchange". Basically you withdraw ecash from your account and in effect "rip it in half" and give half to the seller. Now he gives you the product and you give him the other half of the coin. The idea is that once you have given him the "ripped" ecash ("torn" would be a better word because ripping means something else today), you are out the value of the cash. You have no more incentive to cheat, as giving him the other half won't cost you anything additional. (Even without ecash, a service like egold could mimic this functionality. You'd create an escrow account with two passwords, one known to each party. Only with both passwords could data be withdrawn from the account. Then the buyer would transfer funds into this account. After receiving the goods, the buyer would send his password to the seller.) The problem is that if the source code you are purchasing is bogus, or if the other side doesn't come through, you're screwed because you've lost the value of the torn cash. The other side doesn't gain anything by this fraud, but they harm you, and if they are malicious that might be enough. And likewise you might be malicious and harm them by refusing to give them your half of the coin even after you have received the goods. Again, this doesn't benefit you, you're still out the money, but maybe you like causing trouble. Another idea along these lines is gradual payment for gradual release of the goods. You pay 10% of the amount and they give you 10% of the source code. You pay another 10% and you get the next 10% of the source, and so on. (Or it could be nonlinear; maybe they give out half the code for free, but the final 10% requires a large payment.) The idea is that you can sample and make sure they do appear to have the real thing with a fairly small investment. If there is some mechanism for the seller to have a reputation (like Advogato's perhaps, with some spoofing immunity) then the problem is easier; the seller won't want to screw buyers because it hurts his rep. In that case it may be reasonable to ask the buyer to pay in advance, perhaps using the partial payment system just discussed. These various ideas all have tradeoffs, and in general this kind of problem is hard to solve because of the complexity of what constitutes a successful transaction. A reputation system helps a great deal to resolve the issues, but opens up problems of its own. The betting problem I want to work on is relatively easy because there is no ambiguity about who wins, but even then it is hard to make sure that neither party can maliciously harm the other. Hal F.
On Thu, 4 Nov 2004, Hal Finney wrote:
Another idea along these lines is gradual payment for gradual release of the goods. You pay 10% of the amount and they give you 10% of the source code. You pay another 10% and you get the next 10% of the source, and so on.
Just as an aside, this is in fact how it was being initially marketed. -- Yours, J.A. Terranson sysadmin@mfn.org 0xBD4A95BF "An ill wind is stalking while evil stars whir and all the gold apples go bad to the core" S. Plath, Temper of Time
----- 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
On Thu, Nov 04, 2004 at 03:01:15PM -0800, "Hal Finney" wrote:
Another idea along these lines is gradual payment for gradual release of the goods. You pay 10% of the amount and they give you 10% of the source code. You pay another 10% and you get the next 10% of the source, and so on. (Or it could be nonlinear; maybe they give out half the code for free, but the final 10% requires a large payment.) The idea is that you can sample and make sure they do appear to have the real thing with a fairly small investment.
If there is some mechanism for the seller to have a reputation (like Advogato's perhaps, with some spoofing immunity) then the problem is easier; the seller won't want to screw buyers because it hurts his rep. In that case it may be reasonable to ask the buyer to pay in advance, perhaps using the partial payment system just discussed.
The mojonation file sharing system had an implementation like this originally... -- Taral <taral@taral.net> This message is digitally signed. Please PGP encrypt mail to me. A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
participants (4)
-
Enzo Michelangeli -
hal＠finney.org -
J.A. Terranson -
Taral