Re: Your source code, for sale
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. This is to mix up banking and payment systems. Enzo's description shows banks doing banking - lending money on paper that eventually pays a rate of return. In contrast, in the DGC or digital gold currency world, the issuers of gold like e-gold are payment systems and not banks. The distinction is that a payment system does not issue credit. So, in the e-gold scenario, there would need to be similar third parties independent of the payment system to provide the credit moving in the reverse direction to the goods. In the end it would be much like Enzo's example, with a third party with the seller, a third party with the buyer, and one or two third parties who are dealing the physical goods. There have been some thoughts in the direction of credit creation in the gold community, but nothing of any sustainability has occurred as yet. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your source code, for sale
- Original Message - From: Ian Grigg [EMAIL PROTECTED] To: Hal Finney [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, November 07, 2004 11:21 AM [Hal:] 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. This is to mix up banking and payment systems. Enzo's description shows banks doing banking - lending money on paper that eventually pays a rate of return. In contrast, in the DGC or digital gold currency world, the issuers of gold like e-gold are payment systems and not banks. The distinction is that a payment system does not issue credit. Actually, seeing issuance and acceptance of L/C's only as a money-lending activity is not 100% accurate. Letter of credit is a misnomer: an L/C _may_ be used by the seller to obtain credit, but if the documents are sent for collection rather than negotiated, the payment to the seller is delayed until the opening bank will have debited the buyer's account and remitted the due amount to the negotiating bank. To be precise: when the documents are submitted to the negotiating bank by the seller, the latter also draws under the terms of the L/C a bill of exchange to be accepted by the buyer; that instrument, just like any draft, may be either sent for collection or negotiated immediately, subject, of course, to final settlement. Also, depending on the agreements between the seller and his bank, the received L/C may be considered as collateral to get further allocation of credit, e.g. to open a back-to-back L/C to a seller of raw materials. However, if the documents and the draft are sent for collection, and no other extension of credit are obtained by the buyer, the only advantage of an L/C for the seller is the certainty of being paid by _his_ (negotiating) bank, which he trusts not to collude with the buyer to claim fictitious discrepancies between the actual documents submitted and what the L/C was requesting. (And even in case such discrepancies will turn out to be real, the opening bank will not surrender the Bill of Lading, and therefore the cargo, to the buyer until the latter will have accepted all the discrepancies: so in the worst case the cargo will remain under the seller's control, to be shipped back and/or sold to some other buyer. If it acted differently, the opening bank would go against the standard practice defined in the UCP ICC 500 (http://internet.ggu.edu/~emilian/PUBL500.htm) and its reputation would be badly damaged). So, the L/C mechanism, independently from allocation of credit, _does_ provide a way out of the dilemma which one should come first, payment or delivery?; and this is achieved by leveraging on the reputation of parties separately trusted by the endpoints of the transaction. Generally speaking, it is debatable whether doing banking only means accepting deposits and providing credit or also handling payments for a fee: surely banks routinely do both, although they do not usually enjoy a _regulatory franchise_ on payments because failures in that field are not usually argued to be capable of snowballing into systemic failures. (Austrian economists argue that that's also the case with provision of credit, but it's a much more controversial issue). In the US, as we know, Greenspan's FED decided several years ago against heavy regulation of the payments business, and most industrialized countries chose to follow suit. So, in the e-gold scenario, there would need to be similar third parties independent of the payment system to provide the credit moving in the reverse direction to the goods. In the end it would be much like Enzo's example, with a third party with the seller, a third party with the buyer, and one or two third parties who are dealing the physical goods. There have been some thoughts in the direction of credit creation in the gold community, but nothing of any sustainability has occurred as yet. That would probably end up attracting unwelcome attention by the regulators. Besides, wouldn't that require some sort of fractional banking, resulting in a money supply multiple of the monetary base by an unstable multiplier, and ultimately bringing back the disadvantages of fiat currencies? Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Your source code, for sale
Yes, I'm looking at ideas like this for ecash gambling, but you have a who-goes-first problem. One side or the other has to rip their own cash first, and then the other side can just go away and leave the first side screwed. The act of ripping cash is relatively atomic and involves a transaction with the ecash mint, so they can't both do it at the same time. I guess the best fix is for each side to rip a little bit of cash at a time, so that the guy who goes first only loses a trivial amount if the other side aborts. Then after a few rounds both sides are sunk pretty deep and both have a strong incentive to complete the transaction. What is wrong with having a TTP, generally called a casino? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your source code, for sale
- Original Message - From: Hal Finney [EMAIL PROTECTED] 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. / GSR, 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 [EMAIL PROTECTED]
Re: Your source code, for sale
Tyler Durden wrote: Hum. So my newbie-style question is, is there an eGold that can be verified, but not accessed, until a 'release' code is sent? proof-of-delivery protocols might help (but they're patented, as I discovered when I reinvented them a few years back). 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. Simultaneous release is (provably?) impossible without a trusted third party. I think this is one of the interesting applications of capabilities. Using them, you can have a TTP who is ignorant of what is running - you and your vendor agree some code that the TTP will run, using capability based code. In your case, this code would verify the eGold payment and the code (difficult to do this part with certainty, of course) and release them when both were correct. Because of the capabilities, the TTP could run the code without fear, and you would both know that it performed the desired function, but neither of you could subvert it. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Your source code, for sale
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Finney, Hal (CR) [SNIP discussion on ripping cash] 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. Quick fix for seller incentive: the seller rips some amount of their own cash in such a way that they cannot recover it unless the buyer provides the remainder of the buyer's ripped cash. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your source code, for sale
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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Your source code, for sale
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 [EMAIL PROTECTED] 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? pgpdoIJZJgFGT.pgp Description: PGP signature
RE: Your source code, for sale
At 10:18 AM -0800 11/5/04, Hal Finney wrote: Yes, I'm looking at ideas like this for ecash gambling, but you have a who-goes-first problem. Whenever we talk about financial applications, where the assets represented by one bearer certificate are exchanged for those represented by another, what's really happening is a redeem-reissue process anyway. Since it's the underwriters' reputations you're trusting anyway, we've always assumed that there would be communication between the underwriters in order to execute, clear, and settle the trade all at once. For streaming stuff, we figured that since we were streaming cash for streaming bits, like movies, or content of some kind, you'd just do tit for tat, one stream (cash, probably signed probabalistically tested coins in the last iteration that we called Nicko-mint :-)) against another, the movie, song, etc being streamed. There's the missing last 5 minutes problem, but I think that, in recursive auction-settled cash market for digital goods like this (Eric Hughes' institutional 'pirate' scheme, the 'silk road' stuff, whatever), that there will always be another source to buy what's left from, once the intellectual property issues solve themselves because of the auction process. For things that aren't useful except in their entirety, like code, or executables, (or storing money :-)), I've always been a fan of the Mojo/BitTorrent stuff, where you hash the file into bits, ala m-of-n Shamir secret splitting, and store/buy them from lots of places at once. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]