ACCT using CLTV - More Effective than a sleeping pill!

TierNolan

legendary

Activity: 1232

Merit: 1094

I haven't gone through it step by step but that is a good way to do it.

At any time each party is in a given state right? Why are there 4 start states? Shouldn't it just be that Bob is in one state and Alice is in another?

For example, Bob starts in BOB_start and Alice starts in Alice_waiting_for_trade_request, or something similar.

If a node receives an offer from another party, then it creates a thread to handle it, like a web-server right?

I guess that means that Alice effectively starts at Alice_received_trade_request, or equivalent. Since the waiting_for_trade_request is implicit by listening on the socket.

Bob_start causes Bob to send his offer and then transition to Bob_offer_sent.

Bob_offer_sent could timeout within 30-60 seconds and cause Bob to transition to Bob_cancel_offer. Alternatively, it Alice accepts the offer, they could transition to the fee and 777 pairs exchange. There is no point in wasting processing if the other party isn't accepting the trade.

I guess it depends on how fine grained the state resolution should be.

Also, there could be a step where both sides decide who is Alice and who is Bob, since the person who offers the trade may not necessarily be Bob.

jl777

legendary

Activity: 1176

Merit: 1134

Very nice!

I decided to put these protocols into state machines, as it is very easy to misunderstand a step in the process. The following is an undebugged set of states and transitions of the cut and choose:

