Re: Your source code, for sale

2004-11-18 Thread Ian Grigg
 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

2004-11-18 Thread Enzo Michelangeli
- 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

2004-11-18 Thread Ian Grigg


 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

2004-11-06 Thread Enzo Michelangeli
- 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

2004-11-06 Thread Ben Laurie
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

2004-11-06 Thread Michael_Heyman
 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

2004-11-06 Thread Hal Finney
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

2004-11-06 Thread Taral
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

2004-11-06 Thread R.A. Hettinga
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

2004-11-04 Thread Hal Finney
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]