Quote from: TierNolan on February 24, 2016, 09:31:33 AM

Quote from: jl777 on February 24, 2016, 04:00:57 AM

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 may have got it wrong, need to check.

Quote

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.

I probably need to do a definitive version somewhere.

Quote

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 purpose of the fee is to protect the cut-and-choose step. As long as the 1000 key pairs are valid, the TTP will refund, even if the entire protocol is not completed.

The TTP could publish the keys at that stage.

Quote

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

The attacker could submit their 1000 key pairs to prove that they didn't cheat at cut-and-choose. The TTP would refund (most of) their fee.

Quote

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

You could do a block height + timestamp check?

Code:

CLTV CLTV ....

Care needs to be take, as that could push the early person past the long time person. I wonder if using Bitcoin as the time-server is possible.

instead of timestamp CLTV and relative block CLTV in series, maybe in parallel?

so either 15 blocks or 2 + 2 hours, 15 BTC blocks seems pretty secure and should be at least one hour. But in case it is really slow, then 4 hours side would be ready, allowing for a 2 hour timestamp difference.

I realized both nodes can share their timestamps to make sure they are within a few minutes so no need to deal with -2 hours vs +2 hours for Alice and Bob, they will both be assumed to be relatively in sync, so I think just 2 + 2 hours is needed for the CLTV time based expiration to give at least a 2 hour time window.

The altcoin side would then have plenty of time before the 4 hours or 15 blocks

Did I get that right?

James