Topic: 20 BTC bounty for first AT *atomic cross-chain transfer* with Script clone - page 4. (Read 20174 times)
October 28, 2014, 10:28:51 AM
malleability applies to any transaction, not just multisig. Because the miners can just slightly alter the tx without invalidating the script.
October 28, 2014, 10:18:03 AM
How is malleability not an issue? TX2 is a refund of TX1... thus TX2 spends the hash of the raw TX1 (The TXID). That txid in TX1 can be changed by the miners thus invalidating the refund holding the funds permanently hostage. So TX2 is invalidated and the counterparty doesnt sign again. The funds are permanently stuck. If this is somehow not the case, can you please explain why? I'm familiar with atomic trades and always assumed that was their issue (unilateral hostage commitment)
The TierNolan approach uses a multi-sig address (which is what the malleability issues he describes are all about).
The AT solution does not need or use this (there is *no* multisig address involved at all). You might want to read the AT use case more carefully to understand it.
October 28, 2014, 10:15:18 AM
How is malleability not an issue? TX2 is a refund of TX1... thus TX2 spends the hash of the raw TX1 (The TXID). That txid in TX1 can be changed by the miners thus invalidating the refund holding the funds permanently hostage. So TX2 is invalidated and the counterparty doesnt sign again. The funds are permanently stuck. If this is somehow not the case, can you please explain why? I'm familiar with atomic trades and always assumed that was their issue (unilateral hostage commitment)
October 28, 2014, 09:30:59 AM
Just to make things clear "atomic" does not imply ACID (http://en.wikipedia.org/wiki/ACID) as that *word* it is only *one part of the normal idea for RDMBS txs" (there are *four* words in the acronym for a reason).
The AT "atomic" transfer does satisfy the "atomic" requirement that a transfer should be *all or nothing* but of course this is a blockchain environment not a single server so some "edge cases" (clearly described in http://ciyam.org/at/at_atomic.html) do exist.
Transaction *malleability* (as mentioned by TierNolan) is not an issue when using AT as it doesn't not have "multisig addresses" but of course if the creator of the first AT sends the tx with the "secret" to the other chain and then "loses all connectivity to the internet for the timeout period" then they will end up losing their funds (same thing could happen with any other method of transfer if you don't decide to use a "trusted server").
This is the same problem that TierNolan's script would have also and compared to the problem of an *exchange collapsing* is IMO not an issue (provided the timeouts for refunds are sensible - say 24 and 12 hours per TierNolan's suggestion).
People demanding "perfection" should for a start realise that no PC is *perfect* and that the *internet is not perfect either* (both of these facts are very obvious when you use a cheap Chinese laptop from within China as my PC often crashes for no good reason and the internet here is always being blocked).
The AT "atomic" transfer does satisfy the "atomic" requirement that a transfer should be *all or nothing* but of course this is a blockchain environment not a single server so some "edge cases" (clearly described in http://ciyam.org/at/at_atomic.html) do exist.
Transaction *malleability* (as mentioned by TierNolan) is not an issue when using AT as it doesn't not have "multisig addresses" but of course if the creator of the first AT sends the tx with the "secret" to the other chain and then "loses all connectivity to the internet for the timeout period" then they will end up losing their funds (same thing could happen with any other method of transfer if you don't decide to use a "trusted server").
This is the same problem that TierNolan's script would have also and compared to the problem of an *exchange collapsing* is IMO not an issue (provided the timeouts for refunds are sensible - say 24 and 12 hours per TierNolan's suggestion).
People demanding "perfection" should for a start realise that no PC is *perfect* and that the *internet is not perfect either* (both of these facts are very obvious when you use a cheap Chinese laptop from within China as my PC often crashes for no good reason and the internet here is always being blocked).
October 28, 2014, 03:33:42 AM
Great to see that the AT completed (next step is of course testing).
I have now uploaded the atomic use case http://ciyam.org/at/at_atomic.html.
I have now uploaded the atomic use case http://ciyam.org/at/at_atomic.html.
October 28, 2014, 03:20:59 AM
The AT program which will enable atomic cross-chain transaction is ready. The machine code is less than 256 bytes, so you can see the power the AT can give to the underlying blockchain is huge and that is just a use case. When we have up and running 2 blockchains running AT the first atomic cross-chain tx will take place. So stay tuned.
Here is the full document with the description, the variables used, the script assembly, the assembly code and the machine code. Enjoy!
Here is the full document with the description, the variables used, the script assembly, the assembly code and the machine code. Enjoy!
Code:
Use Case: Atomic Cross-Chain Transfer
-------------------------------------
An AT that enables an atomic cross-chain transfer to be executed by creating two separate instances of itself
on two seperate blockchains. When constructing the first instance a 32 byte secret needs to be "hashed" using
SHA256 and stored in the first 32 bytes of "initial data" followed by another 32 bytes for the address of the
other party, and then the number of minutes to wait until refunding the AT's balance back to its creator.
The initial creator would then wait for the other party to create a matching AT (with a significantly smaller
number of minutes for refund). The hash values would need to be identical. Once the initiator has seen enough
confirmations of the other AT then they will send the secret to the other AT as a message. This AT will first
copy this message into its data storage and then check if when hashed it matches the initial data values that
were provided when it was created. If they match then the funds are sent to the address stored in the initial
data.
Finally the creator of the second AT can now work out from checking their AT's state what the secret is. They
would then send a message to the originally created AT instance with the same secret and it would pay them so
the atomic cross-chain transfer will be completed.
Note that if the second party never actually creates their AT then the first party just needs to wait for the
refund to occur. Likewise once the second party has created their AT then if the first party fails to send it
the secret on time then a refund will occur (and the first party will also be refunded). The first party will
need to be careful not to send the secret too close to the deadline otherwise there is the possibility that a
refund will occur in the second AT but the secret will have already been seen in the message tx.
Another concern is possible attacks by "clogging the AT" up with tiny false message txs to try and prevent it
from paying out. This is perhaps best prevented by making sure that the minimum fee for the ATs is well above
anything that would permit such an attack to be economically beneficial.
Variables
---------
@00 ==> @hash_part1
@01 ==> @hash_part2
@02 ==> @hash_part3
@03 ==> @hash_part4
@04 ==> @address_part1
@05 ==> @address_part2
@06 ==> @address_part3
@07 ==> @address_part4
@08 ==> @refund_minutes
@09 ==> @refund_timestamp
@0a ==> @current_timestamp
@0b ==> @secret_part1
@0c ==> @secret_part2
@0d ==> @secret_part3
@0e ==> @secret_part4
@0f ==> @tx_type
@10 ==> @comparator
@11 ==> @secret_temp1
@12 ==> @secret_temp2
@13 ==> @secret_temp3
@14 ==> @secret_temp4
Script Assembly
---------------
if @refund_timestamp not zero goto loop 1e0a0000001c
set @refund_timestamp to AT creation time 35010309000000
add @refund_minutes to @refund_timestamp 370604090000000900000008000000
:loop (0x1c)
set @current_timestamp to block timestamp 3500030a000000
if @current_timestamp >= @refund_timestamp goto refund 210a00000009000000f0
:txloop (0x2d)
store tx after @current_timestamp in A 3504030a000000
check if A is zero and store result to @comparator 35250110000000
if @comparator is zero finish 2610000000
get type for tx in A and store in @tx_type 3505030f000000
if @tx_type is not 0 goto :check_message 1b0f00000012
get timestamp for tx in A and store in @current_timestamp3507030a000000
goto txloop 1a2d000000
:check_message (0x59)
store message of tx in A to B 320903
swap A and B 322801
sha256 of A and store in B 320402
set @secret_temp1 to A1 35000111000000
set @secret_temp2 to A2 35010112000000
set @secret_temp3 to A3 35020113000000
set @secret_temp4 to A4 35030114000000
set A1 to @hash_part1 33100100000000
set A2 to @hash_part2 33110101000000
set A3 to @hash_part3 33120102000000
set A4 to @hash_part4 33130103000000
check A equals to B and store in @comparator 35270110000000
if comparator is not 0 goto :payout 1b100000000b
goto :txloop 1a2d000000
:payout (0xa7)
set @secret_part1 to $secret_temp1 020b00000011000000
set @secret_part2 to $secret_temp2 020c00000012000000
set @secret_part3 to $secret_temp3 020d00000013000000
set @secret_part4 to $secret_temp4 020e00000014000000
set B1 to @address_part1 33160104000000
set B2 to @address_part2 33170105000000
set B3 to @address_part3 33180106000000
set B4 to @address_part4 33190107000000
send all to address in B 320304
finish 28
:refund (0xf0)
set B to address of the AT creator 320b03
send remaining balance to addres in B 320304
finish 28
Assembly Code
-------------
00000000* BNZ $0000000a :0000001c
00000006 FUN @00000009 0x0301
0000000d FUN @00000009 0x0406 $00000009 $00000008
0000001c FUN @0000000a 0x0300
00000023 BGE $0000000a $00000009 :00000013
0000002d FUN @0000000a 0x0304
00000034 FUN @00000010 0x0125
0000003b FIZ @00000010
00000040 FUN @0000000f 0x0305
00000047 BZR $0000000f :00000059
0000004d FUN @0000000a 0x0307
00000054 JMP :0000002d
00000059 FUN 0x0309
0000005c FUN 0x0128
0000005f FUN 0x0204
00000062 FUN @00000011 0x0100
00000069 FUN @00000012 0x0101
00000070 FUN @00000013 0x0102
00000077 FUN @00000014 0x0103
0000007e FUN 0x0110 $00000000
00000085 FUN 0x0111 $00000001
0000008c FUN 0x0112 $00000002
00000093 FUN 0x0113 $00000003
0000009a FUN @00000010 0x0127
000000a1 BZR $00000010 :000000ac
000000a7 JMP :0000002d
000000ac SET @0000000b $00000011
000000b5 SET @0000000c $00000012
000000be SET @0000000d $00000013
000000c7 SET @0000000e $00000014
000000d0 FUN 0x0116 $00000004
000000d7 FUN 0x0117 $00000005
000000de FUN 0x0118 $00000006
000000e5 FUN 0x0119 $00000007
000000ec FUN 0x0403
000000ef FIN
000000f0 FUN 0x030b
000000f3 FUN 0x0403
000000f6 FIN
Machine Code
------------
1e0a0000001c350103090000003706040900000009000000080000003500030a000000210a00000009000000f03504030a0000003525011000000026100000003505030f0000001b0f000000123507030a0000001a2d0000003209033228013204023500011100000035010112000000350201130000003503011400000033100100000000331101010000003312010200000033130103000000352701100000001b100000000b1a2d000000020b00000011000000020c00000012000000020d00000013000000020e000000140000003316010400000033170105000000331801060000003319010700000032030428320b0332030428
October 28, 2014, 03:06:29 AM
Yes Nxt-to-Qora would of course be possible (assuming Nxt AT goes to *mainnet*)...
I believe it's a wrong statement. I quote it to reserve a place for "Told Ya So" or "Sorry, I Was Wrong".
October 26, 2014, 11:58:48 PM
Well thats generous bounty out there.
Thank you for supporting whole bitcoin community this way
Thank you for supporting whole bitcoin community this way
October 26, 2014, 09:03:09 PM
You can do atomic trade with regular old bitcoin script. Would that qualify for this bounty?
The bounty is clearly for using an atomic cross-chain transfer *AT* to perform this between Qora and a Bitcoin clone.
And btw the atomic cross-chain transfer AT is actually *based* upon TierNolan's work (so I am of course well aware of its existence).
October 26, 2014, 09:00:55 PM
You can do atomic trade with regular old bitcoin script. Would that qualify for this bounty?
October 26, 2014, 08:41:28 PM
I've put this on Reddit:
https://www.reddit.com/r/Bitcoin/comments/2kf579/10_btc_bounty_for_first_at_atomic_crosschain/
https://www.reddit.com/r/Bitcoin/comments/2kf579/10_btc_bounty_for_first_at_atomic_crosschain/
October 24, 2014, 12:45:33 AM
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):
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):
Code:
Variables
--------
@00 ==> @refund_minutes
@01 ==> @refund_timestamp
@02 ==> @current_timestamp
Script Assembly
---------------
if @refund_timestamp not zero goto loop 1e010000001c
set @refund_timestamp to AT creation time 35010301000000
add @refund_minutes to @refund_timestamp 370604010000000100000000000000
:loop (0x1c)
set @current_timestamp to block timestamp 35000302000000
if @current_timestamp >= @refund_timestamp goto refund 2102000000010000002d
(add NOP padding to insert code later) 7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
:refund (0x50)
set B to address of the AT creator 320b03
send remaining balance to address in B 320304
Assembly Code
-------------
00000000* BNZ $00000001 :0000001c
00000006 FUN @00000001 0x0301
0000000d FUN @00000001 0x0406 $00000001 $00000000
0000001c FUN @00000002 0x0300
00000023 BGE $00000002 $00000001 :00000050
0000002d NOP
00000050 FUN 0x030b
00000053 FUN 0x0403
Machine Code
------------
1e010000001c35010301000000370604010000000100000000000000350003020000002102000000010000002d7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f320b03320304
October 23, 2014, 09:31:03 PM
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).
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).
October 23, 2014, 08:10:51 PM
@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.
And something that relies upon "gateways" is in no way *trustless* so we are not talking "apples and apples" here.
October 23, 2014, 02:15:45 PM
Hi ciyam,
i think this project should interest you.
Atomic is developing a method for cross-blockchain transactions without the need of changing code for the respected coins.
/edit
sorry, didnt meant to hijack your thread for advertisment
i though it was related to your OP
if you have time you should read the documentation, there will be several steps to secure the system is trustless.
i think this project should interest you.
Atomic is developing a method for cross-blockchain transactions without the need of changing code for the respected coins.
/edit
sorry, didnt meant to hijack your thread for advertisment
i though it was related to your OP
if you have time you should read the documentation, there will be several steps to secure the system is trustless.
October 23, 2014, 11:58:15 AM
Sorry I don't use Twitter but feel free to do so yourself.
well it is not needed
October 23, 2014, 09:54:45 AM
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!
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!
October 21, 2014, 04:05:26 AM
I have clarified that the AT and AT API implementation must be open source (the rest of the platform is not my concern) and I will be publishing an AT API specification document at the end of the week.
The "atomic cross-chain transfer" AT itself will be coded by myself and will simply require that the blockchain platform correctly implements AT and the "generic fuctions" for the AT API.
When I publish the AT API I am going to "up the bounty" so those interested might want to "get cracking real soon".
Let's see if we can get an atomic cross-chain transfer to occur between to different blockchain mainnets before the end of the year.
The "atomic cross-chain transfer" AT itself will be coded by myself and will simply require that the blockchain platform correctly implements AT and the "generic fuctions" for the AT API.
When I publish the AT API I am going to "up the bounty" so those interested might want to "get cracking real soon".
Let's see if we can get an atomic cross-chain transfer to occur between to different blockchain mainnets before the end of the year.
October 17, 2014, 10:28:33 PM
I did state that I have the final decision and if I am unable to "see" the Script implementation (for the purposes of getting AT to work on other blockchains) then I would not be very happy.
I don't care if the majority of the coin is "closed-source" but I would be asking for the AT part (at least the Script changes) to be made public so that other blockchains can use AT.
As a general rule I don't support "closed source" and AT itself will always remain open but I am not going to dictate to others what to do with their source code.
I don't care if the majority of the coin is "closed-source" but I would be asking for the AT part (at least the Script changes) to be made public so that other blockchains can use AT.
As a general rule I don't support "closed source" and AT itself will always remain open but I am not going to dictate to others what to do with their source code.
October 17, 2014, 06:15:53 PM
Should go without saying, but on a sad note:
You may want to specify 'open source'.
There seems to be a disgraceful movement towards closed source in some communities.
Regardless, you hold the strings to the purse (and the ultimate decision) but I thought it might bear mentioning.
You may want to specify 'open source'.
There seems to be a disgraceful movement towards closed source in some communities.
Regardless, you hold the strings to the purse (and the ultimate decision) but I thought it might bear mentioning.
Right now Qora is closed source. Of course it will have to be open to Ian in order for him to do the Qora AT work, but I wouldn't assume he'd be against closed source. Ian, what do you say?
If close source projects want to use AT that is of no concern to me (license is MIT not GNU).
If they make their version of AT *incompatible* with others then it would basically just either make it harder or maybe even impossible for that blockchain to participate in atomic cross-chain transfers (which wouldn't be likely to help with making their blockchain very popular).
If they make their version of AT *incompatible* with others then it would basically just either make it harder or maybe even impossible for that blockchain to participate in atomic cross-chain transfers (which wouldn't be likely to help with making their blockchain very popular).
Jump to: