[rixtox]

I'm supprised no one has mentioned the fair exchange problem: if A, B engage in an exchange protocol, say A sends data to B while B paying to A, how to achieve fairness using an asynchornous protocol. Without a third party, either one of the two parties has to be in a position of advantage where it can choose to walk off without fulfilling his part of the contract.

The problem still exists under "micro-transaction" scheme, but in a less exploitable sense: because each transaction only involves a small amount of money or data, it's probably okay if you encountered with a cheater with one or two transactions. You can just block them after catching them cheating.

But the cheaters can still exploit this problem for their own gain: they just repeat this scheme with all other users on the network, until they received the whoe file without spending anything.

I don't see this protocol preventing such exploitable scenario. In fact it's a very difficult problem to solve efficiently and without a traditional trusted third party. It's even been proved [1] that strong fairness is impossible without a trusted third party. However relying on blockchain as a thrid party, it's possible to achieve this, and there are implementations [2] out there, but the challenge is throughput. Most of these solutions can only handle kilobytes/s of throughput. The computational barrier here is the vast amount of modular exponentiations.

[1] https://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/pagni... [2] https://github.com/sec-bit/zkPoD-node

[brugeman]

Great point. Not sure about state channels, but there are proposals for the Lightning Network. You could reveal a packet of data inside the payment confirmation itself, so it becomes atomic [1]. However, there are still issues: throughput, obviously, but then there needs to be a way to check the packet of data for correctness.

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/20...

[rixtox]

Yes, it's the basic idea of all the blockchain based implementations. The challenge here is you have to seal the data packet first, make a layer 2 commitment that has some kind of cryptographic binding to the data. Then you have to have a mechanism to atomically open the data while paying the contract. This can be done with some homomorphic properties of some cryptographic primitives but the computational cost is currently very high.

[colonelcanoe]

You could program the rules of the state channel used to provide payment exactly for the piece of the torrent provided. Like you point out, that would use a trusted third party to implement a fair exchange.

We considered doing that, but like you also point out, if you had to sign each piece of the torrent, it would slow throughput to a crawl.