|
Title: Alt chains and atomic transfers Post by: TierNolan on May 02, 2013, 10:35:53 AM One of the big benefits of colored coins is that the transactions are atomic.
You can buy 10 shares in a company for 20 BTC and either the transaction happens or it doesn't. You don't get into a situation where you pay (or give the shares) and then the other transaction is reversed for some reason. One way of doing it would be to verify that the other transaction was buried in a second chain. This could involve checking that a token was in a merkle tree. Step 1: verify that the token matches the desired token OP_DUP [target-token] OP_EQUALVERIFY Step 2: build up merkle tree (fixed depth) [3] OP_ROLL OP_IF OP_SWAP OP_ENDIF OP_CAT OP_HASH256 It is assumed the input is [true/false] [child1] [child2] If true, then child1 and child2 are swapped and then the hash is computed. OP_CAT is currently disabled. The output is [parent] The spend would be [true/false] [merkle-node] [true/false] [merkle-node] .... [true/false] [merkle-node] [token] When this step is finished, then the merkle root would be on the stack. Step 3: scan the alt-chain headers OP_SWAP would be needed before starting to move the merkle root back one. The alt-chain is assumed to have only 3 fields in its header. The input is [nonce] [merkle-root] [previous-hash] OP_CAT OP_CAT OP_HASH256 OP_DUP OP_LESS_THAN [target] OP_VERIFY [2] OP_PICK OP_EQUALVERIFY This computes the hash and checks that it meets difficulty. It then checks that the "previous-hash" for the next header matches the hash of this header. This would be repeated for as many blocks as required. The effect of all of these steps is that it is a script that is released if the token is buried in another chain at least a certain number of blocks deep. To spend, you have to provide the merkle path to the root and then the nonce and merkle root for the headers which build on this one. Depending on the value of the transactions more confirming blocks would be required. The OP_CAT opcode is currently disabled. It isn't really clear what a disabled opcode means. If it isn't accepted, then it effectively doesn't exist. Title: Re: Alt chains and atomic transfers Post by: iddo on May 07, 2013, 10:23:49 AM I'm not completely sure whether I understood your objective here, and I also didn't I understand some of the specifics.
If the objective is to trade (colored) coins between two chains (e.g. Bitcoin and Litecoin) where the trade is atomic, in the sense that either both parties received the coins that they wanted, or neither party did, then I think that we can use this simple protocol: 1) Alice has n1 bitcoins, Bob has n2 litecoins, and they want to trade them. 2) Bob selects a random password X and broadcasts to the Litecoin network a transaction that spends his n2 litecoins to a script that requires the usual OP_CHECKSIG for Alice's Litecoin address as well as "OP_SHA256 Y OP_EQUAL" where Y=SHA256(X), meaning that Alice (and only Alice) can spend those n2 litecoins, but only if she knew an X that satisfies Y==SHA256(X). This transaction is public, so Alice and everyone else see it on the Litecoin blockchain. 3) Alice now broadcasts to the Bitcoin network a similar transaction that allows Bob to spend her n1 bitcoins only if he reveals an X that gives Y==SHA256(X), i.e. a transaction with OP_CHECKSIG for Bob's Bitcoin address and "OP_SHA256 Y OP_EQUAL". 4) If Bob spends the n1 bitcoins (e.g. by sending them to another Bitcoin address of his) then he necessarily reveals X, so now Alice can do the same and spend the n2 litecoins. 5) To avoid extortion, we can use nlocktime (similarly to how it's used in the Contracts wiki page), so for example the transaction on the Litecoin network in step (2) expires after 2 days (meaning that Bob could spend the coins back to himself after 2 days), and the transaction on the Bitcoin network in step (3) expires after 1 day. This implies that if Bob spends the n1 bitcoins then we can be sure that Alice will be able to spend the n2 litecoins, and if either Alice or Bob abort at any stage then no harm is done. Title: Re: Alt chains and atomic transfers Post by: Sergio_Demian_Lerner on May 07, 2013, 12:43:36 PM Check this thread. I think is similar to what you say.
P2PTradeX: P2P Trading between cryptocurrencies (https://bitcointalk.org/index.php?topic=91843.0) Title: Re: Alt chains and atomic transfers Post by: TierNolan on May 07, 2013, 12:59:34 PM I'm not completely sure whether I understood your objective here, and I also didn't I understand some of the specifics. Basically, it is a script that verifies that a hash has been included in an alt chain's merkle tree to a certain depth. Quote 5) To avoid extortion, we can use nlocktime (similarly to how it's used in the Contracts wiki page), so for example the transaction on the Litecoin network in step (2) expires after 2 days (meaning that Bob could spend the coins back to himself after 2 days), and the transaction on the Bitcoin network in step (3) expires after 1 day. This implies that if Bob spends the n1 bitcoins then we can be sure that Alice will be able to spend the n2 litecoins, and if either Alice or Bob abort at any stage then no harm is done. That isn't how locktime works. Locktime means that the transaction can't be included into the chain until the given time. Ideally, for an atomic system, it must be possible for it to be cancelled at any stage. This is what the block chain does, in order to establish ordering of transactions. Step 1: Bob sends coin unlocked by Alice's public key and X for sha(X) If the transaction ends here, Bob loses his money Step 2: Alice sends coins unlocked by Bob's public key and X for sha(X) If the transaction ends here, Alice loses her money. Bob can spend his at some later time. Step 3: Bob sends X for sha(X) to Alice or to block chain Transaction is completed. What is needed is something like Step 1: Bob sends coin unlocked by [Alice's public key and Proof step 3 happened] or [Proof step 3 didn't happen] If the transaction ends here, Bob loses his money Step 2: Alice sends coins unlocked by [Bob's public key and Proof step 3 happened] or [Proof step 3 didn't happen] If the transaction ends here, Alice loses her money. Bob can spend his at some later time. Step 3: Bob sends X for sha(X) to Alice or to block chain Transaction completed. What you want is an alt chain that gives the proof. You could have a time-stamping chain. You can submit X to the chain and then it blocks sha(X) being added and vice versa. The script in the OP was a way to say that the proof must be buried deep in some alt chain. Title: Re: Alt chains and atomic transfers Post by: TierNolan on May 07, 2013, 01:00:41 PM P2PTradeX: P2P Trading between cryptocurrencies (https://bitcointalk.org/index.php?topic=91843.0) Yeah. In fact, having the alt-chain support the system is better than trying for BTC script. Title: Re: Alt chains and atomic transfers Post by: iddo on May 07, 2013, 02:09:23 PM Quote 5) To avoid extortion, we can use nlocktime (similarly to how it's used in the Contracts wiki page), so for example the transaction on the Litecoin network in step (2) expires after 2 days (meaning that Bob could spend the coins back to himself after 2 days), and the transaction on the Bitcoin network in step (3) expires after 1 day. This implies that if Bob spends the n1 bitcoins then we can be sure that Alice will be able to spend the n2 litecoins, and if either Alice or Bob abort at any stage then no harm is done. That isn't how locktime works. Locktime means that the transaction can't be included into the chain until the given time. I meant something similar to what gmaxwell described here (https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked): "You first create the Do you agree that the simple protocol that I described gives atomic trade across chains with no possibilities for extortion? Title: Re: Alt chains and atomic transfers Post by: ripper234 on May 21, 2013, 08:25:59 AM I had some difficulty Googling for a clear explanation of atomic cross-chain trading, so I gathered my findings into this wiki page (https://en.bitcoin.it/wiki/Atomic_cross-chain_trading).
I must admit I do not fully understand Mike Hearns' explanation (https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) as presented, I suggest we use the wiki page to develop and clarify the solution as needed. Title: Re: Alt chains and atomic transfers Post by: TierNolan on May 21, 2013, 01:31:21 PM I must admit I do not fully understand Mike Hearns' explanation (https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) as presented, I suggest we use the wiki page to develop and clarify the solution as needed. This basically works by sending the 2 coins to a script that can only be spent if you have the recipient's public key and the x for a matching H(x). Step 1 A generates H(x) A sends coins to <B's public key> and x for H(x) Step 2 B knows that A has sent his coins, so B sends coins to <A's public key> and x for H(x) Step 3 A sends x to B. The can now both spend the coins they received. If A refuses to perform step 3, when A spends the coins B sent, he has to provide x to the chain. At that point B can spend his coins. The worst A can do is defect and refuse to unlock the coins he sent B, until he wants to spend the coins he received. This is potentially a problem. Title: Re: Alt chains and atomic transfers Post by: iddo on May 21, 2013, 03:36:50 PM The worst A can do is defect and refuse to unlock the coins he sent B, until he wants to spend the coins he received. This is potentially a problem. No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here (http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/05/14#l7436698). Title: Re: Alt chains and atomic transfers Post by: TierNolan on May 21, 2013, 05:31:26 PM No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here (http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/05/14#l7436698). Sounds reasonable. A picks a random number x A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)" A creates TX2: "Pay w BTC from TX1 to <A's public key>, locked 48 hours in the future A sends TX2 to B B signs TX2 and returns to A 1) A submits TX1 to the network B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)" B creates TX4: "Pay v alt-coins from TX3 to <B's public key>, locked 24 hours in the future B sends TX4 to A A signs TX4 and sends back to B 2) B submits TX3 to the network 3) A spends TX3 giving x 4) B spends TX1 using x This is atomic (with timeout). If the process is halted, it can be reversed no matter when it is stopped. Before 1: Nothing public has been broadcast, so nothing happens Between 1 & 2: A can use refund transaction after 48 hours to get his money back Between 2 & 3: B can get refund after 24 hours. A has 24 more hours to get his refund After 3: Transaction is completed by 2 - A must spend his new coin within 24 hours or B can claim the refund and keep his coins - B must spend his new coin within 48 hours or A can claim the refund and keep his coins For safety, both should complete the process with lots of time until the deadlines. Title: Re: Alt chains and atomic transfers Post by: ripper234 on May 25, 2013, 09:17:53 PM Thanks for the great explanation, now it's all clear.
Title: Re: Alt chains and atomic transfers Post by: TierNolan on August 02, 2013, 08:25:13 PM I was thinking of trying this out.
Does anyone know if there is a pool like Eligius for Litecoin that accepts non-standard transactions? Title: Re: Alt chains and atomic transfers Post by: jl2012 on August 03, 2013, 04:19:56 AM I was thinking of trying this out. Does anyone know if there is a pool like Eligius for Litecoin that accepts non-standard transactions? Maybe do it on testnet Title: Re: Alt chains and atomic transfers Post by: TierNolan on August 03, 2013, 08:15:41 AM Maybe do it on testnet Does litecoin have a testnet, I guess that would work? Anyway, I was thinking that the feature could be achieved using channels. Both traders would open a channel to handle the trade. This can be done with standard multi-sig transactions. LTC fees are 0.1 LTC which is pretty high. If nodes created channels to 8 other nodes, then you could get a distributed exchange. Each node would act as market maker between the peers it was connected to. It would tell the other nodes what its bid/ask price was. Persistent nodes could potentially generate profit for their operators. Title: Re: Alt chains and atomic transfers Post by: socrates1024 on October 10, 2013, 07:31:03 PM I've been skeptical of atomic cross-chain trades for a while now. In particular I edited the Contracts wiki page to explain that the proposed technique (the "luxgladius" protocol) has a fatal race condition. But now I'm convinced that solution proposed here works and has no race condition. And it's simpler than P2PTradeX, which is good (although P2PTradeX may still be useful for other things). So, here's my writeup of how this works. Unless I realize I missed something, I want to revise the Contracts wiki page to point to TierNolan's description by default one, and remove the disclaimer that cross-trades don't work! https://en.bitcoin.it/wiki/Contracts
Quote This is an explanation of TierNolan's atomic cross transaction technique. It's similar to one by luxgladius, except this protocol avoids a race condition by using asymmetry - only Alice has a secret, and the timeout on one chain is much longer than the other. https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 Alice has 1btc (Bitcoin) and Bob has 1atc (Altcoin). They would like to conduct an atomic exchange, so that after a finite time, either Alice has 1atc and Bob has 1btc, or the transaction was aborted and their positions are both unchanged. We assume that both the Bitcoin and Altcoin chains are loosely synchronized to eachother, such that neither chain gets more than 12 hours ahead of the other. Phase 1: Alice bails in Alice draws a random secret x. Alice constructs TX1 to bail in a bitcoin. TX1 has a single txout with 1 btc, containing the following scriptPubkey: Code: OP_IF Alice signs TX1 but does not yet publish it. She creates TX2, her refund transaction, which has a locktime of +48 hours. It contains TX1[0] as a txin, and the txout is a standard spend to A. The scriptSig for this txin looks like Code: <sigB2> <sigA2> 1 Alice transmits TX2 to Bob, and requests that Bob signs and returns it. Once Alice receives Bob’s signature sigB2, then Alice publishes TX1, knowing that she will be able to claim her refund after 48 hours, as long as she does not reveal x. Alice is now bailed in. Phase 2: Bob bails in Bob received TX2 in the first phase, and therefore knows H(x). Bob also signed Alice’s refund transaction, but that will not be active until after 48 hours. If Bob is honest, he’ll get what he wants within 24 hours in any case. Bob has also seen that TX1 has been published. Bob creates TX3, which bails in an Altcoin. TX3 is symmetric with TX1, and has a single txout with 1atc, containing the following scriptPubkey: Code: OP_IF Bob also creates TX4, which is his own Altcoin refund. TX4 is timelocked for only 24 hours, uses TX3[0] as a txin, and the scriptSig looks like Code: <sigB4> <sigA4> 1 Phase 3: Alice reveals x and triggers both transactions. Alice has 24 hours to claim the Altcoin, using the following scriptSig: Code: <sigA4’> <x> 0 Code: <sigB2’> <x> 0 This is atomic because: a) each party *bails in* their coins only after receiving a *refund signature* from the other party. b) the refund delay is significantly larger on the Bitcoin chain than on the Altcoin chain, and Alice, who initially knows x, bails in her coin first. Title: Re: Alt chains and atomic transfers Post by: Sergio_Demian_Lerner on October 10, 2013, 08:36:59 PM This socrates1024 protocol seems to be much better than some others I saw. I can't find any drawback.
Title: Re: Alt chains and atomic transfers Post by: Sukrim on October 10, 2013, 10:14:24 PM As far as I understand, Alice cannot put out a general offer though, she can only trade with Bob and vice versa. This might be a potential drawback. On the other hand this is about atomic transfers, not cross chain trade offers...
What if Alice (because she likes to do arbitrage and is speculating on shifting values) reveals her x very late (after 23:59h and 59 seconds)? This would lead to the case that she doesn't get her altcoin but bob can still claim the Bitcoin, right? Also might it be the case that this leads to some issues in the altcoin network, if half of the nodes see her revealing X thus granting her the altcoin and the other half believe that the time is over and the altcoin should return to Bob? Title: Re: Alt chains and atomic transfers Post by: socrates1024 on October 10, 2013, 10:19:34 PM What if Alice (because she likes to do arbitrage and is speculating on shifting values) reveals her x very late (after 23:59h and 59 seconds)? This would lead to the case that she doesn't get her altcoin but bob can still claim the Bitcoin, right? Alice can only harm herself by waiting so close to the deadline. This is OK.Title: Re: Alt chains and atomic transfers Post by: Sukrim on October 11, 2013, 07:36:19 AM Well, then there's still the issue with altcoins being (far) less secure than Bitcoin:
Alice reveals X, Bob 51% attacks Altcoin to undo/prevent Alice's transaction for the remaining n hours, Bob redeems Bitcoin. Are Altcoins just viewed as "secure" in this scenario and is this a reasonable assumption in reality? This again might be seen as not relevant, as not the protocol but the chain is attacked. Still it would be nice to allow Alice to trade with anyone, not just a certain Bob. Title: Re: Alt chains and atomic transfers Post by: agorism on November 25, 2013, 12:48:05 AM See links for details: http://bitcoin.stackexchange.com/questions/2317/script-op-if-etc-clarifications This also talks about if statments in forth: http://theforthsource.com/guide10.html This is my attempt to re-write it. //I am assuming that if <x> is known, that it is already on the stack. //The first "2" is because of bitcoin's bug. The second "2" is an input for op_checkmultisig 2 <pubkeyMine> <pubkeyOther> 2 OP_CHECKMULTISIG OP_DUP //OP_DUP (duplicate top of stack) is here //because OP_NOTIF pops an item off the stack. //If checkmultisig worked, then we want to skip to the end and verify. if checkmultisig did not work, //then we still have another chance OP_NOTIF OP_DROP //This gets rid of the 0 that OP_checkmultisig gave us. Now <x> should be on top. OP_HASH160 <H(x)> OP_EQUAL //If the hash of x is <H(x)>, then this will leave a 1 on top. otherwise, it leaves a 0. <pubkeyOther> OP_CHECKSIG //If B has signed, put a 1 on top 1 OP_EQUAL OP_EQUAL //If the top 2 items were (1, 1) then, delete them and put a 1 on top. Otherwise delete them // and put a 0 on top. T OP_ENDIF OP_VERIFY Now I understand what you were doing Socrates1024 Title: Re: Alt chains and atomic transfers Post by: Peter Todd on November 25, 2013, 07:33:29 AM Socrates1024, I have never written any forth code, but I am pretty sure that how you are using "op_if" is incorrect. I just glanced at it, so take this with a grain of salt, but he's using a standard trick in Bitcoin scripting of using an op_if op_else op_endif to select which condition the script is testing directly rather than test and re-test on failure. You spend such a scriptPubKey with something like this: scriptSig: {values that satisfy the script} <1 or 0 depending on which version you want to use> Title: Re: Alt chains and atomic transfers Post by: kactech on December 29, 2013, 09:36:07 AM @socrates1024
I cannot spent bail-in in current form with BitcoinJ library Executing with signing script Code: x(btc bug) <sigA> <sigB> 1 Could it be a BitcoinJ bug or something is missing in your script? I think it could work with "CHECKMULTISIGVERIFY OP_TRUE" as OP_VERIFY returns Nothing/Invalid Thanks! Title: Re: Alt chains and atomic transfers Post by: bluemeanie1 on December 29, 2013, 08:14:54 PM One of the big benefits of colored coins is that the transactions are atomic. I think you need to do a lot more work to prove this fully. A lot of the publications surrounding this project have been flimsy as of late. Seems this area is overrun by amateurism, but you need to show in specific concrete terms how this works and publish it with a NAME and DATE. Title: Re: Alt chains and atomic transfers Post by: TierNolan on December 29, 2013, 08:44:41 PM I think you need to do a lot more work to prove this fully. A lot of the publications surrounding this project have been flimsy as of late. The point I meant was that it you exchange BTC for coloured coins, then it is inherently atomic. Handling more than 1 chain is more complex. However, ignoring large scale chain reversals, the atomic transfer system in this thread would be atomic too. Title: Re: Alt chains and atomic transfers Post by: bluemeanie1 on December 29, 2013, 08:49:54 PM I think you need to do a lot more work to prove this fully. A lot of the publications surrounding this project have been flimsy as of late. The point I meant was that it you exchange BTC for coloured coins, then it is inherently atomic. Handling more than 1 chain is more complex. However, ignoring large scale chain reversals, the atomic transfer system in this thread would be atomic too. some of the recent proposals [1] suggest doing Color Coins in an altchain, thus according to your claims here you lose this 'atomic' exchange quality with BTC. btw- using Confidence Chains you have 100% reliable exchanges because we support them directly in the TX formats. http://www.altchain.org/?q=whitepapers/paper2.html [1] not sure if proposal is the right term, more like CRG: collaborative rumor generation? Title: Re: Alt chains and atomic transfers Post by: kactech on December 30, 2013, 10:05:06 AM Here is working sketch of trade flow:
https://github.com/kactech/atomictc/blob/pub/src/test/java/com/kactech/atomictc/AtomicTests.java ASCII armored messages from test run: https://github.com/kactech/atomictc/wiki/Five-Steps-Trade-communication To simplify things there are only 2 pubKeys(and related addresses) used, traders exchange only things needed to recreate transactions at their side(instead of sending full refund transactions they send bailInHash and amount), trade state is POJO saved to JSON. It would be nice to hear your thoughts Sorry for spelling Cheers ### TODOS: * UTXOs locking * spam prevention: if Bob doesn't know Alice(or chains have significantly different transaction costs) he can f.e. require her refund to be partitioned (refund amount split over more outputs) to make Alice's refund more expensive than his Title: Re: Alt chains and atomic transfers Post by: bluemeanie1 on December 30, 2013, 05:14:26 PM my thoughts are Im not going to take this seriously until someone at least spends the time writing out an explanation of it with their name on it. A 'rough sketch' or 'code is the spec' isn't an asset, it's a sign that no one thought anything through and they just wanted to produce some code to look like work has been done. the last interesting thing I saw come out of Color Coins was Meni Rosenfeld's whitepaper. I might be a bit more generous with my attention span but unfortunately a number of obnoxious people have moved into that neighborhood. I don't know you so Im not judging you personally. -bm Here is working sketch of trade flow: https://github.com/kactech/atomictc/blob/pub/src/test/java/com/kactech/atomictc/AtomicTests.java ASCII armored messages from test run: https://github.com/kactech/atomictc/wiki/Five-Steps-Trade-communication To simplify things there are only 2 pubKeys(and related addresses) used, traders exchange only things needed to recreate transactions at their side(instead of sending full refund transactions they send bailInHash and amount), trade state is POJO saved to JSON. It would be nice to hear your thoughts Sorry for spelling Cheers ### TODOS: * UTXOs locking * spam prevention: if Bob doesn't know Alice(or chains have significantly different transaction costs) he can f.e. require her refund to be partitioned (refund amount split over more outputs) to make Alice's refund more expensive than his Title: Re: Alt chains and atomic transfers Post by: kactech on December 31, 2013, 07:34:04 AM @bluemeanie1
I don't know what kind of description you want here, it's socrates1024's script (https://bitcointalk.org/index.php?topic=193281.msg3315031#msg3315031), rest is in bitcoin spec. I want to use BitcoinJ, blockchain.info and RPC client to trade BTC/ALT and asking for opinion, that's all. Thank you for not judging me, I'll also refrain from doing so. Title: Re: Alt chains and atomic transfers Post by: agorism on January 11, 2014, 08:41:11 PM Thank you very much for building the example code kactech. Stuff like this is really helpful.
Perhaps I could get advice on how to experiment with scripting? I have been using bitcoind and pybitcointools. I have been having trouble getting the transactions to Eligius, which is the only mining pool that accepts custom transactions? Since broadcasting custom transactions is such a pain, maybe we can come up with a way to do all the custom transactions off-chain? And then we broadcast the final standard transaction normally? Once a transaction has been signed, it is easy for either of them to verify that the transaction is valid. Instead of broadcasting it, they can make an standard transaction that does the same thing, and broadcast that instead. Only in the case where one person disappears do you have to broadcast the custom transaction? I am currently trying to write code to implement cross-chain transactions, as well as trustless distributed gambling. I use bitmessage so that users can talk to one another. bitmessage is a proof-of-work based communication system where you can't even tell which addresses are talking to each other. The code is a big mess right now. https://github.com/zack-bitcoin/python-bitcoin-library Title: Re: Alt chains and atomic transfers Post by: cryptotechguy on February 13, 2014, 04:01:03 AM Since broadcasting custom transactions is such a pain, maybe we can come up with a way to do all the custom transactions off-chain? And then we broadcast the final standard transaction normally? How can we be sure that funds haven't been spend? The way I see it, both Alice and Bob need to verify that transactions are buried under several blocks thus considered valid, and then Alice can proceed with revealing secret x and triggering both transactions. Title: Re: Alt chains and atomic transfers Post by: TierNolan on February 13, 2014, 09:29:02 AM The system in this thread doesn't work at the moment due to transaction malleability.
Title: Re: Alt chains and atomic transfers Post by: cryptotechguy on February 14, 2014, 12:18:40 AM The system in this thread doesn't work at the moment due to transaction malleability. Yeah, but the idea presented later (and here: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) is not compromised and is a great one. Has anyone tried implementing it in any fashion? Title: Re: Alt chains and atomic transfers Post by: kactech on February 14, 2014, 07:39:47 AM The system in this thread doesn't work at the moment due to transaction malleability. Yeah, but the idea presented later (and here: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) is not compromised and is a great one. Has anyone tried implementing it in any fashion? Tx2(the contract) can be invalidated by Tx1(the payment) mutant, if 'B' won't cooperate with 'A' to resolve this issue 'A' will loose his coins. Title: Re: Alt chains and atomic transfers Post by: kactech on February 14, 2014, 07:49:37 AM Thank you very much for building the example code kactech. Stuff like this is really helpful. Hi, bail-in on the blockchain is fundamental here, now way to make it offline.Perhaps I could get advice on how to experiment with scripting? I have been using bitcoind and pybitcointools. I have been having trouble getting the transactions to Eligius, which is the only mining pool that accepts custom transactions? Since broadcasting custom transactions is such a pain, maybe we can come up with a way to do all the custom transactions off-chain? And then we broadcast the final standard transaction normally? Once a transaction has been signed, it is easy for either of them to verify that the transaction is valid. Instead of broadcasting it, they can make an standard transaction that does the same thing, and broadcast that instead. Only in the case where one person disappears do you have to broadcast the custom transaction? I am currently trying to write code to implement cross-chain transactions, as well as trustless distributed gambling. I use bitmessage so that users can talk to one another. bitmessage is a proof-of-work based communication system where you can't even tell which addresses are talking to each other. The code is a big mess right now. https://github.com/zack-bitcoin/python-bitcoin-library Have you tried https://blockchain.info/pushtx for custom transactions? Title: Re: Alt chains and atomic transfers Post by: k99 on March 22, 2014, 03:11:37 AM The system in this thread doesn't work at the moment due to transaction malleability. I think the extortion problem due malleability could be solved in the way that Bob pays in a deposit so there is a balanced risk situation. So both pay in the same amount, Alice payment move over to Bob and he gets his deposit back after the trade: Tx1: input 1: x BTC from Alice input 2: x BTC from Bob output: if clause: MultiSig <Alice, Bob> else clause: 2x BTC to Bobs address and redeemer needs to solve H(x) Tx2_Refund: input: 2x BTC from Tx1 (MultiSig <Alice, Bob> ) output 1: x BTC to Alice output 2: x BTC to Bob timelock: 24 h Same happens on the altcoin side. Tx1 is first signed by Bob then sent to Alice and then she signs her input. Malleability could also happen without bad intention, but the refund tx is only needed if the normal trade does not get completed. In that case both have an incentive to agree to a new refund tx with the changed TxID from the now published Tx1 to get back their payments. At least Bob has no extortion advantage compared to Alice. One other open problem is that when the price changes to the disadvantage of Alice, she might consider to not redeem the Altcoin and therefore cancel the trade. So both trades will be refunded, but Alice has the advantage to decide to cancel the trade if the price moves against her interests. That form of scam seems to be quite a problem on localbitcoin or bitcoin.de. With shorter time-windows that could be mitigated. The fact that Alice is the redeemer who reveals the secret and therefore control if the trade will executed or be canceled (refund), might need additional protection (offer fees, reputation system?). Automated trades with micropayments might be another option (break down a bigger volume to smaller chunks). Title: Re: Alt chains and atomic transfers Post by: TierNolan on March 23, 2014, 12:51:39 PM I created a thread (https://bitcointalk.org/index.php?topic=515370.0) about a similar method. You method is simpler.
I think the extortion problem due malleability could be solved in the way that Bob pays in a deposit so there is a balanced risk situation. So both pay in the same amount, Alice payment move over to Bob and he gets his deposit back after the trade: Tx1: input 1: x BTC from Alice input 2: x BTC from Bob output: if clause: MultiSig <Alice, Bob> else clause: 2x BTC to Bobs address and redeemer needs to solve H(x) <snip> Tx1 is first signed by Bob then sent to Alice and then she signs her input. Alice selects a transaction output of value x that she owns as input 1 and sends it to Bob. Bob creates the transaction, as above, signs it and sends it back to Alice. Alice signs the transaction and gets it hash. Alice creates the refund transaction. Input 2x from TX1 signed by Alice, locked 24 hours in the future Output x to Bob x to Alice Bob signs and sends it back to Alice. Alice now has a refund transaction. She is then supposed to publish TX1. If Alice stops here, then she can hold Bob's money to ransom. Worst case, she gets her money back after 24 hours. OTOH, her hand is weakened, since her x BTC is tied up in the process. Quote The fact that Alice is the redeemer who reveals the secret and therefore control if the trade will executed or be canceled (refund), might need additional protection (offer fees, reputation system?). Automated trades with micropayments might be another option (break down a bigger volume to smaller chunks). This might be a general solution, especially with malleability. If you have traded with someone before, you are willing to trust them for up to 1% of the trade or 1% of the total trades that you have done with that person before. Title: Re: Alt chains and atomic transfers Post by: gigq on March 31, 2014, 06:13:58 AM Malleability could also happen without bad intention, but the refund tx is only needed if the normal trade does not get completed. In that case both have an incentive to agree to a new refund tx with the changed TxID from the now published Tx1 to get back their payments. At least Bob has no extortion advantage compared to Alice. There is still the issue of mutual destruction though. You may ask why that would happen but I can imagine if a decentralized exchange like this really took off it might be worth it for the existing exchanges to mess with users of the decentralized exchange by locking up their funds at random. But I agree with transaction malleability out there this seems like the only possible solution. Title: Re: Alt chains and atomic transfers Post by: TierNolan on April 29, 2014, 12:01:30 PM [edit]
Doesn't work Bob can broadcast TX4 and then wait for the timeout before spending it. By broadcasting TX4, TX3 is spend, so Alice can't get a refund. [/edit] [edit2] Works after all, TX3 can be tweaked. [/edit2] I am trying to get the standard transactions adjusted and ideally, the change should be minimal. One suggestion is to add the following OP_HASH160 OP_EQUAL_VERIFY [Standard Transaction] This means that you can protect a standard transaction with a hash password. I think that this is enough to make things work. Bob selects x TX0: Bob sends w BTC to [2 of Alice-pub-key1 and Bob-pub-key1] TX1: from TX0 to [x for Hash(x) & Alice-pub-key2] TX2: from TX0 to [Bob-pub-key2], timelocked 48 hours Bob signs TX1 and sends TX1-half-signed and TX2 (unsigned) to Alice. Alice signs both and returns the signed version of TX2 to Bob. Bob has TX2 signed and Alice has TX1 signed. Alice extracts Hash(x) from TX1 TX3: Alice sends v ATC to [2 of Alice-pub-key3 and Bob-pub-key3] and <delta> to [x for hash(x) & 2 of Bob-pub-key3 and Alice-pub-key3] Note: TX3 has 2 outputs TX4: from TX3/0 and TX3/1 to [Bob-pub-key4] TX5: from TX3/0 to [Alice-pub-key4], timelocked 24 hours Alice signs TX4 and sends TX4-half-signed and TX5 (unsigned) to Bob. Bob signs both and returns the signed version of TX5 to Alice. Alice has TX5 signed and Bob has TX4 signed. Knowledge of each party Nothing is broadcast until the above is completed. Bob has fully signed versions of TX0 - initial bail-in TX2 - timelocked refund of TX0 (48 hours) TX4 - Bob cashes in altcoin Alice has fully signed versions of TX1: Alice cashes in bitcoin TX3: Alice bail in TX5: timelocked refund (24 hours) Release protocol Note: 1) Bob broadcasts TX0 (Bob bails-in) If the protocol ends here, Bob can use TX2 to get his money back after 48 hours 2) Alice broadcast TX3 (Alice bails-in) If the protocol ends here, Bob can use TX2 to get his money back after 48 hours and Alice can use TX5 to get her money back after 24 hours 3) Bob broadcasts TX4 (Bob commits transaction) He spends v ATC to another of his addresses. He can only do this by providing x, since TX3/1 requires x for hash(x). This commits the transaction. Bob has Alice's money, so she might as well perform step 4. She can't get her original money back anyway. 4) Alice completes the transaction Alice broadcasts TX1. She spends w BTC to another of her addresses. Title: Re: Alt chains and atomic transfers Post by: TierNolan on May 01, 2014, 08:30:57 AM I created a new BIP draft relating to this.
https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki The latest version allows transfers between chains as long as 1 of them supports non-standard transactions. This means that fast testnet <-> mainnet transfers would be possible. Testnet would have to have the longer timeout, since it is the network that supports non-standard transactions. Everything on Bitcoin would standard. I am going to look into creating a simple client/server this week-end to verify that the scheme actually works. What is cool about this is that it means that a BTC <-> altcoin trading system would only require that the altcoin accepts the non-standard transactions template. It should be much easier to convince an altcoin dev to make the change than updating the Bitcoin reference client's rules (though hopefully, they will too). Title: Re: Alt chains and atomic transfers Post by: elroy69 on June 09, 2014, 11:28:59 PM TierNolan,
Really great work on this. Any luck with the simple client/server? Did it work as expected. Have you discussed this with the people like Adam Back pushing the SideChain changes, so that they can include this? I created a new BIP draft relating to this. https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki The latest version allows transfers between chains as long as 1 of them supports non-standard transactions. This means that fast testnet <-> mainnet transfers would be possible. Testnet would have to have the longer timeout, since it is the network that supports non-standard transactions. Everything on Bitcoin would standard. I am going to look into creating a simple client/server this week-end to verify that the scheme actually works. What is cool about this is that it means that a BTC <-> altcoin trading system would only require that the altcoin accepts the non-standard transactions template. It should be much easier to convince an altcoin dev to make the change than updating the Bitcoin reference client's rules (though hopefully, they will too). Title: Re: Alt chains and atomic transfers Post by: TierNolan on June 18, 2014, 04:21:09 PM TierNolan, Really great work on this. Any luck with the simple client/server? Did it work as expected. Have you discussed this with the people like Adam Back pushing the SideChain changes, so that they can include this? Shortage of free time. Getting all the encryption right isn't that easy :), but I have the transactions working, as long as no cheating is required. I still need to add checking for fraud and the refund transactions. One point of good news from the dev list is that they are relaxing some of the restrictions on standard transactions. See this (http://sourceforge.net/p/bitcoin/mailman/message/32473035/) post. As long as the transaction uses P2SH, non-standard transactions will be accepted by the network. At the cost of some extra complexity in creating transactions, almost all non-standard transactions will be possible. The remaining limit is 520 bytes and 15 signature operations, but that is not a major restriction (and is just to protect against DOS attacks). Title: Re: Alt chains and atomic transfers Post by: zccoin on June 28, 2014, 10:07:10 PM TierNolan, Really great work on this. Any luck with the simple client/server? Did it work as expected. Have you discussed this with the people like Adam Back pushing the SideChain changes, so that they can include this? Shortage of free time. Getting all the encryption right isn't that easy :), but I have the transactions working, as long as no cheating is required. I still need to add checking for fraud and the refund transactions. One point of good news from the dev list is that they are relaxing some of the restrictions on standard transactions. See this (http://sourceforge.net/p/bitcoin/mailman/message/32473035/) post. As long as the transaction uses P2SH, non-standard transactions will be accepted by the network. At the cost of some extra complexity in creating transactions, almost all non-standard transactions will be possible. The remaining limit is 520 bytes and 15 signature operations, but that is not a major restriction (and is just to protect against DOS attacks). We are ZCC dev, and would love to adopt the necessary changes for cross chain trade. Will keep an eye on this thread and thanks for your wonderful work. Title: Re: Alt chains and atomic transfers Post by: xHire on February 03, 2015, 01:31:02 PM This is very valueable thread and I'm glad of all the work TierNolan and others have done! :) To contribute to it a little bit, I worked out both proposed protocols. The first one (http://www.coincer.org/2015/01/27/atomic-protocol-1/) with a formalisation, proof and demo implementation. However, the second protocol (http://www.coincer.org/2015/02/03/atomic-protocol-2/) isn't atomic so my post isn't as elaborated as the first one (on the other hand, the derived one in TierNolan's BIP has the issue fixed, but I didn't study it in much detail).
BTW, I'm implementing this as a part of a bigger project---decentralised cryptocurrency exchange (Coincer, for short ;)). And I already have a working atomic protocol that uses only standard transaction scripts. So after years this stuff is definitely moving forwards! :D Title: Re: Alt chains and atomic transfers Post by: Adriano on February 03, 2015, 09:30:55 PM This is very valueable thread and I'm glad of all the work TierNolan and others have done! :) To contribute to it a little bit, I worked out both proposed protocols. The first one (http://www.coincer.org/2015/01/27/atomic-protocol-1/) with a formalisation, proof and demo implementation. However, the second protocol (http://www.coincer.org/2015/02/03/atomic-protocol-2/) isn't atomic so my post isn't as elaborated as the first one (on the other hand, the derived one in TierNolan's BIP has the issue fixed, but I didn't study it in much detail). BTW, I'm implementing this as a part of a bigger project---decentralised cryptocurrency exchange (Coincer, for short ;)). And I already have a working atomic protocol that uses only standard transaction scripts. So after years this stuff is definitely moving forwards! :D Thanks for your work... I will try to find some time to check it too. Adriano Title: Re: Alt chains and atomic transfers Post by: swapcoiner on February 05, 2015, 06:40:15 PM Is this the way, assets are also created and shared?
Title: Re: Alt chains and atomic transfers Post by: TPTB_need_war on December 21, 2015, 11:11:40 PM Maybe the following was summarized upthread, but I want to jot down my high-level conceptualization (ignoring scripting details).
Also I will offer an improvement (perhaps it was not already mentioned upthread?). One of the parties of the trade generates Hash(x), keeps x secret, and generates the first transaction. The other party follows after first transaction is irreversibly confirmed. Both parties issue transactions on their respective block chains to other party, giving the other party the right to accept the funds if they reveal x. The first party who knows x reveals first to accept the funds. The other party then knows x to accept the funds. If x is never revealed the transactions are refunded/canceled. The block chains never have to monitor each other, i.e. miners don't need any knowledge about another block chain. The parties monitor the block chains and issue the transactions. The major flaw in this protocol is it can be jammed because the refund comes much later. An improvement would be to have both parties issue their transactions at the same time. They can both generate a Hash(x) and Hash(y), so that accepting funds requires both x and y. So then they only have to set the refund period to the duration to irreversibly confirm both transactions. For anti-jamming, the UTXO could be required to have been of a certain CoinDaysDestroyed (i.e. some age × coin value). This would reduce jamming resources at the cost of eliminating fast retrading. This protocol isn't really suitable for day trading any way due to its slow confirmation. Title: Re: Alt chains and atomic transfers Post by: coins101 on February 27, 2017, 03:45:10 PM Looking to implement this.
Is there an agreed hash function for different alts to use? Title: Re: Alt chains and atomic transfers Post by: xHire on February 27, 2017, 04:04:18 PM Looking to implement this. As far as I know, there isn’t any set of pairs of usable hash functions for each two altcoins. Nonetheless, before you dive in, you need to make sure that the altcoin is tx-malleability-free or that it has BIP65 deployed. If you are interested, I have an optimised script you might use.Is there an agreed hash function for different alts to use? Be prepared to run into many hurdles if you’re going to implement this kind of exchange from scratch yourself (I mean, the script is the least issue and you can use an already invented one—but there is much more around it that you need to take care of). Title: Re: Alt chains and atomic transfers Post by: FreeTrade on April 29, 2017, 09:12:26 AM Looking to implement this. Is there an agreed hash function for different alts to use? Is this going into Helium? Title: Re: Alt chains and atomic transfers Post by: d5000 on May 01, 2017, 03:51:47 PM I am very interested in this technology and would like to get an overview of the "state of the art" on it if someone knows (if someone has resources, links etc. welcome). Is there another newer thread? I saw this one popping up but it's really old and outdated.
I know there is already a working implementation (AT) (https://ciyam.org/at/at_atomic.html) since 2015, but it's little used and not Bitcoin script compatible (and I don't know if its well peer reviewed or there are any vulnerabilities). And there is MercuryEx (https://bitcointalk.org/index.php?topic=946174.0) but it seems to have stalled in alpha state (probably because it needs malleability fixed). Now with Segwit in LTC and other alts it should work in theory. Title: Re: Alt chains and atomic transfers Post by: a7594li on May 13, 2017, 02:13:03 AM A lot of people do that，But I hope you do better，
I'm also interested |