Topic: 20 BTC bounty for first AT *atomic cross-chain transfer* with Script clone - page 2. (Read 20174 times)

Great! I hope that this will become a function on every next alt-coin

The first blockchain to go live with AT is Burst (https://bitcointalksearch.org/topic/m.9910950) so to qualify for this script implementation of AT bounty the actual atomic cross-chain transfer can be done using Burst (although I am guessing that Qora will also be live before the end of the year).

I understand that the Qora AT implementation is now quite close to completion and Qora will be going open source in the next few days (AT will most likely not make the initial open source release but will be included in a follow up as some final tweaks and testing still needs to be performed).

There will be another non-Bitcoin clone that will be running live with AT very soon but we are still waiting to see if anyone is going to try and claim the 40 BTC possible before the end of the year for getting a Bitcoin clone to implement AT and do an atomic cross-chain transfer with Qora (or the other yet to be announced coin).

Will be keeping an eye on this thread.  Hopefully there are some significant breakthroughs and hopping between coins and blockchains without using any centralised exchanges becomes the preferred method of trading.  I'm a little surprised there isn't more excitement about the potential of all this.

We may also be *announced* at the next Bitcoin conference in Dubai (December 11th from memory) but that will be up to one of the teams that is looking into AT.

(unfortunately we don't have oodles of BTC to spend on marketing like the competition does)

Great, thanks!  Yes, Qora tends to disappear and then magically appear weeks.  I hate to hear he's sick, bht that would explain his extended absense.

No problem although I am not directly involved with the Qora coding (also I believe that qora has been sick recently) - my understanding is that the development is going well and we should be ready to test in a few weeks.

Thanks, CIYAM for keeping this going.  If you wouldn't mind me askig, could you post and update one the Qora thread regarding the AT integration?  What percent are you guys complete?  Are we getting close to a release and, if no, can you give a reasonable ETA?

I hate to derail this topic but I did want to get your attention.

Thanks to one of the devs working on implementing AT in another Java coin it was brought to our attention that our "indirect" and "indirect indexed" addressing ops needed two complimentary ops (so that fetching and storing via this approach is supported).

I have now updated the AT specification (http://ciyam.org/at/at.html) and the C++ prototype (http://ciyam.org/at/_at.cpp.html) to provide the new op codes.

(relevant op codes are IND_DAT, IDX_DAT, SET_IND and SET_IDX)

Note that this doesn't affect the atomic cross-chain transfer use-case as it doesn't use any of those op codes.

Yup - I use "g_" as a prefix for global variables and of course global variables should not be in a real version of AT (although some constants such as max. number of steps per AT and max. number of ATs per block would be expected to be provided).

Ok, I was thinking it has something to do with testing.

That goes for all the g_XX, g_balance, etc as well, correct?

The function_data stuff is only for testing purposes (it would not be included in any "real implementation"). Any real implementation would need to implement the AT API instead (http://ciyam.org/at/at_api.html).

Sorry for the confusion (understand that the C++ code published is a "prototype" that is useful for testing ATs and uses hard-coded pseudo API data rather than making real API calls).

I've been working through this project however I just don't understand what the function_data struct and it's usage, could you clarify:

What is function_data storing, more so what is the intention of the data vector?

Where does a value get written to function_data.data?

Why does get_function_data only iterate g_function_data if it's not the first call?




Edit: Before I get mistaken for an idiot let me clarify it is currently 5am

With the announcement that Counterparty made in regards to Ethereum I am being asked whether AT is still a contender.

Firstly let's be clear that Counterparty do not have Ethereum on *mainnet* now and most likely won't have it on *mainnet* for at least a few months.

Secondly AT has been designed to be much more *low-level* which should make it much quicker to implement (especially as we have already created unit tests for all of the instruction codes except the API ones and we will be creating unit tests for those also).

As an added incentive - I am going to offer another 20 BTC if a Bitcoin clone can achieve the goal of this bounty before the end of 2014 (which would make AT the *first mainnet* Turing complete transaction system for blockchains).

Unfortunately if an AT can't receive and send funds then its uses are very limited. It could still be used to store some information and perform some basic tests (such as checking a hashed secret) but I think it really comes into its own when it can act as an escrow with the funds sent to it being under its control.

Thanks, this implies an altcoin context. I was in particular interested in the question, if TA could be used with Bitcoin directly where OP_CHECKSTATE might be expressed by something else. Anything that doesn't require moving Bitcoin seems very doable. Code, state, ... could easily be published on chain and markers or flags (in OP_RETURN or embedded in bare multisig/P2SH for longer messages) could be used to trigger "now evaluate the next instruction, this point marks a new step, therefore the block of this transaction represents the current context (...)".

The OP clearly points out that the bounty is for using *AT* to achieve the transfer (i.e. it is not and never was a general bounty for achieving a so-called "atomic cross-chain transfer").

So unless you are planning on implementing AT in node.js then clearly it wouldn't even be considered and even if you were going to write the whole AT machine in node.js you'd also have to implement Bitcoin Script in node.js to qualify. I would estimate that task taking some months (for an expert programmer who understands Bitcoin inside and out) - but go ahead and try that if you're still keen.

Perhaps I should have waited to post : https://bitcointalksearch.org/topic/m.9489290

Though my idea was generating two private keys from many private parts generated on different sides and shared in certain steps so that they both reveal each others private keys at the same time. (while leaving proof that the transaction occured and both addresses in fact were derived from shared keyparts.)
A few public keys from the transaction along with signed transaction logs from all three parties would be added to the public ledger (for each node that can process the type of request ie: BTC - LTC | LTC - DOGE)


Since private keys are essentially large numbers there shouldn't be any problems using different ECC curves in generating keypairs from another curve when being used in split key generation.

Though the keys would appear different the math involved would never change the fact that we are just adding, subtracting, multiplying, and dividing large numbers on scalar charts. I don't believe there would be issues with prime number curves either.
Perhaps to add a type of miner to the system it could use a private key that is partially known with a range of numbers that could have been subtracted from it to give it a sort of difficulty and require the miners to find the missing keypart solution.

o.o I just read that stuff and my chart is almost exactly what that thing is.

Would a lite node.js p2p version of this win the bounty?

So the idea behind OP_CHECKSTATE is that the AT is run at that point (no need for puzzles as running the AT *is the puzzle*).

Each block that has AT txs included will have at least one OP_CHECKSTATE output per AT executed (which will identify the hash of the AT state and the amount of funds it has left to keep running).

A peer can verify the block by running each AT and making sure that they come up with the exact same outputs (i.e. same state hash and same amount of funds left to keep running) as AT has been designed to be deterministic.

If a state hash does not match or one of the outputs does not match then the block is considered invalid.

So what exactly does OP_CHECKSTATE?

Might it be possible to construct a transaction puzzle for this purpose where it can be solved by one who is able to provide certain information that should be in possession, if TA evaluated in this-or-that way?