Topic: Towards cryptographic proof of service delivery through deterministic keys. (Read 561 times)

Hey. Here's an idea. I don't know if it has been proposed yet. Perhaps there's been an alternative.

I was trying to think of a way to combine a low-trust protocol with traditional verification of trust. For example, let's say there are 2 identical restaurants in town. You will go to the one that you can verify if they are good (been around a while, and fulfilled services). You use services like Foursquare, Yelp or you ask your friends.

Let's say there are 2 services that provide services to autonomous agents. Although it is low-trust, and does not have to worry too much about losing money, the only thing they can lose is time and resources spent engaging with a crap or malicious server/service. So if it is faced with 2 equal services, equal prices, it will want to choose one with a history of providing great service, so it doesn't spend time engaging with the worse service.

Looking at the blockchain, you can specifically look at micropayment transactions (with the micropayment API: https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments), to determine if the server complied. If there is a full-refund transaction back to the client then the server did not comply with anything (or the client chose not start any incrementation process, but that is more unlikely).

If a server has one semi-exhausted (or fully exhausted) transaction on the blockchain, it might mean 2 things: It was a successful tx by both client and server, or that somewhere along the line client or server did not comply and it was broadcast. If the server did not comply, then the client will move on to another service (if there is competition).

But generally, having more of these semi (or fully) exhausted transactions on the blockchain indicate in some manner that it is more trustworthy. Because the other alternative is of course, is that if they were a bad service, they won't have a lot of transactions.

If a server uses deterministic address generation for its micropayment channels, it can publish its master public key, and a service can crawl the blockchain looking for addresses belonging to the server. If it finds semi (or fully) exhausted channels, it is an indicator (not a definitive one) of successful service delivery. You can perhaps even build a service that does this monitoring on its own.

So, in short. By checking what happened to micropayment channels (through deterministic key generation), and using volume as an indicator an agent can infer trust about a service.

There are still problems however:

1) There's an easy attack. A new site can simply generate micropayments to themselves to show that there is 'volume'. Potential mitigation around this is using time as an indicator as well. ie, you can't spam yourself to trustworthyness. If you've been providing a service for a few months, with decent regularity, it looks more trustworthy.

2) I haven't looked at deterministic address generation for some time, but is it possible by just having the master public key to determine if an address belongs to it (I remember it being vaguely possible with HD wallets)? ie, you don't need to generate millions of addresses ahead that you have to check.

3) The protocol can be improved by showing who closed and submitted the refund tx? In an ideal transaction, the client asks the server to close, and in the blockchain it could show that is what happened (possibly in OP_RETURN?).

Thoughts? Anyone care to poke some more holes in this? Has anyone else thought of this?