The legendary stuff is not important - and I'm not trying to bully you - I just think it is wrong for you to be hassling the OP who has done nothing but try and help people who have been the victim of blockchain.info's incredible incompetence.

You need to calm down and sort your situation out with blockchain.info as they are the only ones that can refund you the BTC. As much as it might be hard right now being patient is going to help you more than not being patient is.

It is irrelevant whether or not you think your life is on the line (for 50 BTC you should never have stored in an online wallet in the first place).

The OP does not work for blockchain.info nor have access to their DB - so what exactly do you think he can do for you now?

You are lucky that the funds were returned at all - now you expect that he should be working for you to get back your funds from blockchain.info (for nothing)?

Sheesh!

I suggest you don't hassle him and you instead hassle blockchain.info who are the obvious problem in all of this (as clearly they did not even bother testing their wallet changes which is why this fiasco has happened).

This initial idea at getting the atomic cross-chain transfer to use different hashes is flawed in that it is no longer trustless, however, @burstcoin worked out a way that it can in fact be made to work.

For those interested in the technical details: https://bitcointalk.org/index.php?topic=893271.msg9843577#msg9843577

I was thinking of creating a macro assembler (but have too much else on my plate) - this looks like some pretty nice work!

You are most welcome to give it a whirl - I am too busy with other things to code this myself unfortunately but I will be happy to review your code if you do decide to create this AT.

In thinking about the idea of local mixing I think you'd create an AT that takes say X addresses/accounts in the form of messages that are sent to it (initially no funds used beyond the minimum fee) and these addresses/accounts would be stored in the ATs data storage area.

Once it has 10 such addresses it will now wait for 10 x Y funds to be sent to it (noting that each sender would need to send the amount plus fee and those funds would of course need to be sent from a different address/account to those addresses/accounts that were used to send the messages in the first place).

If it didn't receive 10 amounts by a timeout then it would refund but assuming it does receive all amounts then it would then send Y (minus required fee for steps) to each account it had stored thus making it impossible to work out who has actually sent funds to who (assuming there are no other ways to trace the addresses/accounts used).

This could be a perpetual local mixer AT as after it has send the funds out it could reset itself in order to be able to start over.

I have now updated the API docco to add the following:

OR_A_with_B               0x0129 EXT_FUN           sets A to A | B
OR_B_with_A               0x012a EXT_FUN           sets B to B | A
AND_A_with_B              0x012b EXT_FUN           sets A to A & B
AND_B_with_A              0x012c EXT_FUN           sets B to B & A
XOR_A_with_B              0x012d EXT_FUN           sets A to A ^ B
XOR_B_with_A              0x012e EXT_FUN           sets B to B ^ A

Let's make them 0x0129 and 0x012a respectively (I'll update the spec shortly).


Unfortunately identifying "accounts" doesn't make much sense when it comes to Bitcoin clones (which is why no API functions to actually do this were created). So this would also be best provided with a "platform specific" API function though.

Having secrets being 16 bytes rather than 32 bytes is not a security concern IMO (so I think that would be the simplest portable solution).

Yes - so perhaps we should add XOR_A_with_B and XOR_B_with_A to the API (as these will be very easy to implement).


I think sending two messages could be problematic as it opens up a potential attack vector where others might try to inject a message *between the two*.



The point of the limitations is to be able to write "portable" ATs (that will work the same on on all platforms). The function number ranges 0x500..0x5ff and 0x600..0x6ff are reserved for writing "platform specific" API functions so that would be the appropriate way to implement a different kind of Message_From_Tx function (such as perhaps Message_From_Tx_In_A_To_AB).

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


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.

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

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.

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

 

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.

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.

My gut feeling is that the mixing approach I've outlined using "atomic cross-chain transfer" is going to be "the only method" for anonymizing but I can see that if we get AT on numerous blockchains then it could become the ultimate "mixing machine".

BTW - props should be for @vbcs and @burstcoin for getting AT integrated with Burst (I only created the specifications and C++ prototype).

After a question that was raised about AT in the Burst (a blockchain based upon HDD storage that should be going mainnet with AT before xmas) topic I have realised that AT can be used to help anonymize the transfer of funds.

Although it wouldn't be practical until there are hundreds (if not thousands) of ATs running - the idea is that the "atomic cross-chain transfer" AT could be easily modified so that instead of both ATs having the same hash they each have a different hash that is a different function of the "shared secret".

For example let's say that the secret is: "secret"

The typical atomic cross-chain transfer would have the SHA256 value of this (2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b) hard-coded into both ATs.

But let's consider that our 2nd AT actually has the hash of "terces" hardcoded in it (04d3368f72736ed54c3cb63454eef23c2ecfb1deed27e2a4aa8e442e898fdbf5) instead of the same hash as the first (this second hash would of course have to be securely transferred between the two parties concerned when the first party creates its AT).

Until "secret" has been published there is no way that "terces" can be published so we have the same behaviour as before but just a manual step now in between (i.e. reverse the secret then send this to the 2nd AT). Of course reversing the secret would be rather to easy to discover so instead one would use a complex function involving transformations and rounds but the idea is the same.

Thus once the secret has been published on the one chain it should be very hard to actually trace which funds went where between the two blockchains (assuming similar ATs are running on both blockchains at around the same time).

Thanks for the interest in AT and hopefully it will be a core feature that a lot of other very useful things can be built on top of.

As AT cannot keep secrets I think a very simple version of what you are wanting is not really going to be possible, however, I can think of one approach that might make it very hard for anyone to "follow the funds" and that is to make a variation of the current "atomic cross-chain transfer" use case (http://ciyam.org/at/at_atomic.html) in which the hash published in the initial AT is not the same as what is used in the other AT (which is created on another blockchain).

The idea would be that the second AT would have a hash that is a function of the first hash (rather than just the secret itself - you'd therefore have to calculate the relevant hash to feed the second AT offlineoffchain). Although when there are very few ATs in existence it would still be easy to track the funds when there are thousands or more of such ATs it would become very hard to work out which transaction matches which (thus starting to approach the plausible deny-ability of CoinJoin assuming the function you used is sufficiently complex enough to not be discovered).

You seriously don't think people have a fundamental right to anonymity?

Although I am not anonymous here I certainly support anyone and everyone's right to be anonymous here or whether else they like.

If you think that people only want to be anonymous because they "have something to hide" then I suggest you need to "think harder".