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

[CIYAM]

I am keen on programming (Software Engineer) but I'm afraid I do not have the needed time available..

Perhaps have a quick look at this: http://ciyam.org/at/at_script.html to gauge how difficult the task would be.

[1713511384]

1713511384

[1713511384]

1713511384

[1713511384]

1713511384

[wizzardTim]

I am keen on programming (Software Engineer) but I'm afraid I do not have the needed time available..

Perhaps have a quick look at this: http://ciyam.org/at/at_script.html to gauge how difficult the task would be.

Ok thanks 

[CIYAM]

Bounty has been upped to 20 BTC now.

Saffron has announced their interest to implement AT but not until next year so there is still a great opportunity for a talented dev to pick up this bounty before the end of this year!

[rlh]

Hey CIYAM, I would be very interested in attempting this bounty but I need a bit more info.  Specifically, do you have a simple (as can be) document that outlines how to get AT connected to BTC?

I understand what you are doing, but I haven't dug deep enough into the connecting end portion of BTC to know how to use this.

Bottom line, is there a barebones document that goes from setup to "Hello World" within AT and BTC?  I think something along those lines could help expedite the creation of services.

[CIYAM]

Hey CIYAM, I would be very interested in attempting this bounty but I need a bit more info.  Specifically, do you have a simple (as can be) document that outlines how to get AT connected to BTC?

Okay - so the main document to help with the AT machine itself is http://ciyam.org/at/at.html and the C++ prototype is here: http://ciyam.org/at/_at.cpp.html.

For the Bitcoin "script" side of things I have come up with this: http://ciyam.org/at/at_script.html.

The other key document is the AT API which is here: http://ciyam.org/at/at_api.html.

Again I am happy to help explain things to interested parties and yourself or others are welcome to send me a PM to get my Skype id if you'd like to be able to chat with me directly.

Understand that the bounty is not there so that "I do all the work" so you are only going to get answers to relevant questions (rather than *code*). If I had the spare time I'd code this myself but I am working 14 hours per day currently on the CIYAM project (and not being so young I do need to get at least 8 hours of sleep and some exercise every day).

[dansmith]

I'm somewhat confused about this thread's title. The title makes it seem like all one has to do is to fork bitcoin/litecoin and start a new blockchain with AT bolted on on top of it. But reading the comments made me doubt that.
Is it correct that in order to claim the bounty, one not only has to come up with the code for atomic cross-chain transfer but also convince the existing coin's miners/nodes to adopt the changes?

[CIYAM]

Actually - it is about as simple as that - but it must be a mainnet that isn't so weak it just gets destroyed due to an ASIC attack or the like overnight (just because that would simply not look good and I do reserve the right to decide who gets the bounty).

Understand that the "atomic cross-chain transfer" needs to be done *using AT* (so you can't use any other method to do it) and also that the AT and AT-API source code created to accomplish this must be made open source (the rest of the coin's source code isn't really of any concern to me).

The point of the bounty is basically to get open source code that can be "easily dropped into any existing Bitcoin clone" for using AT (thus providing an easy to implement alternative to Ethereum or Codius).

If you want to do it with a complete crap coin then perhaps discuss it with me via PM (as maybe I can link things up with a better coin and the reward could be shared as I have been approached by some clones that have a decent rep but their devs are not likely to work on this until next year).

[dexX7]

I started to run the samples and this is very interesting.

I can imagine to run the scripts and use the block chain as data source, and I can also imagine how "passive" data could be integrated, say for example it is observed that "A sends x BTC to B", thus function xyz is triggered (...), but I'm not really sure how AT would be able to do something else than "watch and observe"? A scheme that involves script and the revealing of secrets, as described by TierNolan, might somehow be combined with this, but let me rephrase:

The cross-chain document explicitly mentions "refunding the AT's balance", so I'm wondering: is it intended to trade "virtual" balances which represent Bitcoin within the scripting environment or real Bitcoin (or some-else-coin)? If it's the later, I'd be very curious and would be happy to hear more about it.

For the Bitcoin "script" side of things I have come up with this ...

To clarify: you are not talking about Bitcoin anymore, but Bitcoin + op_checkstate, correct?

[CIYAM]

To clarify: you are not talking about Bitcoin anymore, but Bitcoin + op_checkstate, correct?

Correct - it is only possible for AT to work with the new op code (but at least only the one is required).

AT can indeed "spend" its inputs as because they are OP_CHECKSTATE scripts such as this:

Code:

INPUT:
<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE (original 100)

Thus there is no signature required to be verified with OP_CHECKSTATE only the actual "state" of the AT VM needs to match each peers own calculated state (and outputs that are created by the AT are verified to match the same set of outputs that each peer determined).

[dexX7]

Code:

<state> hash160(1xxATxxYptzC5a7p9obc2SLMPS148G2Qxg) OP_CHECKSTATE (original 100)

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?

[CIYAM]

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.

[LuaPod]

Perhaps I should have waited to post : https://bitcointalk.org/index.php?topic=852917.msg9489290#msg9489290

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?

[CIYAM]

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.

[dexX7]

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

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 (...)".

[CIYAM]

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.

[CIYAM]

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

[bitspill]

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?

Code:

struct function_data
{
   function_data( )
   {
      loop = false;
      offset = 0;
   }

   bool loop;
   size_t offset;

   vector< int64_t > data;
};

map< int32_t, function_data > g_function_data;

int64_t get_function_data( int32_t func_num )
{
   if( func_num == g_increment_func )
   {
      if( g_first_call )
         g_first_call = false;
      else
      {
         for( map< int32_t, function_data >::iterator i = g_function_data.begin( ); i != g_function_data.end( ); ++i )
         {
            if( ++( i->second.offset ) >= i->second.data.size( ) )
            {
               if( i->second.loop )
                  i->second.offset = 0;
               else
                  --( i->second.offset );
            }
         }
      }
   }

   int64_t rc = g_function_data[ func_num ].data[ g_function_data[ func_num ].offset ];

   return rc;
}

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

[CIYAM]

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?

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

[bitspill]

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?

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 that uses hard-coded pseudo API data rather than making real API calls).

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

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

Code:

int32_t g_code_pages = 1;
int32_t g_data_pages = 1;

int32_t g_call_stack_pages = 1;
int32_t g_user_stack_pages = 1;

const int64_t c_default_balance = 100;

int64_t g_val = 0;
int64_t g_val1 = 0;

int64_t g_balance = c_default_balance;

bool g_first_call = true;

int32_t g_increment_func = 0;

[CIYAM]

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

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