AT can be used to anonymize inter-blockchain transfers (who would have thought?)

[CIYAM]

One member of the Burst (a coin that works on HDD capacity rather than PoW or PoS) community asked me whether AT could be used to help anonymize transfers and at first I thought this was simply not possible as AT has *no secrets*.

I am glad I then thought about this again - and suddenly I realised that the "atomic cross-chain transfer" (http://ciyam.org/at/at_atomic.html) use case could be changed ever so slightly to do something I had not thought that AT could ever do (help provide anonymity).

Normally an ACCT (atomic cross-chain transfer) would involve putting the same "hash" into two ATs (each residing on a different blockchain) and then sending the secret to unlock both in order to make the transaction take place.

But there is no need for the secret to be "identical" - so here is an example:

one AT is created with the hash 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b hard-coded in it - but the AT on the other blockchain doesn't have this but instead 04d3368f72736ed54c3cb63454eef23c2ecfb1deed27e2a4aa8e442e898fdbf5.

If we were to study both blockchains we can't see any immediate relationship between the two ATs that have been created to do the ACCT but an ACCT can occur nonetheless as those hashes are actually SHA256 hashes of "secret" and "terces" (this is of course a trivial example of how to do this - a more viable version would use something much more complicated than just reversing the secret).

Assuming we had numerous ATs operating across numerous blockchains all doing transfers at around the same time it is pretty clear that the "ultimate decentralised coin mixer" could be created.

[1713586419]

1713586419

[1713586419]

1713586419

[1713586419]

1713586419

[Vrontis]

This is brilliant !!!

[wizzardTim]

We have reached to the point of true anonymity!

So, the first truly anonymous transaction in cryptocurrencies, will take place between qora and burst?

[CIYAM]

So, the first truly anonymous transaction in cryptocurrencies, will take place between qora and burst?

Understand that if there is only one atomic transfer then it would be obvious but if we managed to get hundreds (or thousands) then I think we have created the starting point of a new type of mixer that runs across blockchains.

[CIYAM]

Interestingly enough if Ethereum has the same Turing complete capabilities then Ethereum can also be the biggest "money laundering application in the world" (perhaps something they won't want to advertise too much).

 

[Vrontis]

So, the first truly anonymous transaction in cryptocurrencies, will take place between qora and burst?

Understand that if there is only one atomic transfer then it would be obvious but if we managed to get hundreds (or thousands) then I think we have created the starting point of a new type of mixer that runs across blockchains.

If there is only one atomic transfer the scenario to freeze this transfer until a second atomic transfer appears could stand?

[CIYAM]

If there is only one atomic transfer the scenario to freeze this transfer until a second atomic transfer appears could stand?

Yes - the basic premise of the atomic transfer does not change - all we have done is add a function to the *shared secret* to make that secret now impossible to trace across different blockchains.

[687_2]

One member of the Burst (a coin that works on HDD capacity rather than PoW or PoS) community asked me whether AT could be used to help anonymize transfers and at first I thought this was simply not possible as AT has *no secrets*.

I am glad I then thought about this again - and suddenly I realised that the "atomic cross-chain transfer" (http://ciyam.org/at/at_atomic.html) use case could be changed ever so slightly to do something I had not thought that AT could ever do (help provide anonymity).

Normally an ACCT (atomic cross-chain transfer) would involve putting the same "hash" into two ATs (each residing on a different blockchain) and then sending the secret to unlock both in order to make the transaction take place.

But there is no need for the secret to be "identical" - so here is an example:

one AT is created with the hash 2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b hard-coded in it - but the AT on the other blockchain doesn't have this but instead 04d3368f72736ed54c3cb63454eef23c2ecfb1deed27e2a4aa8e442e898fdbf5.

If we were to study both blockchains we can't see any immediate relationship between the two ATs that have been created to do the ACCT but an ACCT can occur nonetheless as those hashes are actually SHA256 hashes of "secret" and "terces" (this is of course a trivial example of how to do this - a more viable version would use something much more complicated than just reversing the secret).

Assuming we had numerous ATs operating across numerous blockchains all doing transfers at around the same time it is pretty clear that the "ultimate decentralised coin mixer" could be created.

How difficult would it be to create a stand-alone application that performs this function?

[CIYAM]

How difficult would it be to create a stand-alone application that performs this function?

I don't believe it would be very difficult as it just needs to work out the two hashes, publish an AT and then send the other hash to another person (presumably via GPG).

[vbcs]

I will modify the acct use case tomorrow, so we can start testing it

[Soros Shorts]

Is this function similar to a salt, or is it something more sophisticated?

[burstcoin]

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.

A possible way to allow different hashes would be to use ATs that check sha256(salt + sha256(secret)) with a different salt for each AT, since the creator can reveal sha256(secret) to the 2nd party before the ATs are created to prove that the same secret will release both ATs, however since the same secret would still be used for both ATs, there would still be a clear link.

It seems to me that this would require one party to be trusted, in which case it offers no advantage over sending ordinary transactions.

EDIT: After thinking more about this, I think this might be doable without links with an extra release condition, such as the following scheme:
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.

[vbcs]

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.

A possible way to allow different hashes would be to use ATs that check sha256(salt + sha256(secret)) with a different salt for each AT, since the creator can reveal sha256(secret) to the 2nd party before the ATs are created to prove that the same secret will release both ATs, however since the same secret would still be used for both ATs, there would still be a clear link.

It seems to me that this would require one party to be trusted, in which case it offers no advantage over sending ordinary transactions.

EDIT: After thinking more about this, I think this might be doable without links with an extra release condition, such as the following scheme:
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.

You might be party 1 and party 2 at the same time.. and you want to "hide" your funds

[vbcs]

I am just quoting burstcoin's post also here.

Any method of mixing across multiple chains using ACCTs can also be done on a single chain to obscure things. Amounts can also be broken down by having one or both sides making more than one AT. There doesn't even have to be a corresponding 2nd AT. Someone could just make one side that releases to another address they control, and release it after waiting a while to simulate coins being swapped.

[jamoes]

Quoting my own post from the other thread:

I've thought about it more, and I think ATs could also be used to create CoinJoin transactions in a trustless manner without requiring any communication channel between users other than the blockchain itself..

The setup: there are two users, Alice and Bob, each have 1000 coins in their two public accounts: account_a and account_b. They both want to do a transaction such that their funds are transferred to anon_account_a and anon_account_b, while keeping it impossible for any observing parties to determine who owns which of the anon accounts. To this this, they could create a special AT:

1) Alice and Bob would each send the AT a message from anon_account_a and anon_account_b. The message would indicate to the AT where to send the funds to after it was fully funded.

2) Next, Alice and Bob would each send their 1000 coins to the AT. If either one fails to send, the AT would just issue a refund after a certain amount of time.

3) After the AT is fully funded, it would disperse the funds to anon_account_a and anon_account_b. Any outside observer would be unable to determine who owns which address.

