Quote from: bitappend on February 13, 2014, 01:43:11 PM

What happens to the flow of money under the following scenarios?
Bob claims he never received fiat funds?

That is the situation what is described under Attack scenarios step 4:
He has already received the Fiat, so the only missing for him is the BTC collateral he payed in and which he only gets returned if both sign the last tx. If he tries to cheat he will loose his collateral (Alice know she had payed, so she has no reason to believe him).
Alice would loose also the payment in that case. But why should Bob risk to loose the collateral?

Opionally there could be used an escrow, either included in all the process (I did not described that, but all 2 of 2 multiSig txs would be then 2 of 3 MS) or optionally afterwards (described under the point Extensions). If there is something to mediate, both can agree to create a new tx to a 2 of 3 multiSig with the escrow. Then move the money from the deposit tx over there, and then consult the escrow for arbitration. That could be treated outside the system, just use any available Escrow service.

The SLL dump mentioned in a post above (and in the paper) could be used for the escrow as proof of the bank transfer. Without that proof it will be easy to cheat an escrow with some photoshoped bank tx screenshots....

Quote from: bitappend on February 13, 2014, 01:43:11 PM

Bob dies in a car crash on way to work before acknowledging receipt?

That is the only real problem. Then if nobody in his family can access the funds or you cannot contact (the bank account details could be used) them, the depost if lost.
As this should be a very rare case (1 in 10 000?) and the system should not be used for high volumes it could be considered as something like an "trading fee". If you trade a lot and loose once the funds, then it may be 0.1% of your overall trading volume. Much less like in most centralized exchanges or the costs for Bank transfers.
Another solution would be an 2 or 3 escrow like above. Maybe a solution based on timelocks could solve the problem as well, I have not found a working solution yet.

An overal design goal is also to keep it as simple as possible.
First because it is more realistic that it gets developed some day.
Second it is easier to understand and use.

Open Transactions or Ripple are very advanced and complex solutions. It is even for tech people like here in the forum difficult to really understand it (and trust it). For non-tech savvy people it would be even more difficult. A simple system would help that people really use it and therefore create market liquidity.

A certain remaining risk is acceptable and in fact accepted by quite a lot of people using shady or badly operating exchanges (MtGox, BTC-e,...). The level of risk is defined by every trade with the trading volume and collateral.