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
