[jsprogrammer]

Why not just build an automated post pay system instead of relying on the other person to remember?

At that point, why not setup escrow processes where the sender has to provide proof to release the payment?

This could probably go on and on, as I'm not sure there is a complete answer to centralized vs. decentralized. You likely just have to pick based on what attributes are most important at the time.

[chuckup]

I could imagine the payment protocol being very flexible. Some servers may want their money up front, some may be willing to trust you to pay afterwards, etc.

> At that point, why not setup escrow processes where the sender has to provide proof to release the payment?

There is no way to prove you've sent a file to someone. In the BBS days, there was a program called Leech Zmodem that lied about getting the last chunk of data, so that you didn't have to pay file points for your download.

I can think of a way around this, sort of: you could break the transfer up and require the receiver to sign a message for each piece they've received, before you send the next piece. But, they can lie and say they never got the last piece, and that's tricky because some data is worthless without the entire thing. Maybe they're not lying, and you've disconnected - should they have to pay for 90% of a file? There's lots of little edge cases I can think of.

If this whole idea ever happened, I think large data warehouses would form (using cheap amazon/google storage) and the whole thing might become centralized anyway.

[moe]

they can lie and say they never got the last piece

This can be solved with encryption. Just send them an encrypted version of the file. By requesting the key the receiver confirms possession of all chunks.

[chuckup]

And what if the sender does not send the key? Or, when you use the key, you find out it is just a blob of zeros? (Or, the other way around: receiver lies and says that the sender did not send the key, or that the decrypted data did not match the hash)

[moe]

All your concerns are valid but addressable via "reputation".

Consider this: Each completed transaction is rated by each participating party.

How much your rating affects your opponents reputation in determined by your own reputation. A higher reputation enables privileges such as more peers willing to trade with you, faster downloads, etc.

These reputation systems don't work in common P2P networks because everyone can just generate fake identities and boost their own reputation at will.

However, if you tie the reputation system to bitcoin so that the creation of an identity puts actual money on the line then this kind of cheating doesn't work anymore.

[jerguismi]

Well, I would opt in for something simple/more centralized that works today, instead of having something that works perfectly in thoery after 5 years... All the current projects seem to be the latter type.