|
Title: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on January 25, 2016, 06:00:26 PM So using the CIYAM Trade application along with using a CIYAM console acting as a Bitcoin/Litecoin wallet I demonstrated to my wife how you could exchange LTC for BTC without a 3rd party (or fees other than tx fees) and apparently it was so boring she fell asleep.
Code: Generating a spendable amount of RHS for "user1"... So I've built a decentralised exchange but I am getting the feeling that I have probably wasted my time doing so (am glad it hasn't taken me more than a couple of weeks). Does anyone really think that this kind of idea is going to work? Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: Trouble821 on January 25, 2016, 09:10:45 PM Yes if it's fast enough. The Ripple distributed exchange was always slow compared to regular exchanges, but it did plenty of business last year.
If you could make a trade in 30 seconds or less people would use it. A few coins tried cutting block times to the minimum, and managed a block every few seconds which could make an exchange fairly fast. Viacoin has a 24 seconds block time, and Bitshares 2.0 started with 5 second blocks with the option of reducing it to one second blocks. If the qora devs saw value in reducing the block time to accommodate an exchange they would probably do it. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: cr1776 on January 25, 2016, 09:38:41 PM So using the CIYAM Trade application along with using a CIYAM console acting as a Bitcoin/Litecoin wallet I demonstrated to my wife how you could exchange LTC for BTC without a 3rd party (or fees other than tx fees) and apparently it was so boring she fell asleep. ... So I've built a decentralised exchange but I am getting the feeling that I have probably wasted my time doing so (am glad it hasn't taken me more than a couple of weeks). Does anyone really think that this kind of idea is going to work? A decentralized exchange with a good interface would be quite useful for many. Can it do the reverse? e.g. BTC for LTC? I presume this related to the CHECKLOCKTIMEVERIFY and the check <data1> against <sig1> questions....I haven't looked at the code above yet. Congrats on getting it working. Why do you think you've wasted your time? Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on January 26, 2016, 03:54:54 AM A decentralized exchange with a good interface would be quite useful for many. Can it do the reverse? e.g. BTC for LTC? Yes - it would support that (just using the CIYAM software). I presume this related to the CHECKLOCKTIMEVERIFY and the check <data1> against <sig1> questions....I haven't looked at the code above yet. Indeed - that is how it operates. Congrats on getting it working. Why do you think you've wasted your time? Thanks - well - when it is done using AT instead then it will be integrated into a wallet and not have many steps (so ACCT between QORA and BURST should be a good experience). As CIYAM's blockchain is still a "work in progress" I would have to release Trade as a web application requiring therefore a separate Wallet application to operate with it (which is what my testing is emulating). That adds a few steps (copying and pasting) which I think is not going to be viewed very enthusiastically. Also when it comes to using Bitcoin (or even Litecoin) you could not realistically be expecting to do trades in under an hour or so (because time stamps in blocks are just not that accurate and you would need to wait for at least one confirmation between each step). Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on January 26, 2016, 04:51:50 AM To elaborate on the workflow that would be involved in trading LTC for BTC:
Number of steps for Alice (apart from creating the offer) is four whilst the number of steps for Brian is three (guess it should be slightly easier for the party that "goes first"). Note that if the Wallet is clever enough then perhaps Alice's second last step can be simply automated (i.e. the last two steps could be combined into one) but I think three steps each is about as good as it can get with this design. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 02, 2016, 12:24:23 PM Why is there a need for copy/pasting?
You could require that both people have their litecoin and bitcoin wallets open and connect to them via RPC. The standard clients can generate private keys and fund transactions. They even handle P2SH addresses that are basic. The annoying part of ACCT is that waiting for confirms is kind of required. This means that you are really giving an option to the other party. The other person can drop out if the price shifts. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 02, 2016, 12:29:03 PM Why is there a need for copy/pasting? You could require that both people have their litecoin and bitcoin wallets open and connect to them via RPC. The standard clients can generate private keys and fund transactions. They even handle P2SH addresses that are basic. The reason for that is just up to how it is implemented and yes it could be possible to get rid of that via scripts, etc. Unfortunately the ACCT/CLTV Bitcoin tx is not something that Bitcoin (or Litecoin) can handle with its raw tx support (so it can't create the tx and nor can it sign it). The annoying part of ACCT is that waiting for confirms is kind of required. This means that you are really giving an option to the other party. The other person can drop out if the price shifts. I think that is simply the nature of the beast (so it will never be attractive for "day traders"). Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 02, 2016, 03:36:29 PM Unfortunately the ACCT/CLTV Bitcoin tx is not something that Bitcoin (or Litecoin) can handle with its raw tx support (so it can't create the tx and nor can it sign it). You have to build up the transactions manually, but it does track coins held by the wallet. It also tracks payments to the wallet, as long as you pay them to one of the standard output formats. The fun with testing is that you need to run 4 wallets. You can quickly burn all your outputs and then have to wait 10 minutes for more. The RPC commands I used in my unfinished (pre-checklocktimeverify) version are: listunspent (gets available coins in the wallet) getrawchangeaddress (for change) getnewaddress (for receiving) dumpprivkey (for converting an address into a private key) validateaddress (gets info about the address) sendrawtransaction (sends the raw transaction) Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 02, 2016, 03:39:36 PM Yup - I found that for the 4 wallets the simplest approach is to use "-regtest" (as you can generate the coins instantly).
I also use pretty much the same commands you list - but the construction and signing is done with my own software (I was a little disappointed that Bitcoin couldn't do at least the signing but it is a very unusual looking raw tx so perhaps not that surprising). The CIYAM script I am using for testing this is here: https://github.com/ciyam/ciyam/blob/master/src/bct_acct_test.cin (some of it is probably a bit mysterious but you can see the Bitcoin RPC calls fairly clearly). Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 02, 2016, 03:46:45 PM Note that I didn't use the "get" calls or "dumprivkey" as for the purposes of simplifying the test script I used hard-coded private keys (but in a "live version" I would be basically doing just that).
Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 02, 2016, 04:02:40 PM 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). Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: coins101 on February 04, 2016, 09:29:22 AM If you allow for third party liquidity providers (one or many, eg crowd funded trades), you can pair trades faster.
Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 04, 2016, 09:49:10 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) Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: coins101 on February 04, 2016, 07:54:55 PM 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 09, 2016, 05: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. 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 <creators_public_key> <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 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 <bob_pub_n> <alice_pub_m> OP_2 OP_CHECKMULTISIG 4) Bob pays b Bitcoins to Code: OP_IF 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 09, 2016, 05:21:44 PM 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). Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: jl777 on February 09, 2016, 10:04:51 PM A problem with the deployment of CLTV on Bitcoin is that many altcoins don't support it. Fantastic! Yes, this seems to solve the issue. I will change things to match this. 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 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 <bob_pub_n> <alice_pub_m> OP_2 OP_CHECKMULTISIG 4) Bob pays b Bitcoins to Code: OP_IF 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. James Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 10, 2016, 12:20:16 PM 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: CIYAM on February 10, 2016, 12:23:42 PM 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 10, 2016, 01:11:38 PM 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: jl777 on February 10, 2016, 01:15:08 PM There is an attack on the cut-and-choose. This solves the issue I PM'ed you about and removes the costless locking up of funds. so I will update my code with thatAn 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. James Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: jl777 on February 10, 2016, 01:37:17 PM 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 Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 10, 2016, 02:31:29 PM 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 10, 2016, 04:11:08 PM 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 10, 2016, 07:06:05 PM 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). Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 10, 2016, 08:06:05 PM 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 and Code: OP_IF and Code: OP_IF 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 <bob_pub_1> <alice_pub_0> OP_2 OP_CHECKMULTISIG Pays a Code: OP_2 <bob_pub_0> <alice_pub_1> 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 Pay a to Code: <alice_pub_n> OP_CHECKSIG Alice.penalty.n has these outputs Pays b Code: <bob_pub_n> OP_CHECKSIG Pays a Code: OP_IF 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 Pay a to Code: <alice_pub_n> OP_CHECKSIG Pay h to Code: OP_HASH160 <hash(unlock)> OP_EQUAL_VERIFY <alice_pub_n> OP_CHECKSIG Alice.penalty.n has these outputs Pays b-h Code: <bob_pub_n> OP_CHECKSIG Pays a Code: OP_IF Pays h Code: OP_IF 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 <unlock>, 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 11, 2016, 08:06:09 PM I created a BIP (https://github.com/TierNolan/bips/blob/cpkv/bip-cprkv.mediawiki) that would remove the need for cut-and-choose.
Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 12, 2016, 04:51:37 PM 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 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. Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: jl777 on February 14, 2016, 08:32:24 AM 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 James Title: Re: ACCT using CLTV - More Effective than a sleeping pill! Post by: TierNolan on February 14, 2016, 01:33:58 PM 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. |