Quote from: Mashuri on May 01, 2015, 11:58:56 PM

OP_CHECKSIGDATAVERIFY seems like a useful op-code for bitcoin. Has this, or something similar, been brought to the attention of the developers before?

Not that I am aware of.

Quote from: Mashuri on May 01, 2015, 11:58:56 PM

As you pointed out, this system can work with E being the only link between parties (a main hub) and escrowing HTLC-style contracts between them.

E (the escrow service) is not really a hub: as long as parties can settle their conflicts without involvement of E, E is not involved in any of the transactions (this is a major advantage in terms of privacy and liberty). Also, there is no inherent, architectural reason why escrow servicing should be centralized to a single entity: in theory, every channel in the network can use a different escrow service. However, in practice, due to the difficulty of reputation building, I'd expect some kind of centralization to occur here, just like Bitcoin exchanges today are, to some degree, centralized entities.

Quote from: Mashuri on May 01, 2015, 11:58:56 PM

What I'm specifically interested in seeing illustrated, is a hypothetical scenario where E is a BTC-denominated derivatives exchange escrowing contracts between users with payment channels only directly connected to E.

If you have a direct payment channel to E and E is also the escrow service of that payment channel, then E has two out of three private keys, which is sufficient to unlock any locked micro-transaction funds, so this situation is really sensitive to abuse by E. Note that this situation can also occur by a sybil attack, or by conspiracy between E and either A or B.

In the event that E abuses such a situation, though, it is still possible for the victim to publish cryptographic proof of the abuse. This would destroy E's reputation, so hopefully that will deter E from performing the abuse in the first place. This would only work though, if E's reputation is really worth anything, e.g. if E is a large business that profits from having lots of other customers.

Quote from: Mashuri on May 01, 2015, 11:58:56 PM

Furthermore, W's distribution would need to be determined by a live data feed. Do you think something like that is workable?

Why would W's distribution need to be determined by a live data feed? Maybe you need to clarify your concept. In my concept, the non-final versions of W are only exchanged between neighbors, and in case of a conflict, to the escrow service, and in case of escrow service misbehavior, to the public. The final version of W is sent to the public (on the block chain). Publishing to other parties wouldn't hurt the integrity of the system, but it would be a loss of privacy.

I do think though that, for the report of proof-of-(abuse by an escrow service), there should be a P2P exchange between users of that escrow service. It is essential, of course, that there should be no way for the escrow service itself to control this P2P network: it has a large interest in censoring such a network.