Quote from: TierNolan on February 20, 2016, 01:19:52 PM

Quote from: TPTB_need_war on February 20, 2016, 12:07:38 PM

Remember the party that goes first in your protocol locks up his funds (e.g. UXTO) for the period of the timeout refund

You can have a single transaction that does both fees. That way either neither pays the fee or both do.

The protocol would be

Step 1) Commit to hashes

Alice and Bob create 1000 key pairs.

Alice sends hash(alice_public_key_array) and hash(alice_fee_unlock)
Bob sends hash(bob_public_key_array) and hash(bob_fee_unlock)

TTP is the trusted third party.

The fee transaction has 3 output (plus any change outputs)

A) pays fee to Alice but requires , otherwise it goes to TTP after 7 days
B) pays fee to Bob but requires , otherwise it goes to TTP after 7 days
C) pays to TTP after 7 days

Output C is a 1 of 2 multisig to commit to hash(hash(bob_public_key_array) | hash(alice_public_key_array))

Note: Both parties could exchange a list of TTPs and then pick one of the intersection. The default software could assign the author as one and allow -add_ttp_key as an option (and probably -author_ttp_disable)

Step 2) Choose

Once the fee transaction is broadcast/confirmed, the choose step can happen.

Alice and Bob pick M and N.

Alice sends Bob and the private keys except key N.
Bob sends Alice and the private keys except key M.

Both parties verify the key pairs and then assume the one they didn't pick is probably ok.

As long as the key pairs were valid and the TTP is honest, then an attacker can reclaim his fees (less the TTP's fee).

Step 3) Deposit

Bob pays to an output which gives the money to Alice, unless he releases his private key within 2 days.

He can re-claim his deposit immediately, but that means he ends up bailing out of the protocol.

Step 4) Alice bail in

Alice pays her bail-in to a multisig. If Bob reclaims his deposit, then she can reclaim her bail-in.

Step 5) Bob bails in

Bob pays his output. He can reclaim his output after 1 day. Alice can claim it immediately but then she has to release the fee unlock code and also give Bob her private key, so he can claim his output.

At the end of this step, Bob is stuck. If he reclaims his deposit, then he lets Alice get her bail-in back and she can also claim his bail-in.

Step 6) Alice spends her output (and provides alice_priv_m).

For this step, Alice would also have to provide alice_fee_unlock, and alice_priv_m. Bob can reclaim his fee and also claim his output (and his deposit).

Step 7) Bob can spend the altcoin output

For this step, Bob would also have to provide bob_fee_unlock, so Alice can reclaim his fee.

Step Cool

Bob reclaims his deposit

Bob can reclaim his deposit, since the info released is stale at this point.

So, by the time Bob's deposit is locked, Alice has paid a fee transaction and has also locked her bail-in. I think that is reasonable.

This protocol changes the deposit script so that Bob can reclaim the deposit at anytime. Are you sure there arent any race conditions where Bob can wait to see the unconfirmed tx on the altcoin side and then reclaim his deposit? I think it does, but this definitely requires changing the FSM.

I see a script some posts later that should be Bob's deposit script, but I hope you can enumerate all the required scripts? I want to make sure I am not using scripts from an older iteration. The code now has a matched set of sendtx and verifytx functions, so as long as the proper scripts are used, it can adapt to a large range of protocol changes.

To help with debugging, I am making a manual way to just approve a tx in the state machine, so by manually kicking it to the next state, we can complete the swaps. Also, I will add ways to go into the reclaim states so we can verify the other side can indeed reclaim.

Thanks!

It does seem the above protocol solves all the practical issues, but I am confused a bit by "As long as the key pairs were valid and the TTP is honest, then an attacker can reclaim his fees (less the TTP's fee)." I think we want to allow the TTP to not allow an attacker (as evidenced by non-submission of privN) to be able to reclaim any fees.

The following are the identified attack vectors:
1. Cut and choose attacker (has largest monetary attack on victim)
2. Papercut attacker (delays or prevents victims from reclaiming fees)
3. Liquidity attacker (locks up funds for long time and makes victim not have access to funds for a while)
4. Slippage attacker (waits to complete protocol based on market movements)

To combat these attacks:
1. cumulative fees paid must be significantly more than expected gains and any identified attacker punished with forfeiture of any credits.
2. victims should be able to reclaim/reuse any fees paid for trades that dont complete, or instead of reclaiming, the fees can build credits
3. This seems difficult to punish as the protocol can be followed but with maximum delay allowed, so by reducing the reference time to 1hr/2hrs, it minimized the negative effect
4. With shorter maxtime for the protocol, this effect is minimized, plus users will need to adjust their bid/asks to compensate

Isnt there a way to prevent attacker from recouping any fees via TTP

What is the recommedation for a timestamp padding for the CLTV due to the +/- 2 hour timestamp tolerance?

James