RE: Your source code, for sale

[Tyler Durden]

Hum.
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.

-TD
From: "R.A. Hettinga" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Your source code, for sale
Date: Wed, 3 Nov 2004 19:24:43 -0500
<http://www.adtmag.com/print.asp?id=10225>
 - ADTmag.com
Your source code, for sale
By Mike Gunderloy
Well, maybe not yet. But what does the future hold for those who consider
their source code an important proprietary asset?
Halloween this year featured more scary stuff than just ghosts and ghouls.
It was also the day (at least in the Pacific time zone) when the Source
Code Club posted their second Newsletter in a public Usenet group. Despite
their innocent-sounding name, the Source Code Club is a group of hackers
who are offering to sell the source to commercial products. Their current
menu of source code for sale looks like this:
*   Cisco Pix 6.3.1 - $24,000
*   Enterasys Dragon IDS - $19.200
*   Napster - $12,000
They also claim to have the source code for many other packages that they
haven't announced publicly. "If you are requesting something from a Fortune
100 company, there is a good chance that we might already have it, they
say. Now, you might think this business is blatantly illegal, and no doubt
it is. But that doesn't necessarily mean it's impossible. They're posting
their newsletter to Usenet, probably from an Internet cafe somewhere, so
that's not traceable. They'll take orders the same way, and require orders
to be encrypted using their PGP key, which is at least reasonably
unbreakable at the moment. (As of this writing, I don't see any encrypted
messages posted to the newsgroup they use, though). For payment, they're
using e-gold, which claims to protect the anonymity of its account holders.
Now, it seems reasonably likely that the Source Code Club folks will
eventually get caught; going up against Cisco's resources displays at least
a strong conviction of invulnerability. But even if these guys get caught,
there are deeper issues here. Ten years ago, no one could have dreamed of
trying to set up such a business. Ten years from now, advances in
cryptography, more forms of currency circulating on the Internet, and
improvements in anonymity software are likely to make it impossible to
catch a similar operation.
What will it mean when hacker groups can in fact do business this way with
impunity? First, it's important to note that the ability to sell wares
anonymously won't necessarily imply the ability to get inventory. Your best
defense against having your own source code leaked is to pay careful
attention to its physical security. These days, if I were developing an
important commercial product, I'd make sure there was no path between my
development or build machines and the public Internet. Hackers can do lots
of things, but they still can't leap over physical disconnections. Second,
I'd use software that prevents temporary storage devices (like USB sticks)
from connecting to the network, and keep CD and DVD burners out of the
development boxes as well.
It's also worth making sure that your business doesn't depend entirely on
source code. While the intellectual property that goes into making software
is certainly a valuable asset, it shouldn't be your only asset. Think about
ancillary services like training, support, and customization in addition to
simply selling software.
Finally, note that the Source Code Club business model is based on taking
advantage of people wanting to know what's in the software that they
purchase. About the pix code, they say "Many intelligence
agencies/government organizations will want to know if those 1's and 0's in
the pix image really are doing what was advertised. You must ask yourself
how well you trust the pix images you download to your appliance from
cisco.com." Microsoft (among other companies) has demonstrated how to
remove this particular fear factor from customers: share your source code
under controlled circumstances. That doesn't mean that you need to adapt an
open source model, but when a big customer comes calling, why not walk
their engineers through how things work and let them audit their own areas
of concern?
Given the shifting landscape of intellectual property, and the threat from
groups such as the Source Code Club, these are ma

RE: Your source code, for sale