Code:

    // Four initial states are BOB_sentoffer, ALICE_gotoffer, ALICE_sentoffer, BOB_gotoffer
    // the initiator includes signed feetx and deck of 777 keypairs
    // the responder chooses one of 777 and returns it with "BTCchose" message
    // 
    // "BTC are message events from other party (message events capped at length 8)
    // "lowercas" are special events,  types: , osit, payment,  is altcoin claim
    // "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
    s = instantdex_statecreate(s,n,"BTC_cleanup",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"BOB_claimdeposit",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"ALICE_reclaim",BOB_processfunc,0,0,0);
 
    s = instantdex_statecreate(s,n,"BOB_sentoffer",BOB_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"BOB_sentprivs",BOB_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"BOB_gotoffer",BOB_processfunc,0,"BTC_cleanup",0);
    
    s = instantdex_statecreate(s,n,"ALICE_sentoffer",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_gotoffer",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_sentprivs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_wait3",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitfee_privs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitdeposit_privs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitfee_deposit",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitprivs",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitfee",ALICE_processfunc,0,"BTC_cleanup",0);
    s = instantdex_statecreate(s,n,"ALICE_waitdeposit",ALICE_processfunc,0,"BTC_cleanup",0);
    
    s = instantdex_statecreate(s,n,"BOB_sentdeposit",BOB_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"BOB_altconfirm",BOB_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"ALICE_sentalt",ALICE_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"ALICE_waitconfirms",ALICE_processfunc,0,"BTC_claimdeposit",0);
    s = instantdex_statecreate(s,n,"BOB_sentpayment",BOB_processfunc,0,"BTC_claimdeposit",0);
  
    s = instantdex_statecreate(s,n,"ALICE_claimedbtc",BOB_processfunc,0,0,0);
    s = instantdex_statecreate(s,n,"BOB_claimedalt",BOB_processfunc,0,0,0);

    // events instantdex_addevent(s,*n,,,,)
    instantdex_addevent(s,*n,"BOB_sentoffer","BTCchose","BTCprivs","BOB_sentprivs");
    instantdex_addevent(s,*n,"BOB_sentprivs","feefound","BTCdeptx","BOB_sentdeposit");
    instantdex_addevent(s,*n,"ALICE_sentoffer","BTCchose","BTCprivs","ALICE_sentprivs");
    
    // gotoffer states have sent BTCchose already
    instantdex_addevent(s,*n,"BOB_gotoffer","BTCchose","BTCprivs","BOB_sentprivs");
    instantdex_addevent(s,*n,"ALICE_gotoffer","BTCchose","BTCprivs","ALICE_sentprivs");
    
    // alice needs to wait for various items
    instantdex_addevent(s,*n,"ALICE_sentprivs","BTCdeptx",0,"ALICE_wait3");

    // following states cover all permutations of the three required events to make altpayment
    instantdex_addevent(s,*n,"ALICE_wait3","feefound",0,"ALICE_waitdeposit_privs");
    instantdex_addevent(s,*n,"ALICE_wait3","depfound",0,"ALICE_waitfee_privs");
    instantdex_addevent(s,*n,"ALICE_wait3","BTCprivs",0,"ALICE_waitfee_deposit");
    
    instantdex_addevent(s,*n,"ALICE_waitfee_privs","feefound",0,"ALICE_waitprivs");
    instantdex_addevent(s,*n,"ALICE_waitfee_privs","BTCprivs",0,"ALICE_waitfee");
    
    instantdex_addevent(s,*n,"ALICE_waitdeposit_privs","depfound",0,"ALICE_waitprivs");
    instantdex_addevent(s,*n,"ALICE_waitdeposit_privs","BTCprivs",0,"ALICE_waitdeposit");
    
    instantdex_addevent(s,*n,"ALICE_waitfee_deposit","depfound",0,"ALICE_waitfee");
    instantdex_addevent(s,*n,"ALICE_waitfee_deposit","feefound",0,"ALICE_waitdeposit");
    
    // wait for last event and send out altpayment
    instantdex_addevent(s,*n,"ALICE_waitprivs","BTCprivs","BTCalttx","ALICE_sentalt");
    instantdex_addevent(s,*n,"ALICE_waitfee","feefound","BTCalttx","ALICE_sentalt");
    instantdex_addevent(s,*n,"ALICE_waitdeposit","depfound","BTCalttx","ALICE_sentalt");

    // now Bob's turn to make sure altpayment is confirmed and send real payment
    instantdex_addevent(s,*n,"BOB_sentdeposit","BTCalttx",0,"BOB_altconfirm");
    instantdex_addevent(s,*n,"BOB_altconfirm","altfound","BTCpaytx","BOB_sentpayment");
    
    instantdex_addevent(s,*n,"ALICE_sentalt","BTCpaytx",0,"ALICE_waitconfirms");
    instantdex_addevent(s,*n,"ALICE_waitconfirms","bobfound",0,"ALICE_reclaim");
    instantdex_addevent(s,*n,"ALICE_waitconfirms","payfound","BTCprivM","ALICE_claimedbtc");
  
    // if BTCprivM doesnt come in, altcoin needs to be monitored for alice's claim
    instantdex_addevent(s,*n,"BOB_sentpayment","aclfound","BTCdone","BOB_claimedalt");
    instantdex_addevent(s,*n,"BOB_sentpayment","BTCprivM","BTCdone","BOB_claimedalt");

A few more states are needed for full recovery in all the different cases, but I think the mainstream cases are very close to correct.

James

TierNolan

legendary

Activity: 1232

Merit: 1094

When using a deposit for channel establishment, it is possible to reclaim the deposit once the root transaction is locked (if both cooperate).

Bob pays D to the following output

Code:

IF
    CLTV EQUALVERIFY  OP_CHECKSIG
ELSE
  OP_IF
    HASH160  EQUALVERIFY 
    HASH160  EQUALVERIFY 
  ELSE
    HASH160  EQUALVERIFY
  ENDIF
   OP_CHECKSIG
ENDIF

Alice pays the same to the equivalent.

Bob can reclaim his deposit by publishing his private key for the multisig. If Alice has given him her deposit lock code, then he can claim it using that and keep his private key secret. In that case, he must inherently release his deposit lock code. The process is symmetric.

Once the multisig output has been properly committed on the altchain, Bob and Alice can sign a stable refund transaction with a locktime in the future (it can be more than 1 day). Once they have completed that step, the deposit is no longer needed. At that point they can swap deposit unlock codes. If one of them withholds their lock code after receiving the other party's code, they can't make use of it without inherently releasing their code.

The effect is that the deposit would only be locked for a short period of time during setup rather than being locked for the entire protocol.

I think the step "Create a multisig output with a locked refund on the altchain" could be made different for the different grades of coin and then the rest of any protocol kept the same.

TierNolan

legendary

Activity: 1232

Merit: 1094

I created a BIP that would remove the need for cut-and-choose.

TierNolan

legendary

Activity: 1232

Merit: 1094

This is a way to simulate a Lightning network on a Rank 2 altcoin. The outputs would have to use P2SH in order to support the non-standard scripts.

Since the timeouts are in the days range, it would be enough to have 1 miner who will accept non-standard scripts. Additionally, if cross chain Lightning was to become popular, the relaxing the IsStandard rules would be an easy change.

This is the basics of a protocol.

Step 1) fund deposits

