Quote from: CryptKeeper on May 19, 2015, 06:20:49 AM

Quote from: CIYAM on May 18, 2015, 02:44:07 PM

It is possible to hard-code values into ATs but understand as the Initiator and Responder would need different values we'd have to have two ACCT ATs rather than just one (at the moment the code is the same regardless of which role).

The next main focus for the AT project is going to be UI so we will consider how we can make the workflow and UX better as we proceed.

With the upcoming release of Nxt (1.5.x) there comes a feature named "pay-on-reveal-secret", which I think is the key component of ACCT. Could you adopt the AT code to create a Nxt-compatible secret?

It would be huge to have ACCT between Qora, Burst and Nxt!

I also asked the lead Nxt dev about it, here is his answer (from the Nxt forum):

Quote from: Jean-Luc on May 18, 2015, 12:26:40 PM

Quote from: CryptKeeper on May 18, 2015, 08:28:10 AM

Great, so theoretically we could do Atomic CrossChain Transfers between Nxt, Qora and Burst? What must be done to achieve this?

This is the description of the algorithm:
http://upcoder.com/11/atomic-cross-chain-exchange/
and from the 1.5.0e changelog:
Pay on reveal secret is supported as a voting model for phased transactions.
When this voting model is used, the phased transaction must include the
hash of a secret chosen by the sender (up to 100 bytes long), and an approval
transaction for it is only accepted if it includes the secret that results in
this hash. It does not matter who the sender of the approval transaction is,
unless a whitelist is also defined. Supported hash functions currently are
sha256, ripemd160, and sha256 followed by ripemd160. The codes to specify them
as parameters are available from the getConstants API.

It is required that the other blockchain supports at least one of the above hash functions for the hash of the secret. Instead of timeout and refund transactions, we use phasing finish height, by which the secret revealing transaction must be submitted and accepted in the blockchain, otherwise the reserved unconfirmed balance is refunded. The deadline parameter can also be used to make sure a transaction is not included in the blockchain after this deadline has expired. Somebody should look into whether this can be made to fit with the algorithm they are using. If it can, maybe even a plugin to make it user friendly can be created?

Why NXT is just not using AT like QORA and BURST is doing ? Easier workaround IMO