Alt chains and atomic transfers

[TierNolan]

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 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).

[1714037325]

1714037325

[1714037325]

1714037325

[1714037325]

1714037325

[1714037325]

1714037325

[zccoin]

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 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.

[xHire]

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!

[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!

Thanks for your work... I will try to find some time to check it too.

Adriano

[swapcoiner]

Is this the way, assets are also created and shared?

[TPTB_need_war]

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.

[coins101]

Looking to implement this.

Is there an agreed hash function for different alts to use?

[xHire]

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.

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).

[FreeTrade]

Looking to implement this.

Is there an agreed hash function for different alts to use?

Is this going into Helium?

[d5000]

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.

[a7594li]

A lot of people do that，But I hope you do better，

I'm also interested