Bob and Alice commit to hash(bob_priv_0) and hash(alice_priv_0) using the cut and choose.

On Bitcoin, Bob funds a transaction which pays D to 3 outputs.

Code:

OP_IF
   OP_CLTV  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ENDIF

and

Code:

OP_IF
   OP_CLTV  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ENDIF

and

Code:

OP_IF
   OP_CLTV  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ENDIF

Alice also pays 3*D to the equivalent.

This means that they both promise to publish the private keys within 40 days and their timelocks within 20 and 30 days. The timelocks are the key to simulating CLTV on legacy altcoins.

The two timelocks are needed due to the hash locking. All hash locks time out after 20 days. The revokes timeout after 30 days and the channel/bail-in times out after 40 days.

Step 2) Both bail-in

Alice and Bob fund a transaction with 2 outputs

Pays b

Code:

OP_2   OP_2 OP_CHECKMULTISIG

Pays a

Code:

OP_2   OP_2 OP_CHECKMULTISIG

After 40 days, Bob will be able to spend the first output and Alice will be able to spend the 2nd.

Step 3) Create balance transaction

Alice picks a value alice_n and Bob picks a value bob_n. They compute the hashes and send the digests to the other party.

Create two transactions that spend both outputs of the bail-in transaction.

Bob.penalty.n has these outputs

a = Alice's balance
b = Bob's balance

Pays b to

Code:

OP_IF
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG
OP_ENDIF

Pay a to

Code:

 OP_CHECKSIG

Alice.penalty.n has these outputs

Pays b

Code:

 OP_CHECKSIG

Pays a

Code:

OP_IF
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG
OP_ENDIF

Alice signs Bob.penalty.0 and sends the signature to Bob. Likewise, Bob sends the signature for Alice.penalty.0.

They both sign their transactions and each has one transaction with both signatures.

Once they have done this, they send the revoke code for the previous balance transaction (alice_(n-1) and bob_(n-1)).

With the revoke codes, the earlier transactions are worthless. For example, if Bob broadcast Bob.penalty.n after sending bob_n to Alice, then she could spend the output before he had a chance to claim his output.

By creating new balance transactions, Bob and Alice can update the balance to any value that they want. They need to make sure to send the revoke codes.

Step 4) Create hashlocked output

Bob (or Alice) can create hashlocked outputs.

It is the same as a balance transaction, but with an extra hashlocked output.

Bob.penalty.n has these outputs

