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
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
----- Original Message ----- From: "Ian Grigg" <iang@systemics.com> To: "Hal Finney" <hal@finney.org> Cc: <cryptography@metzdowd.com>; <cypherpunks@al-qaeda.net>; <em@em.no-ip.com> 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
(Guys, this has drifted out of crypto into finance, so I have a feeling that it will disappear of the crypto list. But the topics that are raised are interesting and important enough to carry on, I think.)
[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. [iang:] 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. [enzo:] 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.
An excellent description; I was unaware that the system could be used in a non-credit fashion. Thanks for correcting me.
Generally speaking, it is debatable whether "doing banking" only means "accepting deposits and providing credit" or also "handling payments for a fee":
There are many definitions of "banking" and unfortunately they are different enough that one will make mistakes routinely. Here are the most useful three that I know of: 1. borrowing from the public as deposits and lending those deposits to the public. This is the favoured definition for economists, because it concentrates on the specialness that is banking, which is the foundation for its special regulatory structure. 2. Banking is what banks do, and banks do banking. This is the favoured definition of banks, and often times, regulators, because it gives them a free hand to exploit their special franchise / subsidy. It was codified in law in many countries as just this, but I believe it is out of favour to write it down these days. However, the Fed and other US regulators have from time to time resorted to this definition, when convenient. 3. Banking is what the regulator says is banking. This is the favoured definition of regulators, and sometimes of banks. It means that there is little or no argument or discussion in protecting the flock. This is the much more prevalent in smaller countries, where the notion of "sending in the lawyers" is simply too expensive. 4. There is a popular definition that says something like, if it is to do with money it is banking. That's not a very useful one, but it's prevalent enough to need to be aware of it.
... 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.
Right! (Although, I'd suggest that the "payment systems regulatory" question is polarised between the Fed and the German model. In the German model, payment systems are part of banking, and are subject to heavy regulation. I've not heard of the Germans and their followers accepting the Fed model. This debate is played out in the EU over and over again, and there it can be loosely characterised as the Germans + supporters versus the Brits plus supporters.)
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.
Well, one could speculate on that and many other things. Perhaps an anecdote would illustrate that better than I can in more speculation: in the very early days, e-gold did go to the Fed and ask them if they considered e-gold to be ... within interest. The Fed said, "gold is not money and therefore it is not of interest." This would have been back in 97 or so. Now, that's what the Fed said then. Obviously they are using definition #3 above. And, just as obviously, things can change...
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?
If the separate party were to hold and create credit based on contracts of deposit, using e-gold as the money and as the accounts system, this would be doing banking according to definition #1 above. However, note that it would have both the advantages of both a hard money - 100% reserved digital gold - and the advantages of fractional reserve. The bank could only lend out what it had attracted in deposits, which would result in a stable multiplier. The trick is to separate the payment system from the bank! The easiest way to do this is to ban payment systems from being near or related to credit systems, which is what we espouse in our unregulated finance systems governance models. (This is why e-gold is a payment system in Nevis, and G&SR is a seller of e-gold for dollars in Florida. On paper at least, G&SR can go bankrupt and e-gold carries on.) The offerers of credit and loans were all third parties that more or less had nothing to do with e-gold. Such separation, in theory, allows the creation of a stable credit expansion system which is only limited by the efficiency of the players. iang
participants (3)
-
Enzo Michelangeli -
hal＠finney.org -
Ian Grigg