20 BTC bounty for first AT *atomic cross-chain transfer* with Script clone

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

[1715188829]

1715188829

[1715188829]

1715188829

[Velkro]

Well thats generous bounty out there.
Thank you for supporting whole bitcoin community this way

[Come-from-Beyond]

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]

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!

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

[CIYAM]

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]

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]

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]

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]

malleability applies to any transaction, not just multisig. Because the miners can just slightly alter the tx without invalidating the script.

[CIYAM]

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]

I thought AT you were abbreviating Atomic transactions. Can you please send me a link?

[CIYAM]

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/at

and for the "atomic" use case in particular here: http://ciyam.org/at/at_atomic.html

[dzimbeck]

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]

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]

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

[Come-from-Beyond]

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]

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]

Did anyone express interest yet? e.g. an altcoin dev?

[CIYAM]

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]

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