This technique could easily be expanded upon to any number of people. The only downside to having more accounts participating in the transaction, is an increased risk that someone doesn't fund the AT in step 2.

One major drawback to this whole approach is that the anon_accounts will need to be funded somehow in order to send the message to the AT in step 1. This presents a challenge if you're trying to fund the account for the first time.

Am I missing anything, or is this a viable use-case for Automatic Transactions?

[haploid23]

Can you dumb it down for us simpletons such as myself? This sounds interesting, but too technical.

[vbcs]

Quoting my own post from the other thread:

I've thought about it more, and I think ATs could also be used to create CoinJoin transactions in a trustless manner without requiring any communication channel between users other than the blockchain itself..

The setup: there are two users, Alice and Bob, each have 1000 coins in their two public accounts: account_a and account_b. They both want to do a transaction such that their funds are transferred to anon_account_a and anon_account_b, while keeping it impossible for any observing parties to determine who owns which of the anon accounts. To this this, they could create a special AT:

1) Alice and Bob would each send the AT a message from anon_account_a and anon_account_b. The message would indicate to the AT where to send the funds to after it was fully funded.

2) Next, Alice and Bob would each send their 1000 coins to the AT. If either one fails to send, the AT would just issue a refund after a certain amount of time.

3) After the AT is fully funded, it would disperse the funds to anon_account_a and anon_account_b. Any outside observer would be unable to determine who owns which address.

