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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com