a = Alice's balance
b = Bob's balance
h = hashlocked funds (Alice's in this example)

Pays b-h to

Code:

OP_IF
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG
OP_ENDIF

Pay a to

Code:

 OP_CHECKSIG

Pay h to

Code:

OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG

Alice.penalty.n has these outputs

Pays b-h

Code:

 OP_CHECKSIG

Pays a

Code:

OP_IF
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ELSE
  OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG
OP_ENDIF

Pays h

Code:

OP_IF
  OP_HASH160  OP_EQUALVERIFY  OP_CHECKSIG
OP_ELSE
  OP_IF
    OP_HASH160  OP_EQUALVERIFY OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG
  OP_ELSE
    OP_HASH160  OP_EQUAL_VERIFY  OP_CHECKSIG
  OP_ENDIF
OP_ENDIF

They do the same signing, so Bob has a fully signed Bob.penalty.n and Alice has a fully signed Alice.penalty.n.

Once that is done, they revoke the previous transactions. Like the balance transaction, this one is revokable.

Unlike the Lightning network, the hashlock timeout is fixed.

If Alice was to obtain , then they can revert to a balance transaction and then cancel this transaction.

Additionally, the channel can support multiple hash locked outputs (in either direction) by adding more outputs.

The process is always to create a new transaction and then cancel the old state.

When they finally decide to cancel the transaction, they can just sign a transaction which splits the funds accordingly.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl777 on February 10, 2016, 08:37:17 AM

I think it would be possible to have the payment channels do instant payments, but it would require dedicated nodes being the hubs. I guess if they are getting some fees, that would fund them and incentivize people to run them.

Looks like Lightning can handle multiple chains by having 2 transactions using the same hash. The question is if legacy altcoins can handle lightning channels. Cut-and-choose might allow bypassing the malleability problems. It needs more thought.

Quote

The thing I dont like about micropayment channels is that a lot of trades will get delayed if a hub goes offline. But with CLTV maybe a lot of the contortions required in the past can be cleaned up. I expect to have a debugged proof of concept by this weekend for the above plan, so if you can specify in a bit more about the lightening hubs, I can see about coding it up next week.

Channels don't have to fully "lock" even if a hub goes down.

If only 10% of the funds in the channel are committed, then the other 90% can still be used.

If a transaction was broken down into 10 pieces, then a hub going down would only stall one of the pieces.

Hubs might even insure against nodes going down. They could say that they will cover the loss if another hub that they routed through dies (or pay compensation if they go down).

TierNolan

legendary

Activity: 1232

Merit: 1094

Lightning nodes effectively say "If you can find x such that Hash(x) = h within the next d days, then I will pay you b Bitcoins". The node then says to the next link in the chain "If you can find x such that Hash(x) = h within the next (d - 1) days, then I will pay you b Bitcoins".

Finally, the recipient tells the last node what x is. Each node passes it on to the next node. This causes the money to be transferred.

Once the payment goes through, all nodes issue new transactions. The new transactions don't change the state of the channel, but reset it back to the full timeout. Once that happens, the previous transactions are revoked by sending special revoke codes.

If the same x is used for the channels on both coins, then I think it will allow a circle transfer.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl777 on February 10, 2016, 08:37:17 AM

Quote from: TierNolan on February 10, 2016, 08:11:38 AM

Quote from: CIYAM on February 10, 2016, 07:23:42 AM

Assuming I do launch something it will only be supporting the Rank 1 coins (i.e. the least complexity) and if that only includes BTC and LTC then I'm okay with that.

That seems reasonable for version 1, at least. With CLTV, there is no cut-and-choose risk.

I wonder if something like the Lightening network could be accomplished. In that case, trustless hubs could be created. To perform the trade, the trade happens with the hubs acting as trade hubs. The trade hubs could support multiple altcoins.

It would be a p2p network with 2 types of nodes (or at least 2 specialties). As long as you connect to a few hubs, you could trade with anyone on the network.

Using zero-conf methods can eliminate the wait for blocktimes and for small value trades is probably ok.

I think it would be possible to have the payment channels do instant payments, but it would require dedicated nodes being the hubs. I guess if they are getting some fees, that would fund them and incentivize people to run them.

The thing I dont like about micropayment channels is that a lot of trades will get delayed if a hub goes offline. But with CLTV maybe a lot of the contortions required in the past can be cleaned up. I expect to have a debugged proof of concept by this weekend for the above plan, so if you can specify in a bit more about the lightening hubs, I can see about coding it up next week.

I haven't fully look at the entire Lightening network rules.

One of their nice innovations is transaction canceling. They pay to an output that can only be spent after a delay or by a 2 of 2 multisig. If you give the 2nd private key to the person who has the first key, then the transaction is effectively cancelled. If you broadcast the transaction, then the other person can spend the output.

It may require the relative version of checklocktime though (to do the delay).

I was mostly just thinking about possible options to speed things up.

Quote

Assuming we have enough hubs and not worry about their reliability (as long as hub failure just means a refund to unwind the trade)

I am not sure how that works. I think Lightening might have a re-routing option.

Quote

alice <-> hub.btc <-> bob
alice <-> hub.alt <-> bob

One of the extra things with an exchange is that both transactions must be happen atomically. Lightening is a single way transaction.

Quote

bob and alice agree to trade, with bob sending bitcoins to alice and alice sending alts back
each side sends 1/777'th of the value to the hub
the hub forwards to the other node
when a fractional payment is received, the next payment is sent, until trade is complete

Yeah, that is the benefit of channels. You can build up the transaction in parts.

Quote

which is not great, but maybe the number of increments can be reduced to 100, then we have trades completed in less than a minute and nice side effect is you can see a progress bar as the trade is completing

You could ramp it up. The first step could be 0.1% and then ramp up the step size exponentially.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: TierNolan on February 10, 2016, 08:11:38 AM

Quote from: CIYAM on February 10, 2016, 07:23:42 AM

Assuming I do launch something it will only be supporting the Rank 1 coins (i.e. the least complexity) and if that only includes BTC and LTC then I'm okay with that.

That seems reasonable for version 1, at least. With CLTV, there is no cut-and-choose risk.

I wonder if something like the Lightening network could be accomplished. In that case, trustless hubs could be created. To perform the trade, the trade happens with the hubs acting as trade hubs. The trade hubs could support multiple altcoins.

It would be a p2p network with 2 types of nodes (or at least 2 specialties). As long as you connect to a few hubs, you could trade with anyone on the network.

Using zero-conf methods can eliminate the wait for blocktimes and for small value trades is probably ok.

I think it would be possible to have the payment channels do instant payments, but it would require dedicated nodes being the hubs. I guess if they are getting some fees, that would fund them and incentivize people to run them.

The thing I dont like about micropayment channels is that a lot of trades will get delayed if a hub goes offline. But with CLTV maybe a lot of the contortions required in the past can be cleaned up. I expect to have a debugged proof of concept by this weekend for the above plan, so if you can specify in a bit more about the lightening hubs, I can see about coding it up next week.

I did a proof of concept for this a year and a half ago, I called it subatomic trades.

Assuming we have enough hubs and not worry about their reliability (as long as hub failure just means a refund to unwind the trade), then before a node can start trading then setup a pair of micropayment channels for BTC and each coin they want to trade. Once that is setup, they can trade in either direction up to the limit of their deposit amount.

alice <-> hub.btc <-> bob
alice <-> hub.alt <-> bob

bob and alice agree to trade, with bob sending bitcoins to alice and alice sending alts back
each side sends 1/777'th of the value to the hub
the hub forwards to the other node
when a fractional payment is received, the next payment is sent, until trade is complete

No party is ever at risk more than 0.13%
There is a lot more error states possible with this as the deposit might not be enough for a desired trade, reclaiming unused funds is part of the expected process, etc. However, now that I have the networking side working pretty good, I think the advantage of having a set of hubs with payment channels already setup would allow for nearly realtime trading. with 777 increments, the ping times will be the bottleneck, so estimating 300 millis ping time -> a few minutes...

which is not great, but maybe the number of increments can be reduced to 100, then we have trades completed in less than a minute and nice side effect is you can see a progress bar as the trade is completing

Of course, the above can probably be improved to make it much more usable.

James

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: TierNolan on February 10, 2016, 07:20:16 AM

There is an attack on the cut-and-choose.

An attacker could keep starting trades and perform the cut-and-choose step with 1 invalid pair. If they get detected (99.9%), then they can abort the trade.

Since there is no fee paid for step 1, there is no cost to the attacker.

I have updated the protocol to add a step 0. This slows things down since there is another commit step.

There is a tradeoff between complexity and performance.

If the altcoin supports CLTV, it could be used directly.

It is possible that there is an improved protocol for altcoins which support the more flexible P2SH IsStandard rules.

I would split altcoins into 3 ranks.

Rank 1 coins support CLTV
Rank 2 coins skip the IsStandard check for P2SH outputs
Rank 3 coins only allow standard outputs, even for P2SH

Bitcoin moved from rank 3 to rank 2 about 18 months ago and to rank 1 with the release of CLTV.

On the other hand, a single protocol for all altcoins keeps things simple.

It would be necessary to be clear that there is a 0.1% chance of attack. With the step 0 fee commit, it isn't in anyone elses interests to cheat.

This solves the issue I PM'ed you about and removes the costless locking up of funds. so I will update my code with that

James

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: CIYAM on February 10, 2016, 07:23:42 AM

Assuming I do launch something it will only be supporting the Rank 1 coins (i.e. the least complexity) and if that only includes BTC and LTC then I'm okay with that.

That seems reasonable for version 1, at least. With CLTV, there is no cut-and-choose risk.

I wonder if something like the Lightening network could be accomplished. In that case, trustless hubs could be created. To perform the trade, the trade happens with the hubs acting as trade hubs. The trade hubs could support multiple altcoins.

It would be a p2p network with 2 types of nodes (or at least 2 specialties). As long as you connect to a few hubs, you could trade with anyone on the network.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Whilst I think your approach is sound (especially after the additional step) my gut feel is that the complexity of it all is just not going to work very neatly with an implementation.

Assuming I do launch something it will only be supporting the Rank 1 coins (i.e. the least complexity) and if that only includes BTC and LTC then I'm okay with that.

TierNolan

legendary

Activity: 1232

Merit: 1094

There is an attack on the cut-and-choose.

An attacker could keep starting trades and perform the cut-and-choose step with 1 invalid pair. If they get detected (99.9%), then they can abort the trade.

Since there is no fee paid for step 1, there is no cost to the attacker.

I have updated the protocol to add a step 0. This slows things down since there is another commit step.

There is a tradeoff between complexity and performance.

If the altcoin supports CLTV, it could be used directly.

It is possible that there is an improved protocol for altcoins which support the more flexible P2SH IsStandard rules.

I would split altcoins into 3 ranks.

Rank 1 coins support CLTV
Rank 2 coins skip the IsStandard check for P2SH outputs
Rank 3 coins only allow standard outputs, even for P2SH

Bitcoin moved from rank 3 to rank 2 about 18 months ago and to rank 1 with the release of CLTV.

On the other hand, a single protocol for all altcoins keeps things simple.

It would be necessary to be clear that there is a 0.1% chance of attack. With the step 0 fee commit, it isn't in anyone elses interests to cheat.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: TierNolan on February 09, 2016, 12:14:20 PM

A problem with the deployment of CLTV on Bitcoin is that many altcoins don't support it.

This protocol allows transfers to coins that use the oldest type of IsStandardChecks. Outputs have to use basic script or they won't be accepted.

1) Cut and choose