This technique could easily be expanded upon to any number of people. The only downside to having more accounts participating in the transaction, is an increased risk that someone doesn't fund the AT in step 2.

One major drawback to this whole approach is that the anon_accounts will need to be funded somehow in order to send the message to the AT in step 1. This presents a challenge if you're trying to fund the account for the first time.

Am I missing anything, or is this a viable use-case for Automatic Transactions?

I am not sure this is feasible if i understood correctly your logic. The message that will contain the information ( for example the anon_account_x ) is visible to all the observers. ATs do not have a private key to be able to decrypt messages, so the messages you send to the AT are plain text. Also in the case you mentioned with 2 parties you might not be sure ( if you could somehow indicate the AT where to send the funds ) which anon address belongs to which public address but still you know that for example anon_address_a belongs either to public account_a or b .

[jamoes]

Quoting my own post from the other thread:

I've thought about it more, and I think ATs could also be used to create CoinJoin transactions in a trustless manner without requiring any communication channel between users other than the blockchain itself..

The setup: there are two users, Alice and Bob, each have 1000 coins in their two public accounts: account_a and account_b. They both want to do a transaction such that their funds are transferred to anon_account_a and anon_account_b, while keeping it impossible for any observing parties to determine who owns which of the anon accounts. To this this, they could create a special AT:

1) Alice and Bob would each send the AT a message from anon_account_a and anon_account_b. The message would indicate to the AT where to send the funds to after it was fully funded.

2) Next, Alice and Bob would each send their 1000 coins to the AT. If either one fails to send, the AT would just issue a refund after a certain amount of time.

3) After the AT is fully funded, it would disperse the funds to anon_account_a and anon_account_b. Any outside observer would be unable to determine who owns which address.

This technique could easily be expanded upon to any number of people. The only downside to having more accounts participating in the transaction, is an increased risk that someone doesn't fund the AT in step 2.

One major drawback to this whole approach is that the anon_accounts will need to be funded somehow in order to send the message to the AT in step 1. This presents a challenge if you're trying to fund the account for the first time.

Am I missing anything, or is this a viable use-case for Automatic Transactions?

I am not sure this is feasible if i understood correctly your logic. The message that will contain the information ( for example the anon_account_x ) is visible to all the observers. ATs do not have a private key to be able to decrypt messages, so the messages you send to the AT are plain text. Also in the case you mentioned with 2 parties you might not be sure ( if you could somehow indicate the AT where to send the funds ) which anon address belongs to which public address but still you know that for example anon_address_a belongs either to public account_a or b .

I don't think it matters that the messages are public. The main goal trying to be accomplished is unlinkability between the anon address and the regular address. As a comparison, CoinJoin doesn't encrypt the destination outputs, it just provides unlinkability between the input addresses and the output addresses.

I also don't think it matters that the AT wouldn't be able to know which anon account belongs with which regular account (in fact, that's the goal). In the scheme I described, each public account would send exactly 1000 coins to the AT, and the AT would then send exactly 1000 coins to each of the anonymous accounts that it knows about. Because all the amounts are the same, the AT does not need any knowledge of which account corresponds to which. The users themselves would need to verify that their anonymous account is indeed stored in the AT before sending their funds.

[PirateBlock]

i think if there are a lot of different chains and a lot of movement that this could be one of if not the best coin washing method to date.

[CIYAM]

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

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.