CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 27, 2014, 02:03:09 AM Last edit: October 28, 2014, 02:31:44 PM by CIYAM |
|
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).
|
|
|
|
Velkro
Legendary
Offline
Activity: 2296
Merit: 1014
|
|
October 27, 2014, 04:58:48 AM |
|
Well thats generous bounty out there. Thank you for supporting whole bitcoin community this way
|
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
October 28, 2014, 08: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".
|
|
|
|
vbcs
Full Member
Offline
Activity: 137
Merit: 100
AT - Automated Transactions - CIYAM Developer
|
|
October 28, 2014, 08:20:59 AM Last edit: October 28, 2014, 09:18:17 AM by vbcs |
|
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! 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
|
1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 28, 2014, 08: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.
|
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 28, 2014, 02:30:59 PM |
|
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).
|
|
|
|
dzimbeck
Legendary
Offline
Activity: 2412
Merit: 1044
|
|
October 28, 2014, 03:15:18 PM |
|
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)
|
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 28, 2014, 03:18:03 PM |
|
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.
|
|
|
|
dzimbeck
Legendary
Offline
Activity: 2412
Merit: 1044
|
|
October 28, 2014, 03:28:51 PM |
|
malleability applies to any transaction, not just multisig. Because the miners can just slightly alter the tx without invalidating the script.
|
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 28, 2014, 03:32:29 PM |
|
malleability applies to any transaction, not just multisig. Because the miners can just slightly alter the tx without invalidating the script.
You don't understand AT at all - it is not a Bitcoin script. Please re-read TierNolan's post and review the AT use case and then *think again*. All you can do with *malleability* is *change the sig* and that doesn't affect AT (as the atomic use case does not depend upon that at all). For that to be an issue you'd need AT to *care about the sig* and *it simply doesn't* (the refund address is hard-coded and is not dependent upon the tx sig at all). Fundamentally TierNolan's approach requires B to sign A's *refund* (and vice-versa) but AT's approach *does not* (so although the atomic AT was *based* upon TierNolan's idea it is not the same as it).
|
|
|
|
dzimbeck
Legendary
Offline
Activity: 2412
Merit: 1044
|
|
October 28, 2014, 03:39:33 PM |
|
I thought AT you were abbreviating Atomic transactions. Can you please send me a link?
|
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 28, 2014, 03:40:38 PM |
|
I thought AT you were abbreviating Atomic transactions. Can you please send me a link?
You can see the entire docco from here: http://ciyam.org/atand for the "atomic" use case in particular here: http://ciyam.org/at/at_atomic.html
|
|
|
|
dzimbeck
Legendary
Offline
Activity: 2412
Merit: 1044
|
|
October 28, 2014, 03:51:42 PM |
|
Ahh sorry I should have noticed some of the earlier comments. This is fantastic work. Congratulations. The only way I thought this was possible before was applying a malleability patch/some sort of fork or using refunds.
And this is being implemented in Quora?
|
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 28, 2014, 03:56:16 PM |
|
And this is being implemented in Quora?
The Qora implementation will be happening very soon. We might first prove the atomic use case just using some testnets though.
|
|
|
|
vbcs
Full Member
Offline
Activity: 137
Merit: 100
AT - Automated Transactions - CIYAM Developer
|
|
October 28, 2014, 04:04:48 PM |
|
There is also a working testnet nxt version using the old API. You can see some info here http://5.196.1.215:5876/ATs.html (it is just for testing purposes atm) and the testnet needs to be updated to comply with the new API
|
1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
October 28, 2014, 08:12:13 PM |
|
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. Well, this makes my previous post irrelevant ( https://bitcointalk.org/index.php?topic=826263.msg9354368#msg9354368). On "atomicity" - a successful eclipse attack would lead to the money belonging to one of the parties only (it will get double amount while the counterparty will get none). This shows that the proposed scheme is not atomic.
|
|
|
|
Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
|
October 29, 2014, 08:54:49 AM |
|
Are you planning to look into whether AT works or not (as proposed) or is the debatable use of a single word your only concern? Debatable use of a single word is my only concern because it (un)intentionally confuses people who know what "atomic" means. I'm not going to read AT paper because of a much weaker definition of "atomic". Codius already implemented such the scheme and AT doesn't offer anything above that.
|
|
|
|
wizzardTim
Legendary
Offline
Activity: 1708
Merit: 1000
Reality is stranger than fiction
|
|
October 29, 2014, 02:42:58 PM |
|
Did anyone express interest yet? e.g. an altcoin dev?
|
Behold the Tangle Mysteries! Dare to know It's truth.
- Excerpt from the IOTA Sacred Texts Vol. I
|
|
|
CIYAM (OP)
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
October 29, 2014, 02:44:40 PM |
|
Did anyone express interest yet? e.g. an altcoin dev?
Yes - I have been contacted privately by a couple but no-one seems to have committed themselves to this yet - so you are welcome to join in if you are keen.
|
|
|
|
wizzardTim
Legendary
Offline
Activity: 1708
Merit: 1000
Reality is stranger than fiction
|
|
October 29, 2014, 02:51:43 PM |
|
Did anyone express interest yet? e.g. an altcoin dev?
Yes - I have been contacted privately by a couple but no-one seems to have committed themselves to this yet - so you are welcome to join in if you are keen. I am keen on programming (Software Engineer) but I'm afraid I do not have the needed time available..
|
Behold the Tangle Mysteries! Dare to know It's truth.
- Excerpt from the IOTA Sacred Texts Vol. I
|
|
|
|