Quote from: TierNolan on February 20, 2016, 01:58:35 PM

Quote from: jl777 on February 20, 2016, 12:59:02 PM

Separately, for all failed trades, the keypairs commitments are verified and any violations detected are broadcast to the network. (Or all the peers can monitor all the other trades)

Violations of cut and choose mean that the party doesn't publish the keys. That means you can't prove it.

I am of the position that if you dont publish the keys you forfeit the fee. It seems if one side just stops for whatever reason, they cant prove they didnt cheat. So it is a reverse logic of guilty until proven innocent. It is all automated so as long as they run unmodified software, the only time it would happen is if they get disconnected for the entire 2hour period. If the trade is big enough, there is hopefully enough time to get to a local wifi hotspot to complete the trade.

Why wouldnt this approach work?

Quote

What you need to do is show that the person agreed to pay the fee and then refused to build the transaction.

The proof would be the signed fee transaction but missing the other party's signature. The accused party could then respond by publishing the full transaction and "clear their name".

By providing the final privkey during the protocol, it is proven that that person didnt cheat. We probably need a few cases to deal with Bob bailing out before Alice had to disclose her privkey, probably via some blame states.

Quote

If fraud was successful, then you could publish the locked output and show that the published private key didn't match the committed public key.

Certainly if a fraud is a success, then this is broadcast to all the nodes. I think even any delay from the earliest time a privkey could have been disclosed should send out warnings. That way within a few blocks any funny business is detected and everyone warned.

By using the sum of all fees paid by an account as insurance, then in the event that account steals from another, we could support an insurance claim (up to the limit of the fees paid by the attacker). This way as long as users can see the total fees paid by the other party, they will know how much coverage there is. Granted there are issues about an account building up large amounts of fees and then doing a large number in parallel, but that assumes there are that many that will match up at the same time. I guess this could be fixed by broadcasting all pending trades and adjusting the available insurance. Now we end up with just some propagation based edge cases where not all the pending amounts have been propagated before a trade is agreed to, right at the critical moment.

It feels like it is getting to edge cases that can be handled

James