Thread closed due to Nxt shill.
We can start a new topic but self-moderated to keep out the assholes.
Topic: AT can be used to anonymize inter-blockchain transfers (who would have thought?) (Read 3534 times)
December 15, 2014, 12:26:40 PM
December 15, 2014, 12:24:53 PM
Quote
Atomic cross-chain transfer was invented by BTC forum member TierNolan - so I suggest you educate yourself rather than being a *fan boy of Jl777* and I don't think you'll find anyone here is interested in "Supernet".
Teleport technology is doing pretty much more then this.
Looks like you are just another hater because you can't finish your old projects.
This is just a simple use case of the AT. ATs can do much more, and burst implementation is the same as nxts. And nxts devs were not keen to integrate it into mainnet. I hope now with the burst version they will change their mind
December 15, 2014, 12:24:33 PM
So I have reported the Nxt *shill* to the mods.
You can keep being a retard and posting here - I'll just lock the thread as we aren't going to tolerate the Nxt nonsense here (there is a very good reason why AT will never appear on Nxt).
You can keep being a retard and posting here - I'll just lock the thread as we aren't going to tolerate the Nxt nonsense here (there is a very good reason why AT will never appear on Nxt).
December 15, 2014, 12:20:57 PM
Off topic posts will be reported - your last warning.
December 15, 2014, 12:17:17 PM
It always the same thing people just argue how bad he is but if you compare his work to other i can only see envy and hate.
I see - you are in the wrong topic.
This topic is about AT not about Jl777 and his legion of fans.
If you persist with these off topic posts they will be reported.
December 15, 2014, 12:11:38 PM
The first time i heard the idea was from Jl777 with his Teleport technology which is also using cross-chain transfer to achieve anonymity he even wrote the code for this, maybe you should ask and join his team ?
Seriously - I am not interested in anything a guy who doesn't even understand the problems that binary floating point has (and you should be more wary of such people also).
Atomic cross-chain transfer was invented by BTC forum member TierNolan - so I suggest you educate yourself rather than being a *fan boy of Jl777* and I don't think you'll find anyone here is interested in "Supernet".
December 15, 2014, 07:20:10 AM
Code:
start:
FUN @createtime get_Creation_Timestamp
SET @currenttime $createtime
toploop:
FUN A_to_Tx_after_Timestamp $currenttime
FUN @aiszero check_A_Is_Zero
BZR $aiszero :start
FUN @currenttime get_Timestamp_for_Tx_in_A
JMP :toploop
I was thinking of creating a macro assembler (but have too much else on my plate) - this looks like some pretty nice work!
December 15, 2014, 06:35:53 AM
I don't know if someone's made better tools, but I just pushed onto github a basic AT assembler I hacked together somewhere around 1 - 2 weeks ago: https://github.com/BurstProject/ATAssembler/blob/master/src/scala/ATAssembler.scala
No docs on it, but for an example I was using this AT for to stress test API call abuse on testnet is:
No docs on it, but for an example I was using this AT for to stress test API call abuse on testnet is:
Code:
start:
FUN @createtime get_Creation_Timestamp
SET @currenttime $createtime
toploop:
FUN A_to_Tx_after_Timestamp $currenttime
FUN @aiszero check_A_Is_Zero
BZR $aiszero :start
FUN @currenttime get_Timestamp_for_Tx_in_A
JMP :toploop
That is very good, i am coding straight in machine code, but this tool might be very useful for newcomers. Nice work!
December 15, 2014, 05:57:11 AM
I don't know if someone's made better tools, but I just pushed onto github a basic AT assembler I hacked together somewhere around 1 - 2 weeks ago: https://github.com/BurstProject/ATAssembler/blob/master/src/scala/ATAssembler.scala
No docs on it, but for an example I was using this AT for to stress test API call abuse on testnet is:
No docs on it, but for an example I was using this AT for to stress test API call abuse on testnet is:
Code:
start:
FUN @createtime get_Creation_Timestamp
SET @currenttime $createtime
toploop:
FUN A_to_Tx_after_Timestamp $currenttime
FUN @aiszero check_A_Is_Zero
BZR $aiszero :start
FUN @currenttime get_Timestamp_for_Tx_in_A
JMP :toploop
December 15, 2014, 05:14:50 AM
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.
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.
This is exactly what I was (poorly) trying to describe earlier in this thread. This is very similar to a classic CoinJoin transaction, but it is managed entirely by the AT, and doesn't require any other servers or communication channels. Very exciting!
I think you may need to tweak the fees paid in order to manage spam. In the initial step, the AT should charge a setup fee here (more than the minimum fee for a transaction). This will prevent malicious users from spamming the AT with setups that they never intend to fund, which would lock up everyone else's funds. If the AT does not get fully funded before the refund window, then the AT would simply refund these setup fees (as a bonus along with the regular funds) out to those accounts that did fund it. If the AT does get fully funded, then the setup fees will be returned to all users equally. This should offer enough of an incentive for everyone to complete the transaction in order to not forfeit the setup fees they paid.
Can anyone actually code this AT up? I'm going to try it out myself, but I'm just learning about AT.
I can code that AT or I could help you coded if you like, cause CIYAM is very busy with other things
If you want to code it, that would be great! I am making slow progress in my current attempt. I think I'm still missing a few concepts about how the scripts actually work, but I would learn a lot from seeing a working solution.
December 15, 2014, 05:07:28 AM
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.
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.
This is exactly what I was (poorly) trying to describe earlier in this thread. This is very similar to a classic CoinJoin transaction, but it is managed entirely by the AT, and doesn't require any other servers or communication channels. Very exciting!
I think you may need to tweak the fees paid in order to manage spam. In the initial step, the AT should charge a setup fee here (more than the minimum fee for a transaction). This will prevent malicious users from spamming the AT with setups that they never intend to fund, which would lock up everyone else's funds. If the AT does not get fully funded before the refund window, then the AT would simply refund these setup fees (as a bonus along with the regular funds) out to those accounts that did fund it. If the AT does get fully funded, then the setup fees will be returned to all users equally. This should offer enough of an incentive for everyone to complete the transaction in order to not forfeit the setup fees they paid.
Can anyone actually code this AT up? I'm going to try it out myself, but I'm just learning about AT.
I can code that AT or I could help you coded if you like, cause CIYAM is very busy with other things
December 15, 2014, 04:47:04 AM
Can anyone actually code this AT up? I'm going to try it out myself, but I'm just learning about AT.
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.
December 15, 2014, 04:33:11 AM
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.
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.
This is exactly what I was (poorly) trying to describe earlier in this thread. This is very similar to a classic CoinJoin transaction, but it is managed entirely by the AT, and doesn't require any other servers or communication channels. Very exciting!
I think you may need to tweak the fees paid in order to manage spam. In the initial step, the AT should charge a setup fee here (more than the minimum fee for a transaction). This will prevent malicious users from spamming the AT with setups that they never intend to fund, which would lock up everyone else's funds. If the AT does not get fully funded before the refund window, then the AT would simply refund these setup fees (as a bonus along with the regular funds) out to those accounts that did fund it. If the AT does get fully funded, then the setup fees will be returned to all users equally. This should offer enough of an incentive for everyone to complete the transaction in order to not forfeit the setup fees they paid.
Can anyone actually code this AT up? I'm going to try it out myself, but I'm just learning about AT.
December 15, 2014, 04:13:55 AM
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.
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.
December 15, 2014, 02:05:33 AM
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
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
December 15, 2014, 01:58:58 AM
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).
Sounds good, I'll do this right now.Let's make them 0x0129 and 0x012a respectively (I'll update the spec shortly).
That could be avoided by hardcoding an address the messages must be received from. I do agree that it is a less desirable setup, but some may prefer having a higher level of security.
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).
December 15, 2014, 01:49:06 AM
I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.
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).
Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones,
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*.
December 15, 2014, 01:39:52 AM
I was actually intending the + to mean concat, although combining them with a different operator would work also to keep it to 32 bytes, but I think xor would be a better choice than addition anyway, so no 256 bit math operations are required.
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).
Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones,
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*.
although having an extra api call that retrieves messages without the size restriction might be good also so you only have to work within the limitations of the coins you are actually transferring between.
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).
December 15, 2014, 01:30:59 AM
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.
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).
Sending 2 separate messages for the case of having to provide secrets 1 and 3 would be another alternative to handling compatibility with btc clones, although having an extra api call that retrieves messages without the size restriction might be good also so you only have to work within the limitations of the coins you are actually transferring between.
December 15, 2014, 12:51:04 AM
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.
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.
Jump to: