Quote from: burstcoin on December 14, 2014, 07:43:02 PM

I may be missing something, but I don't see how this technique is useful. The point of atomic cross chain transactions is that neither party needs to trust the other one. The 2nd party(who does not have the secret) is willing to create an AT that releases the funds when a secret he does not know is provided because he knows that when it is released he will be able to see and use that secret to release the other AT. If the hashes in the ATs are different, he no longer has a guarantee that his AT being released will provide him with the required information to release the other one.

Agreed - it doesn't work in a trustless manner with the way that I described (although I guess it could still be useful for trusted parties to do mixing).

Quote from: burstcoin on December 14, 2014, 07:43:02 PM

Party1 makes secret1 and secret2.
Party2 makes secret3.
Party1 calculates sha256(secret1) and sends it to Party2.
Party2 combines it with secret3 to calculate sha256(secret3 + sha256(secret1)) and sends it to Party1
Party1 creates an AT that releases on either secret2 or (secret1 with secret3).
Party2 creates an AT that releases on secret1.
Party1 releases Party2's AT using secret1.
If Party1 is honest, Party1 provides Party2 with secret2 which can be used to release Party1's AT without leaving a link to Party2's AT.
If Party1 is dishonest and does not provide secret2, Party2 can still retrieve their funds with secret1 that was used to release their AT along with secret3, however there will be a link left in the blockchain, as both ATs will have received secret1.

I think I get this - so: sha256(secret3 + sha256(secret1)) is what Party1's AT would literally have to have coded (with a test that the result of said calculation == hard-coded value that was passed to Party1 by Party2).

If we added some 256 bit math functions (such as Add_A_To_B which is described in the API docco although it was not expected to be implemented until a later point in time) then we would be able to do this.

In order for "two secrets" to be passed in the one message it'd probably require that secret1 and secret3 would need to be both 16 bytes rather than 32 (I don't think that is really an issue as 16 bytes is still secure enough). The message limitation of 32 bytes is in order for AT to work on Bitcoin clones (messages being implemented as OP_RETURN values).

@haploid23 - in simple terms what we have worked out is that ATs could be used as a sort of cross-blockchain mixer.