Bob generates 1000 keypairs and sends hash(bob_priv_n) and bob_pub_n to Alice for each n (1 to 1000).

Alice picks n from 1 to 1000 and Bob sends bob_priv_n for the 999 other n's.

If they are ok, then Alice assumes the pair she didn't see is valid.

Similarly, Alice generates 1000 key pairs and has Bob choose.

This gives the following public info.

hash(bob_priv_n) matches bob_pub_n
hash(alice_priv_m) matches alice_pub_m

There is a 0.1% chance of fraud for each attempt. This means that fees must be at least 0.1% of the transaction value. In that way, there is no incentive to cheat at the cut-and-choose.

2) Bob pays D to

Code:

OP_IF
OP_CLTV OP_DROP OP_CHECKSIG
OP_ELSE
OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

D should be more valuable than the value of the Bitcoins or altcoins.

This is a promise by Bob to release bob_priv_n within 2 days (or lose his deposit).

3) Alice pays a altcoins to

Code:

OP_2 OP_2 OP_CHECKMULTISIG

4) Bob pays b Bitcoins to

Code:

OP_IF
OP_CLTV OP_DROP OP_CHECKSIG
OP_ELSE
OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

Alice has 1 day to claim her output, but that means she must provide alice_priv_m.

5) Alice spends the output (and provides alice_priv_m).

6) Bob can spend the altcoin output (since he has both keys)

7) Bob reclaims his deposit

This is atomic and it is recoverable if either party refuses to complete a step.

1) Either party refuses to perform cut-and-choose.

Nothing has been sent to either chain, so no harm done.

2) Bob refuses to pay deposit.

Nothing has been sent to either chain, so no harm done.

3) Alice refuses to bail-in.

Bob reclaims his D after 2 days.
Releasing bob_priv_n has no effect since there was no bail-in by Alice, so the key is never used.

4) Bob refuses to bail-in

If Bob reclaims his deposit, then Alice will have both private keys and can reclaim her bail-in.

If Bob fails to claim his deposit, then Alice gets that as compensation instead of her bail-in. In that case, Bob loses his deposit and can't claim the altcoins. This means he should reclaim his output.

5) Alice refuses to claim her Bitcoins

1 day later Bob can reclaim his Bitcoins

Alice gets her altcoins back or she gets D instead (if Bob doesn't reclaim his deposit).

6) Bob refuses to claim his altcoins

He loses his altcoins when he reclaims his deposit. Alice already has his Bitcoins by this point.

He has an incentive to complete this step.

7) Bob refuses to claim his deposit

He loses his deposit and Alice gets it.

He has an incentive to complete this step.

For each step, there is either an incentive to complete the step or failure to complete the step causes the protocol to abort. In an abort, the incentives are to perform a clean abort.

Fantastic! Yes, this seems to solve the issue. I will change things to match this.

James

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Am going to have to digest your new protocol a bit but I think it is quite interesting.

BTW - if you are interested in being part of creating a decentralised exchange with this sort of protocol as the "settlement layer" then welcome to PM me (I have decided that due to the time it would take to perform such ACCTs they are only going to be good for "settlement" so order matching and general trading will be done via a separate blockchain or maybe a sidechain).

TierNolan

legendary

Activity: 1232

Merit: 1094

A problem with the deployment of CLTV on Bitcoin is that many altcoins don't support it.

This protocol allows transfers to coins that use the oldest type of IsStandardChecks. Outputs have to use basic script or they won't be accepted.

0) Commit to paying fees NEW

Both parties pick a random number and the trade_id = hash256(alice_random_number | bob_random_number)

Both parties should create a transaction which pays to

Code:

OP_1 <02, tradeId> OP_2 OP_CHECKMULTISIG

It must pay fees that are greater than 0.1% of the coins being exchanged. It is a one of two multisig. Since the 2nd public key is generated from the trade_id, nobody has the corresponding private key. This means that it is the same as having 1 key, but it allows committing the fee to the trade.

If <02, tradeId> is not a valid compressed key, then a new tradeId should be selected, until a valid compressed key can be created.

This step could be skipped when in "trusting" mode. If other parties tend to abort before step 1 ends, then the node could switch to untrusting mode.

Reputation systems could be deployed here.

1) Cut and choose

Bob generates 1000 keypairs and sends hash(bob_priv_n) and bob_pub_n to Alice for each n (1 to 1000).

Alice picks n from 1 to 1000 and Bob sends bob_priv_n for the 999 other n's.

If they are ok, then Alice assumes the pair she didn't see is valid.

Similarly, Alice generates 1000 key pairs and has Bob choose.

This gives the following public info.

hash(bob_priv_n) matches bob_pub_n
hash(alice_priv_m) matches alice_pub_m

There is a 0.1% chance of fraud for each attempt. This means that fees must be at least 0.1% of the transaction value. In that way, there is no incentive to cheat at the cut-and-choose.

2) Bob pays D to

Code:

