Pages:
Author

Topic: Atomic swaps using cut and choose - page 3. (Read 12138 times)

sr. member
Activity: 420
Merit: 262
February 24, 2016, 10:22:45 PM
#90
I would be grateful if you or TierNolan could actually answer my question?

Stated in another way, what prevents Bob from finalizing the transaction on the block chain with Bitcoin CLTV op code, taking the funds from Alice, while also not issuing the reciprocal transaction paying to Alice on the other block chain?

I seem to never get a straight answer.

In order to spend the funds from Alice, bob has to disclose the random number Alice can use to spend the bitcoins

Afaics, you have not answered my question. Please read my question again. I didn't ask how Bob finalizes the payment from Alice to Bob. I asked, "while also not issuing the reciprocal transaction paying to Alice on the other block chain?". Alice can't spend Bitcoins, because Bob is issuing a transaction on a block chain that is not Bitcoin (and doesn't support CLVT).

Are you implying that Bob will issue his transaction first (paying to Alice) on the block chain without a CLVT op code? Then how does Bob get a refund if Alice doesn't complete her side of the transaction and how can Bob's transaction be verified against a hash of a random number when the CLVT op code isn't supported.
The simple act of spending the payment requires to disclose the information the other party needs to do their spend.

Ignoring fees, at the high level:
1. bob sends in a deposit that alice verifies she can spend after a certain amount of time. However if bob follows the protocol, he can reclaim this refund before alice is eligible to.

You've apparently swapped the block chains of Alice and Bob relative to scenario I described. But that is okay, I will follow your choice, where Bob is transacting on the block chain with CLTV and Alice is not.

The transaction above signed by Bob I assume requires CLTV (Check-Lock-Time-Verify) since it must be refunded if it is not verified before the timeout of the lock.

2. alice verifies the above is in the blockchain so is assured that worst case she can get the deposit, which is 113% of the transaction amount, so she might actually prefer that. when assured she sends bob a payment that requires both secrets to be spent.

I don't understand how Alice can receive the CLTV output unless she already knows how to verify it. But if she knows how to verify it, then she can steal it at any time.

How can Alice send a payment that requires verification of two secrets if the other block chain doesn't support pay contingent on verification of hash preimage?

3. bob sees this on the altcoin chain and sends in a payment to alice that requires a secret from alice that would allow him to spend the payment from 2.

Bob issued the deposit in #1 and now he also issues another payment to Alice, but which is spendable by Alice contingent on knowing the preimage (secret) of a hash. Only Alice knows this secret preimage at this point until she reveals it. I thus understand this step #3.

4. alice sees this real payment and then cashes in the bitcoins, but in doing so has to divulge the secret bob needs to spend the altcoins

I am disputing whether Alice can make such a transaction available in step #2 if her altcoin doesn't support pay contingent on verification of hash preimage.

Edit: I understand you want to use a forfeitable deposit to ensure that Bob does step #3, since Alice has no way to refund step #2 (because her block chain doesn't support CLTV). I presume you are assuming that the altcoin supports pay contingent on verification of hash preimage. But I still don't see how the mechanics of the forfeitable deposit work? "I don't understand how Alice can receive the CLTV output unless she already knows how to verify it. But if she knows how to verify it, then she can steal it at any time."
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 08:21:08 PM
#89
I would be grateful if you or TierNolan could actually answer my question?

Stated in another way, what prevents Bob from finalizing the transaction on the block chain with Bitcoin CLTV op code, taking the funds from Alice, while also not issuing the reciprocal transaction paying to Alice on the other block chain?

I seem to never get a straight answer.

In order to spend the funds from Alice, bob has to disclose the random number Alice can use to spend the bitcoins

Afaics, you have not answered my question. Please read my question again. I didn't ask how Bob finalizes the payment from Alice to Bob. I asked, "while also not issuing the reciprocal transaction paying to Alice on the other block chain?". Alice can't spend Bitcoins, because Bob is issuing a transaction on a block chain that is not Bitcoin (and doesn't support CLVT).

Are you implying that Bob will issue his transaction first (paying to Alice) on the block chain without a CLVT op code? Then how does Bob get a refund if Alice doesn't complete her side of the transaction and how can Bob's transaction be verified against a hash of a random number when the CLVT op code isn't supported.
The simple act of spending the payment requires to disclose the information the other party needs to do their spend.

Ignoring fees, at the high level:
1. bob sends in a deposit that alice verifies she can spend after a certain amount of time. However if bob follows the protocol, he can reclaim this refund before alice is eligible to.

2. alice verifies the above is in the blockchain so is assured that worst case she can get the deposit, which is 113% of the transaction amount, so she might actually prefer that. when assured she sends bob a payment that requires both secrets to be spent.

3. bob sees this on the altcoin chain and sends in a payment to alice that requires a secret from alice that would allow him to spend the payment from 2.

4. alice sees this real payment and then cashes in the bitcoins, but in doing so has to divulge the secret bob needs to spend the altcoins

5. bob gets the required secret from alice and spends the altcoins

So the high level concepts are to advance to each stage only when you are assured that the other side is following the protocol and the FSM is setup so that if either party bails at any point, the funds in limbo can be reclaimed.

To verify this, the bitcoin scripts must be understood in detail. I see no other way. Conceptually, it is a single pull, double throw switch where a single random number releases two transactions

James
sr. member
Activity: 420
Merit: 262
February 24, 2016, 08:10:14 PM
#88
I would be grateful if you or TierNolan could actually answer my question?

Stated in another way, what prevents Bob from finalizing the transaction on the block chain with Bitcoin CLTV op code, taking the funds from Alice, while also not issuing the reciprocal transaction paying to Alice on the other block chain?

I seem to never get a straight answer.

In order to spend the funds from Alice, bob has to disclose the random number Alice can use to spend the bitcoins

Afaics, you have not answered my question. Please read my question again. I didn't ask how Bob finalizes the payment from Alice to Bob. I asked, "while also not issuing the reciprocal transaction paying to Alice on the other block chain?". Alice can't spend Bitcoins, because Bob is issuing a transaction on a block chain that is not Bitcoin (and doesn't support CLVT).

Are you implying that Bob will issue his transaction first (paying to Alice) on the block chain without a CLVT op code? Then how does Bob get a refund if Alice doesn't complete her side of the transaction and how can Bob's transaction be verified against a hash of a random number when the CLVT op code isn't supported.
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 08:04:32 PM
#87
I would be grateful if you or TierNolan could actually answer my question?

Stated in another way, what prevents Bob from finalizing the transaction on the block chain with Bitcoin CLTV op code, taking the funds from Alice, while also not issuing the reciprocal transaction paying to Alice on the other block chain?

I seem to never get a straight answer.
In order to spend the funds from Alice, bob has to disclose the random number Alice can use to spend the bitcoins
sr. member
Activity: 420
Merit: 262
February 24, 2016, 07:21:40 PM
#86
I would be grateful if you or TierNolan could actually answer my question?

Stated in another way, what prevents Bob from finalizing the transaction on the block chain with Bitcoin CLTV op code, taking the funds from Alice, while also not issuing the reciprocal transaction paying to Alice on the other block chain?

I seem to never get a straight answer.
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 06:45:49 PM
#85
Thus the only way I can see that Bob can be required to issue that said transaction paying to Alice (when employing cut & choose on a block chain without Bitcoin op codes), is if the private key for signing the transaction for Bob paying to Alice (on the block chain without Bitcoin op codes) is revealed in order to finalize the already confirmed transaction for Alice paying to Bob (on the block chain with the CLTV Bitcoin op code).
I believe the red part is what causes the confusion.

What is being revealed is just a random number, NOT the privkey for signing the transaction.
This tx is made so this random number must be revealed for the tx to be valid.

I think this point needs to be understood first. The random number has both algebraic properties itself and it is part of the 1000 cut and choose dataset, but that really has little to do with the point you are complaining about.

James

sr. member
Activity: 420
Merit: 262
February 24, 2016, 05:38:44 PM
#84
Again I don't understand any of that.

I simply asked if Bob is transacting on a block chain without Bitcoin op codes, how can his payment to Alice be required (by the Bitcoin block chain) before he can finalize the transaction on the block chain with Bitcoin CLTV op code. It should be possible to explain this in English.

Stated in another way, what prevents Bob from finalizing the transaction on the block chain with Bitcoin CLTV op code, taking the funds from Alice, while also not issuing the reciprocal transaction paying to Alice on the other block chain?

What I am getting at is that is seems to me (my understanding of the cut & choose as underspecified in English) that Bob has not issued any transaction before Alice's transaction paying to Bob is confirmed on the block chain with Bitcoin CLTV op code. Thus the only way I can see that Bob can be required to issue that said transaction paying to Alice (when employing cut & choose on a block chain without Bitcoin op codes), is if the private key for signing the transaction for Bob paying to Alice (on the block chain without Bitcoin op codes) is revealed in order to finalize the already confirmed transaction for Alice paying to Bob (on the block chain with the CLTV Bitcoin op code). And I have already explained that would not be technically sound because anyone could spend Bob's UXTO (instead of it paying to Alice, and afaics Bob could pay himself). So obviously I must be unaware of some aspect of the protocol, because obviously you two would have realized that the above assumption would not be technically sound.

You can verify the high level design and trust that the scripts implement the AND requirement of the temporary privkey and Bob's signature using the real privkey that generated the pubkey that is part of the utxo.

That sentence is underspecified. What is a 'real privkey'? Aren't all private keys real. Could you please state what you really mean and take the time to form a sentence that specifies which block chain you are referring, how it relates the protocol steps, etc..

I can't verify the high level design because the high level algorithm is underspecified per my question above.

We tried to explain in english, but these scripts are indeed quite confusing.

It doesn't need to be confusing. Just takes time to slow down and formulate well thought out English description.

Einstein once said (paraphrasing), that an expert doesn't completely understand his own craft until he can explain it to a layman.
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 09:11:55 AM
#83
Quote
I do not trust anything which I can't verify and understand. But don't worry about me. If you are 100% sure, then no need for peer review. Right?

We are trying to explain, but the solution requires understanding of precisely how bitcoin scripts work generally https://en.bitcoin.it/wiki/Script and most importantly the specific opcodes used. If you say you dont understand them and then say you cant verify, well it seems to lead to an impasse... So you need to trust me and Tier about the details of scripts or bite the bullet and dive into the details of the scripts. Tier is world leading expert at squeezing the most functions from scripts and making them do things even I didnt think were possible to do with them.

You can verify the high level design and trust that the scripts implement the AND requirement of the temporary privkey and Bob's signature using the real privkey that generated the pubkey that is part of the utxo.

We tried to explain in english, but these scripts are indeed quite confusing. I like to get them done once and for all and not deal with them if possible. Regardless of specs, if the scripts are not understood, I dont see how it can be fully verified.

Plz blame TierNolan for the scripts Smiley

IF
    CLTV DROP CHECKSIG
ELSE
    HASH160 EQUALVERIFY CHECKSIG
ENDIF

the above is the script. it is an if/else statement, the one that spends it selects which branch he wants to execute by pushing a 0 or 1 prior to executing the script, the following would be how to redeem the above script for the two cases:

0
or
1

http://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html is a cool script interpreter that allows you to single step through scripts. It doesnt handle all opcodes, but it is still quite useful.

So to spend the second output, Bob has to sign the tx and assuming it is using SIGHASH_ALL what is signed is the tx that has all the other inputs blanked and the output script substituted. https://en.bitcoin.it/wiki/Transaction explains with some details how to properly sign things, but it is quite messy and I was happy when I got it so I can sign arbitarily constructed tx json objects and it dealt with all the craziness required.

Anyway, bob gets the ~70 byte signature of the hash of the modified tx, adds a 0x01 (for SIGHASH_ALL) and pushes that to the stack along the temporary privkey and a 1 to choose the else path.

Now when both halfs are put together:

1  IF CLTV DROP CHECKSIG ELSE  HASH160 EQUALVERIFY CHECKSIG ENDIF

The above is the combined script that needs to evaluate to true.

pretending I am a script interpreter, the first three things go on the stack:

1



Now the IF see the one (and eats it) and goes to the else branch since it is a 1 and not 0

stack is:



remaining script: HASH160 EQUALVERIFY CHECKSIG

The HASH160 does rmd160(sha256()) and replaces the top of stack:

rmd160(sha256())


remaining script: EQUALVERIFY CHECKSIG

the value from the output is pushed and the EQUALVERIFY pops off two and aborts if not equal. since both are the same it passes this test and we are down to the last check.

stack:
script:  CHECKSIG

Now the CHECKSIG makes sure that it was signed by the privkey that generated the real pubkey

Hopefully that is enough detail and background so you can personally verify that even if Bob's temp privkey is broadcast to the world, it wont do anybody any good.

James

sr. member
Activity: 420
Merit: 262
February 24, 2016, 07:51:57 AM
#82
I do not comprehend why you guys are unable to specify the protocol completely in one page or post. I can't analyze piecemeal.

The finite state machine above defines rigorously all states and state transitions.

I do not (readily) comprehend the notation (and nor will I invest effort to learn or decipher the notation). I assume a proper specification would be more comprehensible to more people. However, do not feel obligated to do it for me. I can simply stop posting in the thread, which some parties might prefer any way.

The bitcoin utxo requires both the temporary privkey and a signature from Bob's real privkey for the pubkey that the utxo pays to.

This sentence is ambiguous to me. I would prefer a proper specification of what you are thinking about and attempting to describe.

You could trust me and TierNolan on this point if you dont understand the bitcoin scripts.

I do not trust anything which I can't verify and understand. But don't worry about me. If you are 100% sure, then no need for peer review. Right?

So knowing the temporary privkey is necessary, but insufficient to spent that specific UTXO. Also, it is a onetime use privkey that only the transactions involved in this swap will ever refer to. unless Bob mistakenly funds more utxo using the temporary privkey, there arent any other utxo to worry about. The specific utxo is already paying Bob, plus requires Bob to sign it.

I have no idea what part of the un(der)specified protocol you are referring to above.

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.

I have no idea how you interpret what I wrote as there isnt demand. My point is many coins are being traded on central exchanges that dont even have a dev team, so assuming they will update to latest scripts will be a very long wait.

I understood your point and my point is if there is demand, then the market will fulfill that demand. Coins that are dying, will die. The market is able to route around such failure.

Of course if you can provide backward compatibility, then of course you may want to provide it. But if it can't be technical sound, then obviously it shouldn't be done. Not much to argue about.
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 07:43:56 AM
#81
I do not comprehend why you guys are unable to specify the protocol completely in one page or post. I can't analyze piecemeal.
The finite state machine above defines rigorously all states and state transitions.

The bitcoin utxo requires both the temporary privkey and a signature from Bob's real privkey for the pubkey that the utxo pays to. To my knowledge you cant just use the onetime entropy from this output and use it to spend anything other than the specific transactions that are spent that require that magic number.

You could trust me and TierNolan on this point if you dont understand the bitcoin scripts.
The script at the high level is:

if ( temporary privkey is revealed and Bob has also signed the transaction )
   then you can spend this output

So knowing the temporary privkey is necessary, but insufficient to spent that specific UTXO. Also, it is a onetime use privkey that only the transactions involved in this swap will ever refer to. unless Bob mistakenly funds more utxo using the temporary privkey, there arent any other utxo to worry about. The specific utxo is already paying Bob, plus requires Bob to sign it.

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.
I have no idea how you interpret what I wrote as there isnt demand. My point is many coins are being traded on central exchanges that dont even have a dev team, so assuming they will update to latest scripts will be a very long wait.

Meaning that it is necessary, but not necessarily sufficient to support altcoins without support for CLTV. And the only way to find out if there will be demand for DE is to get it to work with more than a few coins

James
sr. member
Activity: 420
Merit: 262
February 24, 2016, 07:22:26 AM
#80
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.
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 05:43:44 AM
#79
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 are message events from other party (message events capped at length 8)
    // "" are special events
    // types: , osit, payment, is altcoin claim, claim and claim are bob's and alice's reclaiming of their payments, and claim are bob's and alice's reclaim of fee for failed trade, is alice claiming the deposit
    // "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,,handlerfunc,errorhandler,,
    // a given state has a couple of handlers and custom events, with timeouts and errors invoking a bypass
    // events instantdex_addevent(s,*n,,,,)
    *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. Smiley

James
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 05:38:34 AM
#78
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

legendary
Activity: 1232
Merit: 1084
February 24, 2016, 05:31:33 AM
#77
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.
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 12:08:14 AM
#76
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
legendary
Activity: 1176
Merit: 1132
February 24, 2016, 12:00:57 AM
#75
sr. member
Activity: 420
Merit: 262
February 23, 2016, 07:28:15 PM
#74
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.
legendary
Activity: 1176
Merit: 1132
February 23, 2016, 06:07:03 AM
#73
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
legendary
Activity: 1176
Merit: 1132
February 22, 2016, 07:18:48 PM
#72
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
legendary
Activity: 1176
Merit: 1132
February 22, 2016, 07:14:37 PM
#71
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
Pages:
Jump to: