he can use the system like this: choose an escrow and his/her corresponding oracle machine.
I am still confused how you want to make sure that the escrow is not in cahoots with the buyer. If the buyer can arbitrarily choose an escrow, as you said, then he could also just setup his own escrow service and thereby completely scam the seller. Maybe I just don't get your idea, how you want that the buyer can choose the escrow...?
I think this decentralized exchange needs two important things:
1) The escrow has to be chosen pseudo-randomly such that neither the buyer nor the seller have influence on this decision.
2) The p2p-system must prevent sybil attacks, where an attacker could flood the system with his own escrow services and use them to scam other traders.
Thanks for your efforts in understanding and critiquing.
I have always thought that, indeed, it's better if the escrow is chosen at random. I think I proposed something similar among these pages. The alpha test will not include this feature.
But I think maybe you haven't understood fully the power that the oracle brings: if the seller suspects that the escrow is in cahoots with the buyer after a dispute, there is nothing stopping him from asking for independent verification: he requests an access key to the system and the ssl session key so that he can also verify by accessing the oracle, what the html page says (remember: the buyer has provided a key for ONE html page which provides proof of his transfer without exposing his login credentials).
If the escrow refuses to hand over those keys he has proved he is a fraud. If he hands over the wrong session key it will decrypt nothing - again proving fraud.
It works only because you can prove exactly what program is running on the oracle, and it cannot be tampered with, including by the escrow.
It's true though that a given escrow could commit exactly one fraud via this method, since he's in control of a 2 of 3 multisig address. Until we are able to construct an oracle which interprets all html bank statements correctly, this will always be true.
This problem *could* be mitigated by the escrow posting collateral to another multisig, such that his bitcoins are lost if he commits this transparent fraud. Then we have to be careful not to create a centralised system - with one or more "super-escrows" acting as police over other escrows. This might be too much centralisation, although I am not completely against a system like that. And if you try to distribute a LOT you might get another problem - 13 of 13 multisig is all very well, but what if 1 of the 13 dies?
So this comes back to your (and my) point that the system works much better if escrows are chosen randomly - but don't ignore the HUGE step forward that an oracle represents.
Here are my thoughts on this problem (if it is a problem at all?), and how it might be possible to solve both points:
The idea is to use the block hashes of the bitcoin blockchain as a pseudo random stream to select an escrow.
For example:
All exchange users (buyers,sellers,escrows) have an identity=[ public_key, hash(bank-account-number) ]. If buyer and seller agree to a trade (i.e. through a bitmessage order book as you said), then this trade will be broadcasted to all users. Therefore both trading partners and their identities and the amount will be available for the public. Similar to bitcoin transactions you can compute a hash of this trade. Now based on the hash of the trade and the hash of the next bitcoin block, another user is pseudo-randomly selected. The selection might work like this:
each exchange userXY can calculate his individual score to be the escrow in the broadcasted trade:
score_userXY = hash(identity_userXY XOR hash(trade) XOR hash(next_bitcoin_block))
Everyone can claim to be the escrow service, but only the user with the lowest score will win and be the escrow for this particular trade. By this procedure, the p2p-exchange has pseudo randomly selected the escrow...
Hope my explanation somehow makes sense and could be helpful in any way...
Yes, at first glance, this looks like one viable approach for random choice. I guess there would be a few ways to do it.
However I want to ask about identity: earlier in the thread you suggested it was better to make identities stick to bank accounts rather than hash(BTC add, bank account), and I realised that this was a good point, because anyone can create a BTC address any time, and so could create identities too easily.
I think this is an important issue and I'm not sure about it.
The identity has to have two properties: there should be at least some cost to creating one, but also it should be impossible to impersonate. Public bank account details satisfy the first but not the second. So maybe the best is indeed to combine a bitcoin address with a bank account but not in such a simple way as hash(BTC+BA). It could be requiring a signed message with the bitcoin address used at account creation time, as well as provision of hash of bank details. That way an attempt to create a second account with the same bank account but different bitcoin address would not be allowed, because the hash of the bank account would be a collision.