OP_IF
OP_CLTV OP_DROP OP_CHECKSIG
OP_ELSE
OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

D should be more valuable than the value of the Bitcoins or altcoins.

This is a promise by Bob to release bob_priv_n within 2 days (or lose his deposit).

3) Alice pays a altcoins to

Code:

OP_2 OP_2 OP_CHECKMULTISIG

4) Bob pays b Bitcoins to

Code:

OP_IF
OP_CLTV OP_DROP OP_CHECKSIG
OP_ELSE
OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

Alice has 1 day to claim her output, but that means she must provide alice_priv_m.

5) Alice spends the output (and provides alice_priv_m).

6) Bob can spend the altcoin output (since he has both keys)

7) Bob reclaims his deposit

This is atomic and it is recoverable if either party refuses to complete a step.

1) Either party refuses to perform cut-and-choose.

Nothing has been sent to either chain, so no harm done.

2) Bob refuses to pay deposit.

Nothing has been sent to either chain, so no harm done.

3) Alice refuses to bail-in.

Bob reclaims his D after 2 days.
Releasing bob_priv_n has no effect since there was no bail-in by Alice, so the key is never used.

4) Bob refuses to bail-in

If Bob reclaims his deposit, then Alice will have both private keys and can reclaim her bail-in.

If Bob fails to claim his deposit, then Alice gets that as compensation instead of her bail-in. In that case, Bob loses his deposit and can't claim the altcoins. This means he should reclaim his output.

5) Alice refuses to claim her Bitcoins

1 day later Bob can reclaim his Bitcoins

Alice gets her altcoins back or she gets D instead (if Bob doesn't reclaim his deposit).

6) Bob refuses to claim his altcoins

He loses his altcoins when he reclaims his deposit. Alice already has his Bitcoins by this point.

He has an incentive to complete this step.

7) Bob refuses to claim his deposit

He loses his deposit and Alice gets it.

He has an incentive to complete this step.

For each step, there is either an incentive to complete the step or failure to complete the step causes the protocol to abort. In an abort, the incentives are to perform a clean abort.

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: CIYAM on February 04, 2016, 04:49:10 AM

Quote from: coins101 on February 04, 2016, 04:29:22 AM

If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.

Without many offers presumably the application could never even take off (that would require some marketing effort) but the speed is limited by the method (ACCT using CLTV) rather than by the number of offers that are available.

(and it would become a bit tricky for users to keep track of a whole lot of trades that will require them to create txs at the right point in time)

The end result is very exciting, but the current process is a bit clunky.

Liquidity providers can hold a certain amount of 'x' altcoin which will be ready for exchange at any point. This would be a great way for people to make some money on being liquidity providers. You wouldn't need to worry about marketing.

With liquidity providers with ratings, you're not far off an alt/btc only variant of localbitcoins / shapeshift.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: coins101 on February 04, 2016, 04:29:22 AM

If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.

Without many offers presumably the application could never even take off (that would require some marketing effort) but the speed is limited by the method (ACCT using CLTV) rather than by the number of offers that are available.

(and it would become a bit tricky for users to keep track of a whole lot of trades that will require them to create txs at the right point in time)

coins101

legendary

Activity: 1456

Merit: 1000

If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

In order to make the UI "nicer" I am using "unix time stamps" rather than block numbers - so with a bit of work maybe I could convert the time stamp back into a block number and improve the speed that this could be used at (as Bitcoin time stamps can be out by as much as two hours).

But even so - you are going to need to see at least 1 confirmation from the "initiator" (to the P2SH address they need to send to) before you are going to bother (as the "responder") to send to the complimenting P2SH address (as you wouldn't lock up your funds if you haven't seen that).

And presumably the "initiator" won't reveal their secret until at least one confirmation (keeping in mind that 1 confirmation is still somewhat risky).

So the likelihood of an ACCT taking place in less than an hour is not that much (so this is not a solution for day traders).

Topic: ACCT using CLTV - More Effective than a sleeping pill! (Read 3575 times)