A lot of people do that，But I hope you do better，
I'm also interested
Topic: Alt chains and atomic transfers (Read 27381 times)
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) 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 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.
I know there is already a working implementation (AT) 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 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.
Looking to implement this.
Is there an agreed hash function for different alts to use?
Is there an agreed hash function for different alts to use?
Is this going into Helium?
Looking to implement this.
Is there an agreed hash function for different alts to use?
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).
Looking to implement this.
Is there an agreed hash function for different alts to use?
Is there an agreed hash function for different alts to use?
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.
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.
Is this the way, assets are also created and shared?
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 with a formalisation, proof and demo implementation. However, the second protocol 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! 
To contribute to it a little bit, I worked out both proposed protocols. The first one with a formalisation, proof and demo implementation. However, the second protocol 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! Thanks for your work... I will try to find some time to check it too.
Adriano
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 with a formalisation, proof and demo implementation. However, the second protocol 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!
To contribute to it a little bit, I worked out both proposed protocols. The first one with a formalisation, proof and demo implementation. However, the second protocol 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! 
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?
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 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.
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?
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 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).
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?
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).
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).
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).
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).
[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 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.
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
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.
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.
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.
I created a thread about a similar method. You method is simpler.
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.
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.
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
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)
Tx1 is first signed by Bob then sent to Alice and then she signs her input.
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
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)
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).
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.
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
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)
Tx2_Refund:
input: 2x BTC from Tx1 (MultiSig
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).
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
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?
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.
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?
Jump to: