Take a look at his sig and you'll know why (I have already given up trying to report them - the mods will actually just reduce your *accuracy* for reporting them - spamming rubbish into every single topic is *perfectly okay* with this forum unfortunately).

For those wondering I have read the "side chains" PDF and there is absolutely no reason why they can't use AT (so AT will have the benefit of being able to be portable across *all chains* which no other current "Turing complete" proposal is so far promising).

I noted also that the "atomic cross chain transfer" that they document follows *the exact the same process* as the AT that will be provided shortly by CIYAM for this purpose (which might be helpful for those that might be skeptical that this "use case" can be achieved).

Thanks and to be quite clear CIYAM is not interested in IPOs or the likes and AT is available for every blockchain that wants to use it absolutely *free of charge*. Those that pay attention to the details will notice it is MIT licensed just like Bitcoin is.

Not only is there a bounty set up to get an open source version of the AT API that works on a Bitcoin clone but I have also offered my personal assistance with those who are interested to achieve the goal of performing atomic cross-chain transfers between blockchains (and I won't be accepting any assets or alt coins for such assistance).

To make it even easier the actual AT machine code to *do* the atomic cross-chain transfer is being constructed in the bounty topic: https://bitcointalk.org/index.php?topic=826263.msg9311209#msg9311209 (I expect it'll be completed well before anyone has an AT API ready to test it).

In order to show clear progress of the atomic cross-chain transfer AT itself (and to ensure that no-one has any unfair advantage) I will be posting pieces of the machine code as it as being developed.

So here is the first portion which does the all important "refund" if too much time has elapsed (note that the @refund_minutes value would be part of the "initial data" when the AT is created):

Note that the bounty has been upped to 10 BTC now and that the AT API document has now been published (https://bitcointalk.org/index.php?topic=826263.msg9310030#msg9310030).

All current AT documentation can of course be found here: http://ciyam.org/at

Bounty has been upped to 10 BTC and the AT API document has now been released: http://ciyam.org/at/at_api.html.

Work on creating the actual atomic cross-chain transfer AT has already begun (see next post) and will be completed after the API has been thoroughly reviewed and tested.

Devs should note that the four use cases documented do not use the portable functions listed in the AT API (those use "experimental" functions and should only be considered as illustrative examples for writing ATs).

@criptix - it really isn't very polite to post an "ad" in someone else's topic (your sig is noted).

And something that relies upon "gateways" is in no way *trustless* so we are not talking "apples and apples" here.

So the AT project is offering a bounty here: https://bitcointalk.org/index.php?topic=826263.0

We already have interest from other projects such as this: https://bitcointalk.org/index.php?topic=827804.msg9300029#msg9300029

and even Gavin has expressed some interest in what AT is about: https://bitcointalk.org/index.php?topic=822100.msg9235731#msg9235731

If people want to help then I'd suggest you put the bounty thread into your sig - you will get *no reward* apart from perhaps *changing the world* (and if you do put this link in your sig please don't post crap and don't expect any payment from me).

Do I profit? No - I have actually provided the bounty (and will be increasing it tomorrow). What I want to see happen is "atomic cross-chain transfers" and I am happy for any clone to *be the first* to achieve this (can even be *closed source* provided that the AT and AT API parts are open source).

So the AT API document is nearly complete (just getting some final reviewing).

Again - the bounty will be increased once I release the docco (in the next 24 hours) so those interested should be *watching this space*.

With the announcement of *side-chains* from Adam Beck and others I would guess a lot of alts now need to seriously consider their future. AT will give them a reason to exist (if they weren't just created for the purpose of *pumping and dumping*) with the ability to to "atomic cross-chain transfers" to other alts.

This is *evolution* at work!

Okay - well that makes a bit more sense.

I don't have time to look into it more now but hope I've helped at least let you explain your system a bit better.

But how does the client *get the valid signatures* of the servers in the first place?

(this is the attack vector most likely to be used)

But again *how are you securing this*?

My guess is via https and the CA system (how else?).

There have been many recent attacks made upon https and the CA system so I would be very wary about promoting the safety of it.

I'd suggest that you look into "stealth addresses" and what APIs people are providing to help with that.

Again - I don't think you have *stopped* the attack vectors but I do wish you the best of luck with this.

My personal opinion is that you should consider "stealth" and how that might be able to be used with your idea.

Again you are not handling MITM attacks.

The client may *think* they have 4 valid servers - but they may be actually all be MITM attacks.

How do you *verify* the servers?

The issue is going to be MITM attacks.

You are going to have to rely upon the CA system and OpenSSL (and you might have noticed the various serious issues with that in recent months).

You want to be looking into Stealth Addresses (that way you can publish a public key but nothing can be traced to it).

With only 6 hex digits it would be way too easy for someone to "mine" an equivalent "address" so I don't see how this can work at all.

IMO QR codes are the best approach by far.

Whilst I have zero interest in speculating on coins (and I don't have any Qora) the statement made by Vasilis is accurate (i.e. that he thinks the Qora code is nicely written and is not a clone of Nxt).

Also note that I have no interest in looking at their code myself as I am not a Java programmer anyway (and I am far too busy on other work).

I think that your article reads reasonably well - also note that I will be publishing the AT *API* specification tomorrow (and raising the bounty - if you guys are able to add to that bounty or - better still - try and collect it then that would be great).

The AT API spec combined with this http://ciyam.org/at/at_script.html should make the job of integrating AT with a Bitcoin clone fairly straight forward (if I wasn't so busy working on other things I'd give it a go myself).

The actual atomic cross-chain transfer AT will be provided by CIYAM either later this month or early next month but in short it will work in the same manner as the published nLockTime approach for Bitcoin (but rather than needing nLockTime to be implemented in both "mainnets" you will just need AT to be supported in both).

The new AT will be somewhat like the Dormant Funds Transfer (this is the refund part) but each AT will also contain a SHA256 hash value (whoever publishes their AT first is the one who knows the "secret"). Provided a message "that is the secret" is received by the AT (checked by hashing and comparing to the hard-coded expected hash) and that this occurs before the refund has happened then the AT will store the secret (making it now publicly visible in the ATs state) and of course transfer the funds.

The other AT on the other block chain then just needs to be sent the same secret in order for it to do the other part (again before it refunds). The AT will most likely be designed for re-use as well (so each trader would have their own).

As in the nLockTime approach the refund times need to have a reasonably large difference (say 1 hour for person going 1st and 3 hours for person going second).

Note that to send "messages" for Bitcoin clones OP_RETURN would be used.