["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.

RE: Your source code, for sale

[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

Re: Your source code, for sale

[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. / 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

RE: Your source code, for sale

[J.A. Terranson]

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
[EMAIL PROTECTED]
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

Re: Your source code, for sale

[Tyler Durden]

Ben Laurie made a lot of useful points. However,...
Simultaneous release is (provably?) impossible without a trusted third 
party.
I don't think I believe this. Or at least, I don't think it's true to the 
extent necessary to make the original application impossible.

Consider:
I send you money for naked photos of Geri Ryan (that Borg chick with the 
ASS-KICKING hips). The money is "encapsulated"...you can its there, but you 
can't get at it.

You send me encapsulated photos, perhaps with thumbnails on the outside.
I see the thumbnails and click to send the pre-release. You see the 
pre-release arrive and click the release for the photos.

My photo-bundle receives the releases and opens, and then shoots off a 
message that activates the pre-release on your end, giving you the cash.

Is a 3rd party necessary here? I don't see it, but then again I could be 
wrong.

-TD
_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: Your source code, for sale

[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

Re: Your source code, for sale

[Chris Kuethe]

On Fri, 05 Nov 2004 10:01:41 -0500, Tyler Durden
<[EMAIL PROTECTED]> wrote:
> ...
> My photo-bundle receives the releases and opens, and then shoots off a
> message that activates the pre-release on your end, giving you the cash.
> 
> Is a 3rd party necessary here? I don't see it, but then again I could be
> wrong.

What if I block the outbound "release the money" message after I
unbundle the images. Sure, I've already committed my money, but you
can't get to it. In effect I've just ripped you off, because I have
usable product and you don't have usable money. The proof of delivery
comes in handy here, so that as soon as I can prove to the bank that
my product has arrived within your administrative area, they'll pay
me. And the bank sends me a key to unlock the product as soon as it
sends you the money.

And what *GUARANTEE* do I have that the blob of bits you sent me with
the Geri Ryan photos on the outside isn't something from goatse.cx or
tubgirl...? Let's say there are 24000 items in the tarball of the IOS
code. Do you want to pay $24K for all of them (once) or $12K for half
of them (twice) or $1 per file or directory (24000 times)? Do you want
to pay per committed bit or character? How can you protect yourself
from me committing to sell you /dev/random?

I'm sure everyone has this bit committed to memory, but the beginning
of Applied Crypto, chapter 2 says:

=
Protocols have other characteristics as well:
-- Everyone involved in the protocol must know the protocol and all of
the steps to follow in advance.
-- Everyone involved in the protocol must agree to follow it.
-- The protocol must be unambiguous; each step must be well defined
and there must be no chance of a misunderstanding.
-- The protocol must be complete; there must be a specified action for
every possible situation.

.. The whole point of using cryptography in a protocol is to prevent
or detect eavesdropping and cheating.
=

That last property is critical: what does the protocol do when someone
isn't playing by the rules? Of course, there's nothing that crypto can
do to prevent you from selling me garbage, only the fact that you
intentionally did so can be proven. Comment about bribing the dockside
worker at the shipping line deleted.

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: Your source code, for sale

[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?


pgpyk4tHG01wV.pgp
Description: PGP signature

Re: Your source code, for sale

[Tyler Durden]

What if I block the outbound "release the money" message after I
unbundle the images. Sure, I've already committed my money, but you
can't get to it. In effect I've just ripped you off, because I have
usable product and you don't have usable money.
Well, yes, but this would be a very significant step forward from the 
current situation. As t-->infinity the vast majority of non-payments are 
going to be for the purpose of greed. If the payment is already 'gone', then 
you need a whole different set of motives for wanting to screw somebody even 
if you get nothing out of it. So in other words, you have at least solved 
the payment problem "to the first order", with no 3rd party. With fancier 
mechanisms I would think you can solve it to 2nd order too.

-TD
_
Check out Election 2004 for up-to-date election news, plus voter tools and 
more! http://special.msn.com/msn/election2004.armx

Re: Your source code, for sale

["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

RE: Your source code, for sale

["Hal Finney"]

Michael_Heyman writes:
> Finney, Hal (CR):
> > 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.

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.

Hal

RE: Your source code, for sale

[R.A. Hettinga]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.3

iQA/AwUBQYvH6cPxH8jf3ohaEQIGGACgiS/Uv3KxDK4rM9lozOoxfI5Fg1QAoP7d
4Xw6/SwfaBOqgyh9uQTS/5oa
=XMiK
-END PGP SIGNATURE-

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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'

Re: Your source code, for sale

[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

Re: Your source code, for sale

[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

Re: Your source code, for sale

[Ben Laurie]

Tyler Durden wrote:

What if I block the outbound "release the money" message after I
unbundle the images. Sure, I've already committed my money, but you
can't get to it. In effect I've just ripped you off, because I have
usable product and you don't have usable money.

Well, yes, but this would be a very significant step forward from the 
current situation. As t-->infinity the vast majority of non-payments are 
going to be for the purpose of greed. If the payment is already 'gone', 
then you need a whole different set of motives for wanting to screw 
somebody even if you get nothing out of it. So in other words, you have 
at least solved the payment problem "to the first order", with no 3rd 
party. With fancier mechanisms I would think you can solve it to 2nd 
order too.
How do you make the payment already "gone" without using a third party?

Re: Your source code, for sale

[Tyler Durden]

Oh, I assumed that this verification 'layer' was disjoint from the e$ layer. 
In other words, you might have a 3rd party e$ issuer, but after that they 
shouldn't be necessaryor, there's a different 3rd party for the 
verification process.

I think that's reasonable, but of course one could argue "what's the point 
if you already need a 3rd party for the e$". But I think that's a disjoint 
set of issues.

-TD
From: Ben Laurie <[EMAIL PROTECTED]>
To: Tyler Durden <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Your source code, for sale
Date: Mon, 08 Nov 2004 11:50:28 +
Tyler Durden wrote:

What if I block the outbound "release the money" message after I
unbundle the images. Sure, I've already committed my money, but you
can't get to it. In effect I've just ripped you off, because I have
usable product and you don't have usable money.

Well, yes, but this would be a very significant step forward from the 
current situation. As t-->infinity the vast majority of non-payments are 
going to be for the purpose of greed. If the payment is already 'gone', 
then you need a whole different set of motives for wanting to screw 
somebody even if you get nothing out of it. So in other words, you have at 
least solved the payment problem "to the first order", with no 3rd party. 
With fancier mechanisms I would think you can solve it to 2nd order too.
How do you make the payment already "gone" without using a third party?
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Your source code, for sale

[Tyler Durden]

Well, I guess once you need a 3rd party for the e$, it's only going to make 
sense that the issuer offer a "value added" service like you're talking 
about. A 3rd party verifier is probably going to be too costly.

But I'm not 100% convinced that you HAVE TO have a 3rd party verifier, but 
it's looking like that's what's going to make sense 99% of the time anyway.

-TD
From: [EMAIL PROTECTED] ("Hal Finney")
To: [EMAIL PROTECTED]
Subject: Re: Your source code, for sale
Date: Mon,  8 Nov 2004 10:51:24 -0800 (PST)
Ben Laurie writes:
> How do you make the payment already "gone" without using a third party?
Of course there has to be a third party in the form of the currency
issuer.  If it is someone like e-gold, they could do as I suggested and
add a feature where the buyer could transfer funds irrevocably into
an escrow account which would be jointly controlled by the buyer and
the seller.  This way the payment is already "gone" from the POV of the
buyer and if the seller completes the transaction, the buyer has less
incentive to cheat him.
In the case of an ecash mint, a simple method would be for the seller to
give the buyer a proto-coin, that is, the value to be signed at the mint,
but in blinded form.  The buyer could take this to the mint and pay to
get it signed.  The resulting value is no good to the buyer because he
doesn't know the blinding factors, so from his POV the money (he paid
to get it signed) is already "gone".  He can prove to the seller that
he did it by using the Guillou-Quisquater protocol to prove in ZK that
he knows the mint's signature on the value the seller gave him.
The seller thereby knows that the buyer's costs are sunk, and so the
seller is motivated to complete the transaction.  The buyer has nothing
to lose and might as well pay the seller by giving him the signed value
from the mint, which the seller can unblind and (provably, verifiably)
be able to deposit.
Hal
_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: Your source code, for sale

["Hal Finney"]

Ben Laurie writes:
> How do you make the payment already "gone" without using a third party?

Of course there has to be a third party in the form of the currency
issuer.  If it is someone like e-gold, they could do as I suggested and
add a feature where the buyer could transfer funds irrevocably into
an escrow account which would be jointly controlled by the buyer and
the seller.  This way the payment is already "gone" from the POV of the
buyer and if the seller completes the transaction, the buyer has less
incentive to cheat him.

In the case of an ecash mint, a simple method would be for the seller to
give the buyer a proto-coin, that is, the value to be signed at the mint,
but in blinded form.  The buyer could take this to the mint and pay to
get it signed.  The resulting value is no good to the buyer because he
doesn't know the blinding factors, so from his POV the money (he paid
to get it signed) is already "gone".  He can prove to the seller that
he did it by using the Guillou-Quisquater protocol to prove in ZK that
he knows the mint's signature on the value the seller gave him.

The seller thereby knows that the buyer's costs are sunk, and so the
seller is motivated to complete the transaction.  The buyer has nothing
to lose and might as well pay the seller by giving him the signed value
from the mint, which the seller can unblind and (provably, verifiably)
be able to deposit.

Hal

Re: Your source code, for sale

[Ben Laurie]

Hal Finney wrote:
Ben Laurie writes:
How do you make the payment already "gone" without using a third party?

Of course there has to be a third party in the form of the currency
issuer.  If it is someone like e-gold, they could do as I suggested and
add a feature where the buyer could transfer funds irrevocably into
an escrow account which would be jointly controlled by the buyer and
the seller.  This way the payment is already "gone" from the POV of the
buyer and if the seller completes the transaction, the buyer has less
incentive to cheat him.
In the case of an ecash mint, a simple method would be for the seller to
give the buyer a proto-coin, that is, the value to be signed at the mint,
but in blinded form.  The buyer could take this to the mint and pay to
get it signed.  The resulting value is no good to the buyer because he
doesn't know the blinding factors, so from his POV the money (he paid
to get it signed) is already "gone".  He can prove to the seller that
he did it by using the Guillou-Quisquater protocol to prove in ZK that
he knows the mint's signature on the value the seller gave him.
The seller thereby knows that the buyer's costs are sunk, and so the
seller is motivated to complete the transaction.  The buyer has nothing
to lose and might as well pay the seller by giving him the signed value
from the mint, which the seller can unblind and (provably, verifiably)
be able to deposit.
Cute. You could adapt Lucre to do this.
Cheers,
Ben.
--
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