Atomic swaps using cut and choose

[TierNolan]

Just because the counter party proves he knows the hash of his private key doesn't prove he will reveal it. I am totally dumbfounded as to how this solves anything.  

Once you have proven that the digest is hash(private_key).  You can then commit to releasing x should have hash(x) = h.

For example, Bob pays a large deposit to this output

Code:

IF
    <now + 2 days> CLTV DROP <Alice's public key> CHECKSIG
ELSE
    HASH160 <hash(Bob's private key)> EQUALVERIFY <Bob's public key 2> CHECKSIG
ENDIF

With cut and choose, Alice is sure that hash(Bob's private key) actually is for his private key.

If Bob doesn't spend that output within 2 days, then Alice can take his deposit (since the CLTV in the top line will have expired).  

However, the only way to spend that output is to provide the private key.

To spend the output he signs it using

Code:

<Bob's signature using private key 2> <Bob's private Key>

HASH160 hashes his private key and then EQUALVERIFY verifies that it matches <hash(Bob's private key)>.

If Alice watches the network, then she will be able to obtain this information and so will get Bob's private key, as promised.

[TPTB_need_war]

I told you I don't understand Bitcoin op codes, therefor I don't understand your post.

Also you said the point of cut and choose is when CLTV is not available. But then you using CLTV in your example above 

[jl777]

I told you I don't understand Bitcoin op codes, therefor I don't understand your post.

Also you said the point of cut and choose is when CLTV is not available. But then you using CLTV in your example above 

The protocol puts all the fancy opcodes in the bitcoin side, only the basic scripts are assumed to work on the altcoin side

[jl777]

@TierNolan

As the implementation is filling out, I found another minor attack vector, the slippage attack.

Assuming all other parts of the protocol is followed, there is just one place where one side is granting the other an at the money put option without paying anything for this. Some sort of black-scholes option premium is needed.

Scenario:

Alice and Bob agree to trade ALT at 0.02 BTC
We get to where Bob's payment has confirmed and he is waiting for Alice to send payment.
Now Alice runs a modified client that is checking poloniex to wait until the price goes below 0.02 until sending the response. In half the cases the timeout is reached, but as long as the slippage is more than the fee, Alice has gained.

This is why the shorter the time window to complete the better, but since BTC blocktimes are unpredictable, I think 1 hour is the shortest time we can set the altcoin sides timeout and I am still not sure what to do about the +/-2 hours leeway on bitcoin timestamps and how that affects CLTV

http://www.fintools.com/resources/online-calculators/options-calcs/options-calculator/
using volatility of 25% and 5% riskless interest rate, a one day at the money put option's value us about 0.5%, which is more than 3 times the fee. So actually at the one hour timeframes the 0.13% fee is actually right around the put option value!

So maybe this isnt a problem after all. Maybe Alice needs to pay a bit higher fee for the option premium in addition to the insurance fee for the cut and choose. I think if Alice paid the same value fee for BTC and altcoin, that takes care of this asymmetry.

Bob has a much weaker slippage attack surface. He is not getting a call option, but some sort of hybrid (not sure of name, maybe a half straddle butterfly)

If price goes against him, he delays sending, but then Alice wont complete so he wont gain, but now Alice paid for the put option and not benefiting from it...

OK, so this needs some tweaking of fees, maybe an extra one inserted into the protocol, but the shorter the timeframe the smaller this problem is, so I want to get as streamlined of an ordermatch working first

James

[TierNolan]

I told you I don't understand Bitcoin op codes, therefor I don't understand your post.

Ok the code means that the output can be claimed under two conditions:

- Alice can claim the output, but she must wait 2 days
- Bob can claim the output, but to do so he must also provide x such that hash(x) = <hash(bob's private key)>

Bob is the one that funds that output.  It is his deposit.

If we waits more than 2 days, Alice will claim the output using option 1.  This means that he must claim the output before then.  However, to do that, he has to provide x.

Assuming that the cut and choose worked, then x is guaranteed to be the private key.

Also you said the point of cut and choose is when CLTV is not available. But then you using CLTV in your example above 

The trade is from Bitcoin to an altcoin.  All the complexity is to leverage Bitcoin's script to allow trading with an obsolete altcoin.

[TierNolan]

As the implementation is filling out, I found another minor attack vector, the slippage attack.

Yeah, this is a known problem.  The price of the trade would have to take it into account.  There could be 2 prices.

Buy Bitcoin as Bob
Sell Bitcoin as Bob

(or even 4, since there would be a spread)

[TPTB_need_war]

From PM, because this is an important point that others might not realize:

Well if an attacker runs a DE and I dont attack back, then that DE works, so at least there will be one DE that works

The attacker can set the effective minimum fee (even it is multiples higher than the advertized fee due to jammed trades), by ratio of how much they attack their own (or another's) DE.

So in essence the attacker can shut down all DE, by making sure he earns just enough on his DE to offset his attack costs on other DE, but this is a moving target that eventually ends up in all users giving up and abandoning DEs. There only needs to be one attacker.

Edit: I think I offered a solution upthread.

[jl777]

From PM, because this is an important point that others might not realize:

Well if an attacker runs a DE and I dont attack back, then that DE works, so at least there will be one DE that works

The attacker can set the effective minimum fee (even it is multiples higher than the advertized fee due to jammed trades), by ratio of how much they attack their own (or another's) DE.

So in essence the attacker can shut down all DE, by making sure he earns just enough on his DE to offset his attack costs on other DE, but this is a moving target that eventually ends up in all users giving up and abandoning DEs. There only needs to be one attacker.

Edit: I think I offered a solution upthread.

I didnt fully understand you solution. can you describe it in more detail?

James

[TPTB_need_war]

With cut and choose, Alice is sure that hash(Bob's private key) actually is for his private key.

How does the cut & choose exchange prove that Bob's has provided a hash of a private key and not a hash of something else 

If Bob doesn't spend that output within 2 days, then Alice can take his deposit (since the CLTV in the top line will have expired).  

However, the only way to spend that output is to provide the private key.

To spend the output he signs it using

Code:

<Bob's signature using private key 2> <Bob's private Key>

HASH160 hashes his private key and then EQUALVERIFY verifies that it matches <hash(Bob's private key)>.

If Alice watches the network, then she will be able to obtain this information and so will get Bob's private key, as promised.

And so will everyone else get Bob's private key and a miner who wins the block can spend his output before his transaction is confirmed on the block chain.

[jl777]

With cut and choose, Alice is sure that hash(Bob's private key) actually is for his private key.

How does the cut & choose exchange prove that Bob's has provided a hash of a private key and not a hash of something else 

If Bob doesn't spend that output within 2 days, then Alice can take his deposit (since the CLTV in the top line will have expired).  

However, the only way to spend that output is to provide the private key.

To spend the output he signs it using

Code:

<Bob's signature using private key 2> <Bob's private Key>

HASH160 hashes his private key and then EQUALVERIFY verifies that it matches <hash(Bob's private key)>.

If Alice watches the network, then she will be able to obtain this information and so will get Bob's private key, as promised.

And so will everyone else get Bob's private key and a miner who wins the block can spend his output before his transaction is confirmed on the block chain.

These are onetime throwaway private keys and the output is hardwired to Bob's address, so if anybody else does the spend it pays to Bob anyway.

There is no way to know for sure that the hash of the privkey was provided until it works when it is revealed. That is why the fee is required, so that any attack by cheating has a negative expected return.

I changed to 2000 keypairs, so with a 1/777 fee, the expected return is a loss of about 20%. This presupposes there are anywhere near 2000 trades that can be done. Since newbie accounts will only be traded with reluctantly, it will take time to build up an account with 1000+ trades.

And what is achieved? You have lost 1000+ fees, you steal from who you traded with (worth 777 fees), still you lost 200+ fees. The account you built up is blacklisted and the victim is compensated from the fees that have been paid by the attacker. Any balance is forfeited. So any cut and choose attacker will be helping the InstantDEX bank account and the victim would just need to wait a bit extra before being reimbursed. No financial harm to the victim, financial gain to InstantDEX, financial loss to the attacker.

Another point. The 2000 keypairs acts as PoW. It takes several seconds to calculate them all, so you would need one CPU core per attack. Its not like you can simply notify 2000 other peers that you want to start a trade. The initiator has to calculate all the keypairs upfront.

Only if a node decides to accept this incoming offer, will the similar calcs need to be done on the receiving side. Due to the time it takes, probably need to put in some checks for the desirability of the initiating side, but that is for later.

I have a strong feeling that losing 20% will be a pretty strong deterrent, in fact I am hoping we will get a bunch of idealogical cut and choose attackers who want to disrupt the DE without regard to losing money. I can then use those funds to pay for bots that will be making bids, just waiting to be cheated on. In fact, this could create a massive positive feedback loop and the net result is that the DE is unusable by people, but the bots make the attacker pay thousands of BTC in fees, forever.

Not a great result, but I think I can live with that.

James

[jl777]

From PM, because this is an important point that others might not realize:

Well if an attacker runs a DE and I dont attack back, then that DE works, so at least there will be one DE that works

The attacker can set the effective minimum fee (even it is multiples higher than the advertized fee due to jammed trades), by ratio of how much they attack their own (or another's) DE.

So in essence the attacker can shut down all DE, by making sure he earns just enough on his DE to offset his attack costs on other DE, but this is a moving target that eventually ends up in all users giving up and abandoning DEs. There only needs to be one attacker.

Edit: I think I offered a solution upthread.

The cut and choose attack is very cash negative. The papercut attack appears to be the biggest attack vector now.

I think just making InstantDEX a TTP (trusted third party) with full discretion as to the disposition of fees will solve this. Granted it requires trusting that I wont abuse the DE users, myself, but we are talking about the fee here not the trading capital. If this really is an issue that people wont trust that I wont papercut attack the DE users, then we would need some other method.

Since you already have a solution, I could just use that too.

Does this mean there are no attacks left?

James

[jl777]

As the implementation is filling out, I found another minor attack vector, the slippage attack.

Yeah, this is a known problem.  The price of the trade would have to take it into account.  There could be 2 prices.

Buy Bitcoin as Bob
Sell Bitcoin as Bob

(or even 4, since there would be a spread)

Of course, things have always been setup with bid/ask spreads, but I was thinking of some sort of automated compensator for the slippage attack.

Otherwise, the burden of estimating the black-scholes value being granted falls on the user. I guess I could just have a standard spread factor that is added, but it is variable depending primarily on the other party to the trade.

It seems that the fully precise system will need realtime monitoring of past behavior, tracked by fees paid, number of transactions, volumes of transactions, number of "disconnects", etc.

But all this would be a layer on top of the atomic swap, so I dont think I need to worry about it for now. Maybe someone will want to help coding the insurance tracking aspect of this.

James

[jl777]

debugging is progressing slower than normal. just takes too long per iteration, I have time to respond to messages... then time passes and with all the printouts a bit hard to know how the test did.

anyway, have it going back and forth in the state machine until it is waiting for the feetx to confirm. [note to FSM debuggers: it REALLY helps to spell the name of the state it is in correctly!]

Due to the variety of ways the feetx can go,  I made things so it can be put in a variety of places without too much work. For now, I just want to see an automated swap complete.

James

[TPTB_need_war]

And so will everyone else get Bob's private key and a miner who wins the block can spend his output before his transaction is confirmed on the block chain.

These are onetime throwaway private keys and the output is hardwired to Bob's address, so if anybody else does the spend it pays to Bob anyway.

I think I am having difficulty analyzing due to not having one complete specification of the entire protocol with all justifications in one post or web page, and trying to understand it piecewise instead of holistically. Also I've been running around past 2 days to doctors, testing laboratories, and clinics.

In the original version of TierNolan's protocol, my understand is Bob obviously pays Alice, not himself. Bob and Alice each have some UXTO they want to spend to each other on separate block chains. Alice constructs a CLTV payment to Bob contingent on releasing a hash preimage and waits for Bob to construct an identical transaction which he can do once he sees Alice's transaction is confirmed. Once Alice sees Bob's transaction is confirmed, she releases the hash preimage so both transactions become finalized.

The cut & choose alternative is apparently proposed to handle the case where Bob's block chain doesn't support a CLTV opcode. Apparently the conceptual idea that Alice pays (hardwired to Bob as the payee) with CLTV to a 2 of 2 multi-sig, where the second multi-sig requires Bob's private key. Apparently Bob releases this private key when he spends his UXTO to Alice, thus Alice is sure Bob can be paid unless he pays her. My point is that once Bob releases this private key, anyone can spend his UXTO to any payee else besides Alice. Thus I am asserting the cut & choose doesn't work, unless someone can explain to me my mistake.

My proposed tweak or improvement to the original protocol to eliminate jamming is that Bob signs a message indicating he is starting the protocol with Alice, contingent on Alice submitting her CLTV transaction within the current block number. Alice includes this signature in the meta data of her transaction on the block chain. Thus if Bob doesn't issue his CLTV transaction, then he is jamming and his UXTO can be filtered by using the Coin Days Destroyed setting. Note do not permanently filter Bob, because it is possible he wasn't able to fulfill his obligation due to network outage or for other valid reason.

Edit: I don't see an intractable problem with not supporting altcoins that don't add CLTV support. Altcoins will add it, lest they fall behind what the market wants.

[jl777]

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 <bob_fee_unlock>, otherwise it goes to TTP after 7 days
B) pays fee to Bob but requires <alice_fee_unlock>, 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 <alice_public_key_array> and the private keys except key N.
Bob sends Alice <bob_public_key_array> 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 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

[jl777]

My point is that once Bob releases this private key, anyone can spend his UXTO to any payee else besides Alice. Thus I am asserting the cut & choose doesn't work, unless someone can explain to me my mistake.

The "private key" is just one of 1000 temporary ones, so it only applies to the set of transactions from this atomic swap.

The spend requires to have both the temporary private key and a signature that matches the destination pubkey. Presumably only Bob is able to sign the spend with  the real privkey that matches the pubkey the output pays.

The protocol has evolved to solve the real world issues identified, so while the concepts are still the same, a lot of details have changed. Also, waiting for all the popular coins to update could be a long wait. I am working on a universal solution, at least as universal as possible.

In a market where coins without any working blockchain are trading hundreds of thousands USD per day, it seems a bit unrealistic to wait for sanity and technical updates. Why would they bother if they are already getting massive volumes and decent marketcaps? Especially if they dont have a dev team anymore.

James

[TierNolan]

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.

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.

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.

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.

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:

   <now + 2 hours> CLTV <now + 12 blocks> 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.

[jl777]

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.

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.

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.

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.

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:

   <now + 2 hours> CLTV <now + 12 blocks> 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

[jl777]

The following is the current FSM. I wish there was a way to generate graphics for it, but not familiar with a good way to do that.

With the various tweaks along the way, I fear it has drifted a bit, but at least here is a rigorous definition of the atomic FSM.

It is a bit tricky as some things are implicit (sending of the tx) but the events for a state responsible for that transition is usually a direct map from the protocol description

Code:

    // Two initial states are BOB_idle and ALICE_idle
    // Inconvenient to start statemachines before this as typically after posting something in the orderbook, it is possible for multiple offers to come in. In that case the user or designated tradebot will need to choose among the acceptable offers and also to determine how much longer to wait. Also, an orderbook entry is technically a state, but there is no assurance it will ever proceed beyond the initial state and not just expire. Once an incoming offer is accepted, then the statemachine is created to push the swap toward completion.
    
    // the initiator includes a deck of INSTANTDEX_DECKSIZE keypairs
    //
    // "BTC<msg> are message events from other party (message events capped at length 8)
    // "<lowercase msg>" are special events
    // <TX> types: <fee>, <dep>osit, <alt>payment, <acl> is altcoin claim, <bre>claim and <are>claim are bob's and alice's reclaiming of their payments, <bfr> and <afr>claim are bob's and alice's reclaim of fee for failed trade, <adp> is alice claiming the deposit
    // "<TX>found" means the other party's is confirmed at user specified confidence level
    
    // BTC_cleanup state just unwinds pending swap as nothing has been committed yet
    
    // states instantdex_statecreate(s,n,<Name of State>,handlerfunc,errorhandler,<Timeout State>,<Error State>
    // a given state has a couple of handlers and custom events, with timeouts and errors invoking a bypass
    // events instantdex_addevent(s,*n,<Current State>,<event>,<message to send>,<Next State>)
    *n = 2;
    s = instantdex_statecreate(s,n,"BTC_cleanup",BTC_cleanupfunc,0,0,0,-1); // from states without any commits
    memset(s,0,sizeof(*s) * 2);
    // terminal [BLOCKING] states for the corresponding transaction
    // if all goes well both alice and bob get to claim the other's payments
    s = instantdex_statecreate(s,n,"ALICE_claimedbtc",ALICE_claimbtcfunc,0,0,0,0);
    instantdex_addevent(s,*n,"ALICE_claimedbtc","aclfound","poll","BTC_cleanup");
    instantdex_addevent(s,*n,"ALICE_claimedbtc","poll","poll","ALICE_claimedbtc");
    
    s = instantdex_statecreate(s,n,"BOB_depclaimed",BOB_reclaimfunc,0,0,0,0); // deposit back
    instantdex_addevent(s,*n,"BOB_depclaimed","brefound","poll","BTC_cleanup");
    instantdex_addevent(s,*n,"BOB_depclaimed","poll","poll","BOB_depclaimed");

    s = instantdex_statecreate(s,n,"BOB_claimedalt",BOB_claimaltfunc,0,0,0,0);
    instantdex_addevent(s,*n,"BOB_claimedalt","bclfound","poll","BOB_depclaimed");
    instantdex_addevent(s,*n,"BOB_claimedalt","poll","poll","BOB_claimedalt");
    
    // if things go wrong, bob gets his deposit and fee back
    s = instantdex_statecreate(s,n,"BOB_feereclaimed",BOB_feereclaimfunc,0,0,0,0);
    instantdex_addevent(s,*n,"BOB_feereclaimed","bfrfound","poll","BTC_cleanup");
    instantdex_addevent(s,*n,"BOB_feereclaimed","poll","poll","BOB_feereclaimed");
    
    s = instantdex_statecreate(s,n,"BOB_reclaimed",BOB_reclaimfunc,0,0,0,0); // deposit back
    instantdex_addevent(s,*n,"BOB_reclaimed","brefound","poll","BOB_feereclaimed");
    instantdex_addevent(s,*n,"BOB_reclaimed","poll","poll","BOB_reclaimed");

    // if things go wrong, alice reclaims her altpayment or claims the deposit and then fee
     s = instantdex_statecreate(s,n,"ALICE_feereclaimed",ALICE_feereclaimfunc,0,0,0,0);
    instantdex_addevent(s,*n,"ALICE_feereclaimed","afrfound","poll","BTC_cleanup");
    instantdex_addevent(s,*n,"ALICE_feereclaimed","poll","poll","ALICE_feereclaimed");
  
    s = instantdex_statecreate(s,n,"ALICE_reclaimed",ALICE_reclaimfunc,0,0,0,0); // altpayment
    instantdex_addevent(s,*n,"ALICE_reclaimed","arefound","poll","ALICE_feereclaimed");
    instantdex_addevent(s,*n,"ALICE_reclaimed","poll","poll","ALICE_reclaimed");
    s = instantdex_statecreate(s,n,"ALICE_depositclaimed",ALICE_claimdepositfunc,0,0,0,0); // altpayment
    instantdex_addevent(s,*n,"ALICE_depositclaimed","adpfound","poll","ALICE_feereclaimed");
    instantdex_addevent(s,*n,"ALICE_depositclaimed","poll","poll","ALICE_depositclaimed");
    // end terminal [BLOCKING] states
    
    // need to create states before they can be referred to, that way a one pass FSM compile is possible
    s = instantdex_statecreate(s,n,"BOB_gotoffer",BTC_waitprivCfunc,0,"BTC_cleanup",0,1);
    s = instantdex_statecreate(s,n,"ALICE_gotoffer",BTC_waitprivCfunc,0,"BTC_cleanup",0,1);
    s = instantdex_statecreate(s,n,"BOB_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
    s = instantdex_statecreate(s,n,"BOB_waitfee",BOB_waitfeefunc,0,"BTC_cleanup",0,0);
    s = instantdex_statecreate(s,n,"BOB_sentdeposit",BOB_waitBTCalttxfunc,0,"BOB_reclaimed",0,0);
    s = instantdex_statecreate(s,n,"BOB_altconfirm",BOB_waitaltconfirmfunc,0,"BOB_reclaimed",0,0);
    s = instantdex_statecreate(s,n,"BOB_sentpayment",BOB_waitprivMfunc,0,"BOB_reclaimed",0,0);
    s = instantdex_statecreate(s,n,"ALICE_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
    s = instantdex_statecreate(s,n,"Alice_waitfee",ALICE_waitfeefunc,0,"BTC_cleanup",0,0);
    s = instantdex_statecreate(s,n,"ALICE_waitdeposit",ALICE_waitdepositfunc,0,"BTC_cleanup",0,0);
    s = instantdex_statecreate(s,n,"ALICE_sentalt",ALICE_waitBTCpaytxfunc,0,"ALICE_reclaimed",0,0);
    s = instantdex_statecreate(s,n,"ALICE_waitconfirms",ALICE_waitconfirmsfunc,0,"ALICE_reclaimed",0,0);
    s = instantdex_statecreate(s,n,"ALICE_checkbobreclaim",ALICE_checkbobreclaimfunc,0,"ALICE_reclaimed",0,0);

    if ( 0 ) // following are implicit states and events handled externally to setup datastructures
    {
        instantdex_addevent(s,*n,"BOB_idle","usrorder","BTCoffer","BOB_sentoffer"); // send deck
        instantdex_addevent(s,*n,"ALICE_idle","usrorder","BTCoffer","ALICE_sentoffer");
    }
    s = instantdex_statecreate(s,n,"BOB_idle",BTC_idlerecvfunc,0,"BTC_cleanup",0,1);
    instantdex_addevent(s,*n,"BOB_idle","BTCoffer","BTCdeckC","BOB_gotoffer"); // send deck + Chose
    s = instantdex_statecreate(s,n,"ALICE_idle",BTC_idlerecvfunc,0,"BTC_cleanup",0,1);
    instantdex_addevent(s,*n,"ALICE_idle","BTCoffer","BTCdeckC","ALICE_gotoffer");

    // after offer is sent, wait for other side to choose and sent their deck, then send privs
    s = instantdex_statecreate(s,n,"BOB_sentoffer",BTC_waitdeckCfunc,0,"BTC_cleanup",0,1);
    s = instantdex_statecreate(s,n,"ALICE_sentoffer",BTC_waitdeckCfunc,0,"BTC_cleanup",0,1);
    instantdex_addevent(s,*n,"BOB_sentoffer","BTCdeckC","BTCprivC","BOB_sentprivs"); // send privs + Chose
    instantdex_addevent(s,*n,"ALICE_sentoffer","BTCdeckC","BTCprivC","ALICE_sentprivs");
    
    // gotoffer states have received deck and sent BTCdeckC already (along with deck)
    s = instantdex_statecreate(s,n,"BOB_gotoffer",BTC_waitprivCfunc,0,"BTC_cleanup",0,1);
    s = instantdex_statecreate(s,n,"ALICE_gotoffer",BTC_waitprivCfunc,0,"BTC_cleanup",0,1);
    instantdex_addevent(s,*n,"BOB_gotoffer","BTCprivC","BTCprivs","BOB_sentprivs"); // send privs
    instantdex_addevent(s,*n,"ALICE_gotoffer","BTCprivC","BTCprivs","ALICE_sentprivs");
    
    // to reach sentprivs, all paths must have sent/recv deck and Chose and verified cut and choose
    s = instantdex_statecreate(s,n,"BOB_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
    instantdex_addevent(s,*n,"BOB_sentprivs","BTCprivs","poll","BOB_waitfee");
    instantdex_addevent(s,*n,"BOB_sentprivs","poll","poll","BOB_sentprivs");

    s = instantdex_statecreate(s,n,"ALICE_sentprivs",BTC_waitprivsfunc,0,"BTC_cleanup",0,0);
    instantdex_addevent(s,*n,"ALICE_sentprivs","BTCprivs","poll","Alice_waitfee");
    instantdex_addevent(s,*n,"ALICE_sentprivs","poll","poll","ALICE_sentprivs");

    // [BLOCKING: fee] Bob waits for fee and sends deposit when it appears
    s = instantdex_statecreate(s,n,"BOB_waitfee",BOB_waitfeefunc,0,"BTC_cleanup",0,0);
    instantdex_addevent(s,*n,"BOB_waitfee","feefound","BTCdeptx","BOB_sentdeposit");
    instantdex_addevent(s,*n,"BOB_waitfee","poll","poll","BOB_waitfee");

    // [BLOCKING: fee and deposit] Alice waits for fee and then waits for deposit to confirm and sends altpayment
    s = instantdex_statecreate(s,n,"Alice_waitfee",ALICE_waitfeefunc,0,"BTC_cleanup",0,0);
    instantdex_addevent(s,*n,"Alice_waitfee","feefound","poll","ALICE_waitdeposit");
    instantdex_addevent(s,*n,"Alice_waitfee","poll","poll","Alice_waitfee");
    
    s = instantdex_statecreate(s,n,"ALICE_waitdeposit",ALICE_waitdepositfunc,0,"BTC_cleanup",0,0);
    instantdex_addevent(s,*n,"ALICE_waitdeposit","depfound","BTCalttx","ALICE_sentalt");
    instantdex_addevent(s,*n,"ALICE_waitdeposit","poll","poll","ALICE_waitdeposit");

    // [BLOCKING: BTCalttx and altfound] now Bob's turn to make sure altpayment is confirmed and send real payment
    s = instantdex_statecreate(s,n,"BOB_sentdeposit",BOB_waitBTCalttxfunc,0,"BOB_reclaimed",0,0);
    instantdex_addevent(s,*n,"BOB_sentdeposit","BTCalttx","poll","BOB_altconfirm");
 
    s = instantdex_statecreate(s,n,"BOB_altconfirm",BOB_waitaltconfirmfunc,0,"BOB_reclaimed",0,0);
    instantdex_addevent(s,*n,"BOB_altconfirm","altfound","BTCpaytx","BOB_sentpayment");
    instantdex_addevent(s,*n,"BOB_altconfirm","poll","poll","BOB_altconfirm");
    
    // [BLOCKING: BTCpaytx] now Alice's turn to make sure payment is confrmed and send in claim or see bob's reclaim and reclaim
    s = instantdex_statecreate(s,n,"ALICE_sentalt",ALICE_waitBTCpaytxfunc,0,"ALICE_reclaimed",0,0);
    instantdex_addevent(s,*n,"ALICE_sentalt","BTCpaytx","poll","ALICE_waitconfirms");
    
    s = instantdex_statecreate(s,n,"ALICE_waitconfirms",ALICE_waitconfirmsfunc,0,"ALICE_reclaimed",0,0);
    instantdex_addevent(s,*n,"ALICE_waitconfirms","altfound","BTCprivM","ALICE_claimedbtc");
    instantdex_addevent(s,*n,"ALICE_waitconfirms","poll","poll","ALICE_checkbobreclaim");
    
    s = instantdex_statecreate(s,n,"ALICE_checkbobreclaim",ALICE_checkbobreclaimfunc,0,"ALICE_reclaimed",0,0);
    instantdex_addevent(s,*n,"ALICE_checkbobreclaim","brefound","poll","ALICE_reclaimed");
    instantdex_addevent(s,*n,"ALICE_checkbobreclaim","poll","poll","ALICE_waitconfirms");
    
    // [BLOCKING: privM] Bob waits for privM either from Alice or alt blockchain
    s = instantdex_statecreate(s,n,"BOB_sentpayment",BOB_waitprivMfunc,0,"BOB_reclaimed",0,0);
    instantdex_addevent(s,*n,"BOB_sentpayment","aclfound","BTCdone","BOB_claimedalt");
    instantdex_addevent(s,*n,"BOB_sentpayment","BTCprivM","BTCdone","BOB_claimedalt");
    instantdex_addevent(s,*n,"BOB_sentpayment","poll","poll","BOB_sentpayment");

If you want to specify the protocol using FSM description, that would eliminate any ambiguities and blatant mistakes by silly coders like me.

James

[TPTB_need_war]

My point is that once Bob releases this private key, anyone can spend his UXTO to any payee else besides Alice. Thus I am asserting the cut & choose doesn't work, unless someone can explain to me my mistake.

The "private key" is just one of 1000 temporary ones, so it only applies to the set of transactions from this atomic swap.

The spend requires to have both the temporary private key and a signature that matches the destination pubkey. Presumably only Bob is able to sign the spend with  the real privkey that matches the pubkey the output pays.

I do not comprehend why you guys are unable to specify the protocol completely in one page or post. I can't analyze piecemeal.

My point is that Alice has to be sure that Bob will issue his payment to Alice, and that he can't be capable of spending the payment from Alice to Bob before issuing the counter payment. As understand the cut & choose protocol, Alice signs the CLTV to a 2 of 2 multi-signature where Bob must reveal his private key in order to finalize that payment from Alice to Bob. But I also assume the payment from Bob to Alice (on the other block chain) must use the same private key, else otherwise Alice has no way to be sure that Bob has paid her as well. Thus I assert that once Bob releases his private key, any one could spend his UXTO to another party.

This is getting really tiring go round and round with posts and not having a complete specification of the cut & choose protocol.

The protocol has evolved to solve the real world issues identified, so while the concepts are still the same, a lot of details have changed.

It would help if one of you would provide all the details in proper specification, because it is very difficult for someone to analyze that which is underspecified (and a moving target).

Also, waiting for all the popular coins to update could be a long wait. I am working on a universal solution, at least as universal as possible.

I do not believe a universal solution exists. But I will await clarification.

In a market where coins without any working blockchain are trading hundreds of thousands USD per day, it seems a bit unrealistic to wait for sanity and technical updates. Why would they bother if they are already getting massive volumes and decent marketcaps? Especially if they dont have a dev team anymore.

If you don't think there is a massive demand for decentralized exchange, then why even bother.