Topic: Understanding the Automated Transaction system (AT) - page 3. (Read 5302 times)

To design an AT properly you need some insight knowledge of how AT is designed to work. I will try to give some hints providing an example for the Lottery case that is currently running on burst platform under the name LuckyAT. The post is rather big and I hope is simple enough to understand.

First of all you need to be aware that each AT is actually an account ( with an address without public key and only the AT can access that account's funds ). The way to "communicate" with the AT is through txs. Sending funds to the AT is achieved with a normal tx.

When the Lottery case is deployed for the first time all the variables are initialized to 0. When the lottery starts for the first time you need to initialize some of the variable properly.

( The full code of the Lottery case can be found here: http://pastebin.com/xiDdMzEG

In the Lottery case the following first lines do that:

The first line does a sanity check to see if the variable payout_time is initialized. If it is not, we are setting the variable min_amount (which is the ticket size to participate to the Lottery) and then we set payout_time to the creation timestamp (which is the "timestamp" of the block the Lottery has been deployed).

NOTE: An important concept in ATs are the "timestamps". Timestamps are constructed using the block height and the order of the tx inside the block. If you want for example to fetch the 3rd tx at block height 15885 then the corresponding timestamp will be (15885)(3). The best way to think timestamps is the combination of two integers, one for the block height and one for the tx. The Creation timestamp always uses 0 for the second part f.e (blockHeight)(0).

As stated also in www.ciyam.org/at/at_api.html : "timestamp" does not mean a real timestamp but instead is an artificial timestamp that includes two parts. The first part is a block height (32 bits) with the second part being the number of the transaction if applicable (also 32 bits and zero if not applicable).

The third line is copying payout_time to timestamp.

The 5th line is "labelling" the following code as a branch point where you can "jump" later if needed.
The 6th and 7th lines are initializing payout_balance ( which is the total amount the lottery gathered as winnings for the winner) and tx_info respectively. Tx_info will be used as input to the API call add_Minutes_to_Timestamp along with payout_time and what actually this line does is:
payout_time = payout_time + tx_info
This way the lottery is aware after which block can send the prize to the winner and restart.

The next lines are the following:

Here the lottery fetches the first tx (if any) after the provided timestamp. If there is a tx ( FUN @tx_info check_A_Is_Zero ) then we proceed processing the tx else the AT stops and sets the program counter (pc) to pcs (FIN op code) ( pcs is zero at that point ) .
Setting the pc to 0 makes the AT to start from the first line ( BNZ $payout_time :loop ) the next time it will run.
Also stopping the AT using the FIN op code will "freeze" the AT until the ATs account balance changes ( f.e. until someone sends funds to the AT ). If you don’t want at this point to freeze the AT, you could change the FIN with SLP op code which will make the AT to "sleep" for just one block. ( That does not mean always that the AT will run on next block, as the block might be full with other ATs which have higher priority to run ).

If there is a tx then the Lottery continues with:

Here we get the timestamp of the tx and we check if that timestamp is less than the payout_time timestamp. If it is, we proceed fetching more info for that tx ( :get_info_amount ) else is time to pay the winner the total amount gathered ( JMP :payout ).


Note: The Lucky AT has been programmed to not draw a ticket for funds received from the Creator's Address. This way the creator can send funds to the AT to increase the prize without participating in the draw.

The above piece of code fetches the amount of the tx, the address of the sender and the address of the creator. If these two addresses are equal we jump to :bootstrap (see above note), else we fetch the type of the tx ( 0-> normal tx, 1-> message tx). If the tx is not a message tx, we check if the amount of the tx is equal to the ticket amount. If it is we proceed drawing a ticket for that tx else we proceed on refunding that tx.

Note about the amounts: When you create an AT you set a field called minimum activation account. That amount is the minimum account required to process the tx. All the API calls that return amounts are deducting that minimum activation account ( f.e if minActivationAmount is set to 10 coins and you send a tx of 250 coins, the amount the AT will see is 240).

 Moving forward we see:
 
Here we draw a ticket for that tx and if the ticket is not zero we send a message with the ticket value to the sender of the tx. After that we add the amount of the tx to the payout_balance and we check if the ticket we have draw is greater than the current best_ticket. (Note: The highest ticket wins). If the ticket we have picked is greater, we store the ticket value to best_ticket and the senders account to best_account, else we jump to skip.

Note: the API call get_Ticket_Id_for_Tx_in_A is making the AT to freeze at that point until the ticket is "ready" assuring the ticket is random ( a ticket is ready after 15 blocks from the block the tx belongs, f.e. if you make a tx at block height 14500 then the ticket will be ready at block 14515 and the AT freezes until then).


Here we set the timestamp to the tx's timestamp we just processed and jump to loop where we continue fetching txs after that timestamp.


Here we increase the prize ( payout_balance ) when the creator sends funds to the Lottery.


The above code checks that we have a winner and if we have a winner we pay him either the total ATs account or the payout_balance.

NOTE: Sometimes the AT might have more or less amount than the one it has gathered from tickets. When the ATs amount is greater it means that the processing fees were less than the "minimum activation amount's" gathered from tx's. If the ATs amount is less then the "min activation amount" was set "wrongly" and the processing of the tx's are more costly. Sometimes is difficult or impossible to have a constant min activation amount (f.e if a transaction is greater than the amount needed to participate, the tx will be refunded, thus it will consume more fees. If the tx is equal to the ticket amount then there are no fees for refunding that tx ).


If there is no winner on the previous round ( none txs were sent to the Lottery) then we proceed with initialization of the variables.


Here the refunding takes place. There are 2 possibilities. Either the amount of the tx is greater than the ticket amount or less. If the txs amount is greater then we refund the difference ( tx_amount - min_amount) and then we draw a ticket for that tx, or we refund the total amount of the tx.


After paying the winner we set the timestamp to payout_time and we initialize best_ticket and best_account to 0 and we continue by jumping back to init.

Our very first "use case" was a Lottery (which runs on Burst with a new draw once per week) so the raw assembly code for it is as follows:


Perhaps @vbcs might post a nicer version for you that was created using AT Assembler (which has variable *names* and *labels* rather than just addresses as yes I realise that the above is more than a little hard to decipher).

We are working on the idea of some quicker random games of chance and will be sure to let people know when we have a simple example that they can study (we might perhaps make a simple "highest random value wins" for two consecutive players).

One limitation that AT hosts do have is how quickly they can generate "random" data (on Burst that is currently set at 14 blocks from memory) so you could have a dice kind of game but it won't be "instant" (the same AT could work much faster on a blockchain that can produce entropy quicker).

hi CIYAM!!!

can you explain in a few words...
how AT could be use to implement a simple gambling like lottery or dice game??

thanks!!!

For those keen enough to want to create an AT for themselves an AT Assembler has been created (written in Scala) which you can find here: https://github.com/BurstProject/ATAssembler (it is what has been used to create the AT use cases that have been released with Burst).

Although creating ATs in assembly language is clearly no easy thing we include HTML with our AT use cases that actually mean you can create your own instant clone without having to know or care about any code (just fill in a simple form and click a button).

We are still yet to formalise a UI specification system but we hope to have that worked out soon so we can extend our tools to be able to make it very easy for people to create portable ATs with a nice looking UI with the minimum of effort.

Although AT is currently only tied to Burst I think that this link is still worth sharing: https://bitcointalksearch.org/topic/m.10397472 as we have created a decentralised Crowfunding system (with no 684 pledger limit such as Lighthouse has).

AT could be used with Bitcoin (assuming the core devs decide to implement it) and the way that could be done is described here: http://ciyam.org/at/at_script.html (a general technical description of how Bitcoin Script could be changed to support AT with the addition of just one new op code).

It would of course be best for this to be done on a Bitcoin clone first which is why I created a 20 BTC bounty for just this: https://bitcointalksearch.org/topic/20-btc-bounty-for-first-at-atomic-cross-chain-transfer-with-script-clone-826263 (we have had some interest in the bounty but no-one has yet "bitten the bullet" and actually started implementing it AFAIA).

I'd expect that the core devs would want to see how it goes on a Bitcoin clone (maybe several) for quite a while before they would consider whether or not they would want to add the functionality to Bitcoin itself (and that is a perfectly reasonable attitude to have).

How  AT can be used with Bitcoin?

What is needed to be done?

In order to help explain how AT works and to help anyone trying to create ATs who mostly use this forum for information I have created this topic.

*** mods please note that AT has been designed to work on any blockchain so please do not move this into the alts section ***

The current documentation for AT can be found here: http://ciyam.org/at but it is highly technical (we do intend to provide some simpler documentation as we progress).

So if you have any questions about AT (what it can and can't do, how does it work, etc.) please ask away.

P.S. I've made this topic self-moderated as unfortunately I am currently being followed by trolls in every new topic I create (but I will only be removing off-topic or troll posts).