Bitcoin Forum
June 23, 2024, 05:39:15 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Understanding the Automated Transaction system (AT)  (Read 5267 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
CIYAM (OP)
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2015, 04:09:39 PM
Last edit: February 08, 2015, 05:25:42 PM by CIYAM
 #1

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Vrontis
Sr. Member
****
Offline Offline

Activity: 351
Merit: 250



View Profile WWW
February 08, 2015, 06:01:04 PM
 #2

How  AT can be used with Bitcoin?

What is needed to be done?

CIYAM (OP)
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2015, 06:07:36 PM
Last edit: February 08, 2015, 06:32:57 PM by CIYAM
 #3

How AT can be used with Bitcoin?

What is needed to be done?

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://bitcointalk.org/index.php?topic=826263.0 (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).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM (OP)
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2015, 06:56:01 PM
 #4

Although AT is currently only tied to Burst I think that this link is still worth sharing: https://bitcointalk.org/index.php?topic=731923.msg10397472#msg10397472 as we have created a decentralised Crowfunding system (with no 684 pledger limit such as Lighthouse has).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM (OP)
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 09, 2015, 08:02:28 AM
Last edit: February 09, 2015, 08:59:56 AM by CIYAM
 #5

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
zlatanBorec
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
February 09, 2015, 12:01:42 PM
 #6

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


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!!!
CIYAM (OP)
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 09, 2015, 12:13:40 PM
 #7

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

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:

Code:
00000000* BNZ $00000000 :0000004c
00000006  SET @00000001 #0000002e90edd000
00000013  FUN @00000000 0x0301
0000001a  SET @00000002 $00000000
00000023  SET @00000003 #0000000000000000
00000030  SET @00000004 #0000000000002760
0000003d  FUN @00000000 0x0406 $00000000 $00000004
0000004c  FUN 0x0304 $00000002
00000053  FUN @00000004 0x0125
0000005a  BNZ $00000004 :00000061
00000060  FIN
00000061  FUN @00000005 0x0307
00000068  BLT $00000005 $00000000 :00000077
00000072  JMP :00000110
00000077  FUN @00000006 0x0306
0000007e  FUN 0x030a
00000081  FUN @00000004 0x0104
00000088  FUN 0x030b
0000008b  FUN @00000007 0x0104
00000092  BEQ $00000007 $00000004 :00000102
0000009c  FUN @00000004 0x0305
000000a3  BNZ $00000004 :000000f4
000000a9  BEQ $00000006 $00000001 :000000b8
000000b3  JMP :00000156
000000b8  FUN @00000004 0x0308
000000bf  FIZ $00000004
000000c4  FUN 0x030a
000000c7  FUN 0x0110 $00000004
000000ce  FUN 0x0405
000000d1  ADD @00000003 $00000001
000000da  BLE $00000004 $00000008 :000000f4
000000e4  SET @00000008 $00000004
000000ed  FUN @00000009 0x0104
000000f4  SET @00000002 $00000005
000000fd  JMP :0000004c
00000102  ADD @00000003 $00000006
0000010b  JMP :000000f4
00000110  BZR $00000003 :00000148
00000116  BZR $00000008 :00000148
0000011c  FUN 0x0116 $00000009
00000123  FUN @0000000a 0x0300
0000012a  BEQ $0000000a $00000000 :00000140
00000134  FUN 0x0402 $00000003
0000013b  JMP :00000184
00000140  FUN 0x0403
00000143  JMP :00000184
00000148  SET @00000002 $00000005
00000151  JMP :00000023
00000156  FUN 0x030a
00000159  BLE $00000006 $00000001 :00000178
00000163  SUB @00000006 $00000001
0000016c  FUN 0x0402 $00000006
00000173  JMP :000000b8
00000178  FUN 0x0402 $00000006
0000017f  JMP :000000f4
00000184  SET @00000002 $00000000
0000018d  SET @00000008 #0000000000000000
0000019a  SET @00000009 #0000000000000000
000001a7  JMP :00000023

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
rollingMyCar
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
February 09, 2015, 01:35:47 PM
 #8

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

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:

Code:
00000000* BNZ $00000000 :0000004c
00000006  SET @00000001 #0000002e90edd000
00000013  FUN @00000000 0x0301
0000001a  SET @00000002 $00000000
00000023  SET @00000003 #0000000000000000
00000030  SET @00000004 #0000000000002760
0000003d  FUN @00000000 0x0406 $00000000 $00000004
0000004c  FUN 0x0304 $00000002
00000053  FUN @00000004 0x0125
0000005a  BNZ $00000004 :00000061
00000060  FIN
00000061  FUN @00000005 0x0307
00000068  BLT $00000005 $00000000 :00000077
00000072  JMP :00000110
00000077  FUN @00000006 0x0306
0000007e  FUN 0x030a
00000081  FUN @00000004 0x0104
00000088  FUN 0x030b
0000008b  FUN @00000007 0x0104
00000092  BEQ $00000007 $00000004 :00000102
0000009c  FUN @00000004 0x0305
000000a3  BNZ $00000004 :000000f4
000000a9  BEQ $00000006 $00000001 :000000b8
000000b3  JMP :00000156
000000b8  FUN @00000004 0x0308
000000bf  FIZ $00000004
000000c4  FUN 0x030a
000000c7  FUN 0x0110 $00000004
000000ce  FUN 0x0405
000000d1  ADD @00000003 $00000001
000000da  BLE $00000004 $00000008 :000000f4
000000e4  SET @00000008 $00000004
000000ed  FUN @00000009 0x0104
000000f4  SET @00000002 $00000005
000000fd  JMP :0000004c
00000102  ADD @00000003 $00000006
0000010b  JMP :000000f4
00000110  BZR $00000003 :00000148
00000116  BZR $00000008 :00000148
0000011c  FUN 0x0116 $00000009
00000123  FUN @0000000a 0x0300
0000012a  BEQ $0000000a $00000000 :00000140
00000134  FUN 0x0402 $00000003
0000013b  JMP :00000184
00000140  FUN 0x0403
00000143  JMP :00000184
00000148  SET @00000002 $00000005
00000151  JMP :00000023
00000156  FUN 0x030a
00000159  BLE $00000006 $00000001 :00000178
00000163  SUB @00000006 $00000001
0000016c  FUN 0x0402 $00000006
00000173  JMP :000000b8
00000178  FUN 0x0402 $00000006
0000017f  JMP :000000f4
00000184  SET @00000002 $00000000
0000018d  SET @00000008 #0000000000000000
0000019a  SET @00000009 #0000000000000000
000001a7  JMP :00000023

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


nice to hear about "AT" lottery game!!!
CIYAM,
can you post a link with some how-to play???

many thanks!!!
vbcs
Full Member
***
Offline Offline

Activity: 137
Merit: 100


AT - Automated Transactions - CIYAM Developer


View Profile
February 09, 2015, 07:46:26 PM
Last edit: February 09, 2015, 08:34:36 PM by vbcs
 #9

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:
Code:
BNZ $payout_time :loop
SET @min_amount #00000005efeb1f00
FUN @payout_time get_Creation_Timestamp
SET @timestamp $payout_time
init:
SET @payout_balance #0000000000000000
SET @tx_info #0000000000002760
FUN @payout_time add_Minutes_to_Timestamp $payout_time $tx_info

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:
Code:
loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BNZ $tx_info :process_tx
FIN

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:
Code:
process_tx:
FUN @tx_time get_Timestamp_for_Tx_in_A
BLT $tx_time $payout_time :get_info_amount
JMP :payout

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

Code:
get_info_amount:
FUN @tx_amount get_Amount_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
FUN @tx_info get_B1
FUN B_to_Address_of_Creator
FUN @creator get_B1
BEQ $creator $tx_info :bootstrap
FUN @tx_info get_Type_for_Tx_in_A
BNZ $tx_info :skip
BEQ $tx_amount $min_amount :get_ticket
JMP :refund

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:
 
Code:
 get_ticket:
FUN @tx_info get_Ticket_Id_for_Tx_in_A
FIZ $tx_info
FUN B_to_Address_of_Tx_in_A
FUN set_A1 $tx_info
FUN send_A_to_Address_in_B
ADD @payout_balance $min_amount
BLE $tx_info $best_ticket :skip
SET @best_ticket $tx_info
FUN @best_account get_B1

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

Code:
skip:
SET @timestamp $tx_time
JMP :loop

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.

Code:
bootstrap:
ADD @payout_balance $tx_amount
JMP :skip

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

Code:
payout:
BZR $payout_balance :empty
BZR $best_ticket :empty
FUN set_B1 $best_account
FUN @block_timestamp get_Block_Timestamp
BEQ $block_timestamp $payout_time :pay_all_at_amount
FUN send_to_Address_in_B $payout_balance
JMP :finish_payout
pay_all_at_amount:
FUN send_All_to_Address_in_B
JMP :finish_payout

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

Code:
empty:
SET @timestamp $tx_time
JMP :init

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

Code:
refund:
FUN B_to_Address_of_Tx_in_A
BLE $tx_amount $min_amount :refund_less
SUB @tx_amount $min_amount
FUN send_to_Address_in_B $tx_amount
JMP :get_ticket
refund_less:
FUN send_to_Address_in_B $tx_amount
JMP :skip

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.

Code:
finish_payout:
SET @timestamp $payout_time
SET @best_ticket #0000000000000000
SET @best_account #0000000000000000
JMP :init

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.


1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
zlatanBorec
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
February 09, 2015, 08:06:19 PM
 #10

To design an AT properly you need some insight knowledge on how AT is working. 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:
Code:
BNZ $payout_time :loop
SET @min_amount #00000005efeb1f00
FUN @payout_time get_Creation_Timestamp
SET @timestamp $payout_time
init:
SET @payout_balance #0000000000000000
SET @tx_info #0000000000002760
FUN @payout_time add_Minutes_to_Timestamp $payout_time $tx_info

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:
Code:
loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BNZ $tx_info :process_tx
FIN

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:
Code:
process_tx:
FUN @tx_time get_Timestamp_for_Tx_in_A
BLT $tx_time $payout_time :get_info_amount
JMP :payout

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

Code:
get_info_amount:
FUN @tx_amount get_Amount_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
FUN @tx_info get_B1
FUN B_to_Address_of_Creator
FUN @creator get_B1
BEQ $creator $tx_info :bootstrap
FUN @tx_info get_Type_for_Tx_in_A
BNZ $tx_info :skip
BEQ $tx_amount $min_amount :get_ticket
JMP :refund

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:
 
Code:
 get_ticket:
FUN @tx_info get_Ticket_Id_for_Tx_in_A
FIZ $tx_info
FUN B_to_Address_of_Tx_in_A
FUN set_A1 $tx_info
FUN send_A_to_Address_in_B
ADD @payout_balance $min_amount
BLE $tx_info $best_ticket :skip
SET @best_ticket $tx_info
FUN @best_account get_B1

Here we draw a ticket for that tx and if is not zero then we get the senders address and send him a message with the ticket. After that we add the amount of the tx to the payout_balance and we check if the ticket we draw is great than the best_ticket. (Note: The highest ticket wins). If the ticket we draw is greater then 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).

Code:
skip:
SET @timestamp $tx_time
JMP :loop

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.

Code:
bootstrap:
ADD @payout_balance $tx_amount
JMP :skip

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

Code:
payout:
BZR $payout_balance :empty
BZR $best_ticket :empty
FUN set_B1 $best_account
FUN @block_timestamp get_Block_Timestamp
BEQ $block_timestamp $payout_time :pay_all_at_amount
FUN send_to_Address_in_B $payout_balance
JMP :finish_payout
pay_all_at_amount:
FUN send_All_to_Address_in_B
JMP :finish_payout

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 ticket amount the AT will also refund that tx, thus it will consume more fees. If the tx is equal to the ticket amount then there are no fees for refunding that tx).

Code:
empty:
SET @timestamp $tx_time
JMP :init

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

Code:
refund:
FUN B_to_Address_of_Tx_in_A
BLE $tx_amount $min_amount :refund_less
SUB @tx_amount $min_amount
FUN send_to_Address_in_B $tx_amount
JMP :get_ticket
refund_less:
FUN send_to_Address_in_B $tx_amount
JMP :skip

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.

Code:
finish_payout:
SET @timestamp $payout_time
SET @best_ticket #0000000000000000
SET @best_account #0000000000000000
JMP :init

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.


wow!!!!

i appreciate really a lot vbcs!!!
you do a lot of work for this community!!!
you are great!!!!
i'm going to read it...

thank you again!!!
vbcs
Full Member
***
Offline Offline

Activity: 137
Merit: 100


AT - Automated Transactions - CIYAM Developer


View Profile
February 09, 2015, 08:25:53 PM
 #11

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

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:

Code:
00000000* BNZ $00000000 :0000004c
00000006  SET @00000001 #0000002e90edd000
00000013  FUN @00000000 0x0301
0000001a  SET @00000002 $00000000
00000023  SET @00000003 #0000000000000000
00000030  SET @00000004 #0000000000002760
0000003d  FUN @00000000 0x0406 $00000000 $00000004
0000004c  FUN 0x0304 $00000002
00000053  FUN @00000004 0x0125
0000005a  BNZ $00000004 :00000061
00000060  FIN
00000061  FUN @00000005 0x0307
00000068  BLT $00000005 $00000000 :00000077
00000072  JMP :00000110
00000077  FUN @00000006 0x0306
0000007e  FUN 0x030a
00000081  FUN @00000004 0x0104
00000088  FUN 0x030b
0000008b  FUN @00000007 0x0104
00000092  BEQ $00000007 $00000004 :00000102
0000009c  FUN @00000004 0x0305
000000a3  BNZ $00000004 :000000f4
000000a9  BEQ $00000006 $00000001 :000000b8
000000b3  JMP :00000156
000000b8  FUN @00000004 0x0308
000000bf  FIZ $00000004
000000c4  FUN 0x030a
000000c7  FUN 0x0110 $00000004
000000ce  FUN 0x0405
000000d1  ADD @00000003 $00000001
000000da  BLE $00000004 $00000008 :000000f4
000000e4  SET @00000008 $00000004
000000ed  FUN @00000009 0x0104
000000f4  SET @00000002 $00000005
000000fd  JMP :0000004c
00000102  ADD @00000003 $00000006
0000010b  JMP :000000f4
00000110  BZR $00000003 :00000148
00000116  BZR $00000008 :00000148
0000011c  FUN 0x0116 $00000009
00000123  FUN @0000000a 0x0300
0000012a  BEQ $0000000a $00000000 :00000140
00000134  FUN 0x0402 $00000003
0000013b  JMP :00000184
00000140  FUN 0x0403
00000143  JMP :00000184
00000148  SET @00000002 $00000005
00000151  JMP :00000023
00000156  FUN 0x030a
00000159  BLE $00000006 $00000001 :00000178
00000163  SUB @00000006 $00000001
0000016c  FUN 0x0402 $00000006
00000173  JMP :000000b8
00000178  FUN 0x0402 $00000006
0000017f  JMP :000000f4
00000184  SET @00000002 $00000000
0000018d  SET @00000008 #0000000000000000
0000019a  SET @00000009 #0000000000000000
000001a7  JMP :00000023

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


nice to hear about "AT" lottery game!!!
CIYAM,
can you post a link with some how-to play???

many thanks!!!

To participate to the lottery you need to download and run burstcoin. Then follow the instructions which are published here:
https://bitcointalk.org/index.php?topic=731923.msg10254497#msg10254497

1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
unsoindovo
Legendary
*
Offline Offline

Activity: 1932
Merit: 1042

https://locktrip.com/?refId=40964


View Profile
February 10, 2015, 07:59:37 PM
 #12

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

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:

Code:
00000000* BNZ $00000000 :0000004c
00000006  SET @00000001 #0000002e90edd000
00000013  FUN @00000000 0x0301
0000001a  SET @00000002 $00000000
00000023  SET @00000003 #0000000000000000
00000030  SET @00000004 #0000000000002760
0000003d  FUN @00000000 0x0406 $00000000 $00000004
0000004c  FUN 0x0304 $00000002
00000053  FUN @00000004 0x0125
0000005a  BNZ $00000004 :00000061
00000060  FIN
00000061  FUN @00000005 0x0307
00000068  BLT $00000005 $00000000 :00000077
00000072  JMP :00000110
00000077  FUN @00000006 0x0306
0000007e  FUN 0x030a
00000081  FUN @00000004 0x0104
00000088  FUN 0x030b
0000008b  FUN @00000007 0x0104
00000092  BEQ $00000007 $00000004 :00000102
0000009c  FUN @00000004 0x0305
000000a3  BNZ $00000004 :000000f4
000000a9  BEQ $00000006 $00000001 :000000b8
000000b3  JMP :00000156
000000b8  FUN @00000004 0x0308
000000bf  FIZ $00000004
000000c4  FUN 0x030a
000000c7  FUN 0x0110 $00000004
000000ce  FUN 0x0405
000000d1  ADD @00000003 $00000001
000000da  BLE $00000004 $00000008 :000000f4
000000e4  SET @00000008 $00000004
000000ed  FUN @00000009 0x0104
000000f4  SET @00000002 $00000005
000000fd  JMP :0000004c
00000102  ADD @00000003 $00000006
0000010b  JMP :000000f4
00000110  BZR $00000003 :00000148
00000116  BZR $00000008 :00000148
0000011c  FUN 0x0116 $00000009
00000123  FUN @0000000a 0x0300
0000012a  BEQ $0000000a $00000000 :00000140
00000134  FUN 0x0402 $00000003
0000013b  JMP :00000184
00000140  FUN 0x0403
00000143  JMP :00000184
00000148  SET @00000002 $00000005
00000151  JMP :00000023
00000156  FUN 0x030a
00000159  BLE $00000006 $00000001 :00000178
00000163  SUB @00000006 $00000001
0000016c  FUN 0x0402 $00000006
00000173  JMP :000000b8
00000178  FUN 0x0402 $00000006
0000017f  JMP :000000f4
00000184  SET @00000002 $00000000
0000018d  SET @00000008 #0000000000000000
0000019a  SET @00000009 #0000000000000000
000001a7  JMP :00000023

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


nice to hear about "AT" lottery game!!!
CIYAM,
can you post a link with some how-to play???

many thanks!!!

To participate to the lottery you need to download and run burstcoin. Then follow the instructions which are published here:
https://bitcointalk.org/index.php?topic=731923.msg10254497#msg10254497

i just installed the html file to use lottery!!!

can you explain what stand for:
   - Current best ticket
   - Total amount
   - Next draw


thanks...



██▬▬▬

██▬

██▬

██▬▬▬



████           ▄▄█████████▄▄            ▄▄█████████▄▄        ████         █████      ██████████████████   ████████████       ████    ████████████    
████         ▄███████████████▄        ▄███████████████▄      ████       █████      ████████████████████  █████████████      ████    █████████████   
████        █████▀       ▀█████▄     █████▀       ▀█████     ████     █████         █       ████       █  ████     █████             ████     █████  
████       ████▀           ▀████▄   ████▀           ▀████    ████   █████                   ████          ████      ████     ████    ████      ████  
████      ████▀              ▀████ ▀███▀                     ████ █████                     ████          ████     █████     ████    ████     █████  
████      ████                 ████▄ ▀                       ████████                       ████          █████████████      ████    █████████████   
████      ████                  ▀████                        ████████                       ████          ████████████       ████    ████████████    
████      ████▄             ▄██▄ ▀████▄                      ████ █████                     ████          ████    ████       ████    ████            
████       ████▄           ▄████   ▀████▄           ▄████    ████   █████                   ████          ████    ▀████      ████    ████            
████        █████▄       ▄█████      █████▄       ▄█████     ████     █████                 ████          ████      ████     ████    ████            
████████████ ▀███████████████▀        ▀███████████████▀      ████       █████               ████          ████       ████    ████    ████            
█████████████  ▀▀█████████▀▀            ▀▀█████████▀▀        ████         █████             ████          ████        █████  ████    ████            

 
 
 
▬▬▬██

▬██

▬██

▬▬▬██
vbcs
Full Member
***
Offline Offline

Activity: 137
Merit: 100


AT - Automated Transactions - CIYAM Developer


View Profile
February 10, 2015, 08:12:46 PM
 #13

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

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:

Code:
00000000* BNZ $00000000 :0000004c
00000006  SET @00000001 #0000002e90edd000
00000013  FUN @00000000 0x0301
0000001a  SET @00000002 $00000000
00000023  SET @00000003 #0000000000000000
00000030  SET @00000004 #0000000000002760
0000003d  FUN @00000000 0x0406 $00000000 $00000004
0000004c  FUN 0x0304 $00000002
00000053  FUN @00000004 0x0125
0000005a  BNZ $00000004 :00000061
00000060  FIN
00000061  FUN @00000005 0x0307
00000068  BLT $00000005 $00000000 :00000077
00000072  JMP :00000110
00000077  FUN @00000006 0x0306
0000007e  FUN 0x030a
00000081  FUN @00000004 0x0104
00000088  FUN 0x030b
0000008b  FUN @00000007 0x0104
00000092  BEQ $00000007 $00000004 :00000102
0000009c  FUN @00000004 0x0305
000000a3  BNZ $00000004 :000000f4
000000a9  BEQ $00000006 $00000001 :000000b8
000000b3  JMP :00000156
000000b8  FUN @00000004 0x0308
000000bf  FIZ $00000004
000000c4  FUN 0x030a
000000c7  FUN 0x0110 $00000004
000000ce  FUN 0x0405
000000d1  ADD @00000003 $00000001
000000da  BLE $00000004 $00000008 :000000f4
000000e4  SET @00000008 $00000004
000000ed  FUN @00000009 0x0104
000000f4  SET @00000002 $00000005
000000fd  JMP :0000004c
00000102  ADD @00000003 $00000006
0000010b  JMP :000000f4
00000110  BZR $00000003 :00000148
00000116  BZR $00000008 :00000148
0000011c  FUN 0x0116 $00000009
00000123  FUN @0000000a 0x0300
0000012a  BEQ $0000000a $00000000 :00000140
00000134  FUN 0x0402 $00000003
0000013b  JMP :00000184
00000140  FUN 0x0403
00000143  JMP :00000184
00000148  SET @00000002 $00000005
00000151  JMP :00000023
00000156  FUN 0x030a
00000159  BLE $00000006 $00000001 :00000178
00000163  SUB @00000006 $00000001
0000016c  FUN 0x0402 $00000006
00000173  JMP :000000b8
00000178  FUN 0x0402 $00000006
0000017f  JMP :000000f4
00000184  SET @00000002 $00000000
0000018d  SET @00000008 #0000000000000000
0000019a  SET @00000009 #0000000000000000
000001a7  JMP :00000023

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


nice to hear about "AT" lottery game!!!
CIYAM,
can you post a link with some how-to play???

many thanks!!!

To participate to the lottery you need to download and run burstcoin. Then follow the instructions which are published here:
https://bitcointalk.org/index.php?topic=731923.msg10254497#msg10254497

i just installed the html file to use lottery!!!

can you explain what stand for:
   - Current best ticket
   - Total amount
   - Next draw


thanks...




In this lottery use case the highest ticket wins the total amount gathered. So the total amount is the total amount the lottery has gathered till now. When you purchase a ticket, that ticket is compared to the current best ticket and if it is greater then your ticket becomes the best ticket. The payout will occur when the lottery runs after the block height defined in next draw.

I am planning to deploy more Lottery cases, where you are not aware of the tickets until is time for drawing the winner or "heads up" cases (where the lottery waits for 2 participants and then decides the winner).

1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
vbcs
Full Member
***
Offline Offline

Activity: 137
Merit: 100


AT - Automated Transactions - CIYAM Developer


View Profile
February 10, 2015, 08:25:35 PM
Last edit: February 10, 2015, 08:49:18 PM by vbcs
 #14

Also, I have upload a new html version for the Lottery cases where the ATs are filtered properly and you only see the Lottery cases:

https://mega.co.nz/#!ycpXCADa!BWzhEmkm0JzfWn2HZL7YTat4hg0Jwuz5gD34TJ9SmSY

1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
redHairy
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
February 11, 2015, 09:18:59 AM
 #15

Also, I have upload a new html version for the Lottery cases where the ATs are filtered properly and you only see the Lottery cases:

https://mega.co.nz/#!ycpXCADa!BWzhEmkm0JzfWn2HZL7YTat4hg0Jwuz5gD34TJ9SmSY

i'm really interested vbcs!!!
when i come back home i give it a try for sure!!!!

 Wink

burstcoin
Sr. Member
****
Offline Offline

Activity: 280
Merit: 250


View Profile
February 11, 2015, 04:37:44 PM
 #16

I'd like to give/explain another AT example.

This is AT code for 'fund management'. The AT will store coins, and have 5 authorized users. If 3 of the 5 users send it the same message containing a destination address and an amount, the AT will make a transaction of that amount to that address. If no funds are transfered out for a set amount of time, the AT can be sent a message and the AT will assume it became inaccessable(lost keys, etc), and transfer it's funds to a set address.

Code:
FUN @txIterTime get_Block_Timestamp
^declare scratch
^declare counter

at the top we store the current time for use when iterating transactions.
declare can be used to force variable in specific positions, which can be useful to force variables to the begining if you want to pass initial data on at creation to have them initialized before the AT starts, but we don't do that here, so it's only for demo puposes

SET @numUsers #0000000000000005
SET @neededVotes #0000000000000003
SET @dormantTransferAddress #0000000000000000
SET @dormantTransferMinutes #0000000000000028

we set up some constants used, num users, num votes needed, address to tranfer for inactivity, and minutes of inactivity until transfer(should be much higher, but had it low for testing)

SET @dormantDeadline $txIterTime
FUN @dormantDeadline add_Minutes_to_Timestamp $dormantDeadline $dormantTransferMinutes

we set a deadline for when we'll transfer to fallback if no transfers out occur

^allocate allowedUsers 5
^allocate votesAccount 5
^allocate votesAmount 5

allocate sets aside the specified number of spaces and also adds a SET command setting the variable name specified to the starting address of the block so it can be used as a pointer to an array

^comment set user ids in scratch assignments
CLR @counter
SET @scratch #a9d3c7e1052e59b6
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #d588a72e511f576a
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #878344bc465ee397
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #5b4a79c0ad8542ea
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #fca2612346d6d33b
SET @($allowedUsers + $counter) $scratch
^comment end user id assignments

here we just hardcoded some user ids. for demo purposes these are the id numbers for burst accounts with passphrases a, as, asd, asdf, and asdfg.

ERR :dormantTransfer

we set an error handler. if for some reason the at get stuck and is unable to continue(trying to access address out of address space, divide by 0, etc), it will jump there instead of dieing. The risk of something like that happening here is low due to the simplicity of this at, but it's always a good idea to have a handler dumping the coins somewhere, otherwise they'll all end up in transaction fees going to the miners if you did make a mistake somewhere

PCS

pcs sets a new start point. the AT will resume from here instead of the top when we do finish calls, skipping over the initialization.

txloop:
FUN A_to_Tx_after_Timestamp $txIterTime
FUN @scratch check_A_Is_Zero
FIZ $scratch
FUN @txIterTime get_Timestamp_for_Tx_in_A
FUN @scratch get_Type_for_Tx_in_A
BZR $scratch :txloop

here we have a loop that tries to get the next transaction. an id of 0 is returned if there is none, so we finish if none was retrieved(FIZ = finish if zero). if we did get a tx id, we store the timestamp to use for the next tx retrieval attempt, and then check what type of tx we have. a normal payment is 0, but if there is a message attached it is a type 1. we ignore normal payments transfering funds in, but continue on processing if there is a message

CLR @counter
FUN B_to_Address_of_Tx_in_A
FUN @address get_B1
findUserLoop:
SET @scratch $($allowedUsers + $counter)
BEQ $address $scratch :foundUser
INC @counter
BLT $counter $numUsers :findUserLoop

here we check to see if the user is on the authorized list. we retrieve the address who sent us the tx, and loop through authorized users, and jump to :founduser if we found them in the list

^comment check dormant time
BLE $txIterTime $dormantDeadline :notFoundUser
JMP :dormantTransfer
notFoundUser:
JMP :txloop

if the user wasn't found, we check the timestamp against the inactivity timestamp. due to a limit on the distance a branch op can jump and limitations of the currently available assembler, a workaround needed to be used here of branching over a jmp. the most recent but not yet publically available version can automatically convert too far branches to branch jmp combinations, so this is a temporary issue
if the inactivity deadline is up, we jump to :dormanttransfer, and if not we return to the tx loop.

foundUser:
SET @userIndex $counter
FUN message_from_Tx_in_A_to_B
FUN @address get_B1
FUN @amount get_B2
SET @($votesAccount + $userIndex) $address
SET @($votesAmount + $userIndex) $amount

if the user was found in the authorized list, we save the counter from the loop to use as the array index for that user's state. We get their message and save the intended destination and amount as that user's current vote

CLR @voteCount
CLR @counter
countVotesLoop:
SET @scratch $($votesAccount + $counter)
BNE $scratch $address :notSameVote
SET @scratch $($votesAmount + $counter)
BNE $scratch $amount :notSameVote
INC @voteCount
notSameVote:
INC @counter
BLT $counter $numUsers :countVotesLoop
BGE $voteCount $neededVotes :votePassed
JMP :txloop

now we loop through all the votes, and count up the amount which are identical to the one we just recorded. If the amoount is at least the threshold specified in the constants at the top, we jump to :votePassed, otherwise we head back to the tx loop

votePassed:
FUN clear_B
FUN set_B1 $address
FUN send_to_Address_in_B $amount

when the vote is passed, we send that amount

CLR @counter
CLR @scratch
clearLoop:
SET @($votesAccount + $counter) $scratch
SET @($votesAmount + $counter) $scratch
INC @counter
BLT $counter $numUsers :clearLoop

we clear out all the votes after a send

^comment update dormant transfer deadline
SET @dormantDeadline $txIterTime
FUN @dormantDeadline add_Minutes_to_Timestamp $dormantDeadline $dormantTransferMinutes
JMP :txloop

then we set a new inactivity deadline, and head back to the tx loop

dormantTransfer:
FUN clear_B
FUN set_B1 $dormantTransferAddress
PCS
sendAll:
FUN send_All_to_Address_in_B
JMP :sendAll

if the inactivity deadline runs out a jump from above can take us here, and this is also the error handler. we set the fallback address as destination, and put ourselves in an infinite loop sending there. the script will halt due to lack of funds immediatly after the send, so it will only get activated when it receives more, which it will then proceed to send, then halt

BURST-QHCJ-9HB5-PTGC-5Q8J9
unsoindovo
Legendary
*
Offline Offline

Activity: 1932
Merit: 1042

https://locktrip.com/?refId=40964


View Profile
February 11, 2015, 09:00:24 PM
 #17

I'd like to give/explain another AT example.

This is AT code for 'fund management'. The AT will store coins, and have 5 authorized users. If 3 of the 5 users send it the same message containing a destination address and an amount, the AT will make a transaction of that amount to that address. If no funds are transfered out for a set amount of time, the AT can be sent a message and the AT will assume it became inaccessable(lost keys, etc), and transfer it's funds to a set address.

Code:
FUN @txIterTime get_Block_Timestamp
^declare scratch
^declare counter

at the top we store the current time for use when iterating transactions.
declare can be used to force variable in specific positions, which can be useful to force variables to the begining if you want to pass initial data on at creation to have them initialized before the AT starts, but we don't do that here, so it's only for demo puposes

SET @numUsers #0000000000000005
SET @neededVotes #0000000000000003
SET @dormantTransferAddress #0000000000000000
SET @dormantTransferMinutes #0000000000000028

we set up some constants used, num users, num votes needed, address to tranfer for inactivity, and minutes of inactivity until transfer(should be much higher, but had it low for testing)

SET @dormantDeadline $txIterTime
FUN @dormantDeadline add_Minutes_to_Timestamp $dormantDeadline $dormantTransferMinutes

we set a deadline for when we'll transfer to fallback if no transfers out occur

^allocate allowedUsers 5
^allocate votesAccount 5
^allocate votesAmount 5

allocate sets aside the specified number of spaces and also adds a SET command setting the variable name specified to the starting address of the block so it can be used as a pointer to an array

^comment set user ids in scratch assignments
CLR @counter
SET @scratch #a9d3c7e1052e59b6
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #d588a72e511f576a
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #878344bc465ee397
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #5b4a79c0ad8542ea
SET @($allowedUsers + $counter) $scratch
INC @counter
SET @scratch #fca2612346d6d33b
SET @($allowedUsers + $counter) $scratch
^comment end user id assignments

here we just hardcoded some user ids. for demo purposes these are the id numbers for burst accounts with passphrases a, as, asd, asdf, and asdfg.

ERR :dormantTransfer

we set an error handler. if for some reason the at get stuck and is unable to continue(trying to access address out of address space, divide by 0, etc), it will jump there instead of dieing. The risk of something like that happening here is low due to the simplicity of this at, but it's always a good idea to have a handler dumping the coins somewhere, otherwise they'll all end up in transaction fees going to the miners if you did make a mistake somewhere

PCS

pcs sets a new start point. the AT will resume from here instead of the top when we do finish calls, skipping over the initialization.

txloop:
FUN A_to_Tx_after_Timestamp $txIterTime
FUN @scratch check_A_Is_Zero
FIZ $scratch
FUN @txIterTime get_Timestamp_for_Tx_in_A
FUN @scratch get_Type_for_Tx_in_A
BZR $scratch :txloop

here we have a loop that tries to get the next transaction. an id of 0 is returned if there is none, so we finish if none was retrieved(FIZ = finish if zero). if we did get a tx id, we store the timestamp to use for the next tx retrieval attempt, and then check what type of tx we have. a normal payment is 0, but if there is a message attached it is a type 1. we ignore normal payments transfering funds in, but continue on processing if there is a message

CLR @counter
FUN B_to_Address_of_Tx_in_A
FUN @address get_B1
findUserLoop:
SET @scratch $($allowedUsers + $counter)
BEQ $address $scratch :foundUser
INC @counter
BLT $counter $numUsers :findUserLoop

here we check to see if the user is on the authorized list. we retrieve the address who sent us the tx, and loop through authorized users, and jump to :founduser if we found them in the list

^comment check dormant time
BLE $txIterTime $dormantDeadline :notFoundUser
JMP :dormantTransfer
notFoundUser:
JMP :txloop

if the user wasn't found, we check the timestamp against the inactivity timestamp. due to a limit on the distance a branch op can jump and limitations of the currently available assembler, a workaround needed to be used here of branching over a jmp. the most recent but not yet publically available version can automatically convert too far branches to branch jmp combinations, so this is a temporary issue
if the inactivity deadline is up, we jump to :dormanttransfer, and if not we return to the tx loop.

foundUser:
SET @userIndex $counter
FUN message_from_Tx_in_A_to_B
FUN @address get_B1
FUN @amount get_B2
SET @($votesAccount + $userIndex) $address
SET @($votesAmount + $userIndex) $amount

if the user was found in the authorized list, we save the counter from the loop to use as the array index for that user's state. We get their message and save the intended destination and amount as that user's current vote

CLR @voteCount
CLR @counter
countVotesLoop:
SET @scratch $($votesAccount + $counter)
BNE $scratch $address :notSameVote
SET @scratch $($votesAmount + $counter)
BNE $scratch $amount :notSameVote
INC @voteCount
notSameVote:
INC @counter
BLT $counter $numUsers :countVotesLoop
BGE $voteCount $neededVotes :votePassed
JMP :txloop

now we loop through all the votes, and count up the amount which are identical to the one we just recorded. If the amoount is at least the threshold specified in the constants at the top, we jump to :votePassed, otherwise we head back to the tx loop

votePassed:
FUN clear_B
FUN set_B1 $address
FUN send_to_Address_in_B $amount

when the vote is passed, we send that amount

CLR @counter
CLR @scratch
clearLoop:
SET @($votesAccount + $counter) $scratch
SET @($votesAmount + $counter) $scratch
INC @counter
BLT $counter $numUsers :clearLoop

we clear out all the votes after a send

^comment update dormant transfer deadline
SET @dormantDeadline $txIterTime
FUN @dormantDeadline add_Minutes_to_Timestamp $dormantDeadline $dormantTransferMinutes
JMP :txloop

then we set a new inactivity deadline, and head back to the tx loop

dormantTransfer:
FUN clear_B
FUN set_B1 $dormantTransferAddress
PCS
sendAll:
FUN send_All_to_Address_in_B
JMP :sendAll

if the inactivity deadline runs out a jump from above can take us here, and this is also the error handler. we set the fallback address as destination, and put ourselves in an infinite loop sending there. the script will halt due to lack of funds immediatly after the send, so it will only get activated when it receives more, which it will then proceed to send, then halt

I like more and more the concept of AT!!!!
is a new form of democracy...
really democracy.
and if it is implemented correctly, it will not be possible buy-bribe votes-decisions

if you have some time to spend...
read this gbianchi project...
oraclyze.

it is liek http://www.augur.net/

as soon as possible i will post english material!!

██▬▬▬

██▬

██▬

██▬▬▬



████           ▄▄█████████▄▄            ▄▄█████████▄▄        ████         █████      ██████████████████   ████████████       ████    ████████████    
████         ▄███████████████▄        ▄███████████████▄      ████       █████      ████████████████████  █████████████      ████    █████████████   
████        █████▀       ▀█████▄     █████▀       ▀█████     ████     █████         █       ████       █  ████     █████             ████     █████  
████       ████▀           ▀████▄   ████▀           ▀████    ████   █████                   ████          ████      ████     ████    ████      ████  
████      ████▀              ▀████ ▀███▀                     ████ █████                     ████          ████     █████     ████    ████     █████  
████      ████                 ████▄ ▀                       ████████                       ████          █████████████      ████    █████████████   
████      ████                  ▀████                        ████████                       ████          ████████████       ████    ████████████    
████      ████▄             ▄██▄ ▀████▄                      ████ █████                     ████          ████    ████       ████    ████            
████       ████▄           ▄████   ▀████▄           ▄████    ████   █████                   ████          ████    ▀████      ████    ████            
████        █████▄       ▄█████      █████▄       ▄█████     ████     █████                 ████          ████      ████     ████    ████            
████████████ ▀███████████████▀        ▀███████████████▀      ████       █████               ████          ████       ████    ████    ████            
█████████████  ▀▀█████████▀▀            ▀▀█████████▀▀        ████         █████             ████          ████        █████  ████    ████            

 
 
 
▬▬▬██

▬██

▬██

▬▬▬██
tzpardi
Member
**
Offline Offline

Activity: 66
Merit: 10


View Profile
February 12, 2015, 12:01:06 PM
 #18

Thanks for creating this, it is really good!

Do you know how is this different from the Ethereum scripting system, firstly, is it conceptually the same thing or the purpose of Ethereum's scripting engine is something different?
CIYAM (OP)
Legendary
*
Offline Offline

Activity: 1890
Merit: 1078


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 12, 2015, 12:04:31 PM
 #19

Fundamentally both AT and Ethereum solve the problem of providing "Turing complete" smart contracts but they do this in quite different ways.

Ethereum have used a Java like VM whilst AT is "virtual CPU". To most users of this technology the underlying mechanism is not going to matter and whether one approach or the other is better remains to be seen.

AT does not include a "new high-level language" (which Ethereum does) so the path towards a HLL for AT would actually be to harness an existing (and extremely well tested) system such as LLVM by targeting AT as a new kind of CPU that it can work with.

Assuming we are able to get LLVM working with AT then you would be able to program ATs using C/C++ (and other "industry standard" languages).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
redHairy
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
February 12, 2015, 08:15:14 PM
 #20

Also, I have upload a new html version for the Lottery cases where the ATs are filtered properly and you only see the Lottery cases:

https://mega.co.nz/#!ycpXCADa!BWzhEmkm0JzfWn2HZL7YTat4hg0Jwuz5gD34TJ9SmSY

hi vbcs...
page downloaded and tested..
i have a request...

it is possible to add a column like this:
CountDown

simply put a timer indicating how far it is the conclusion of the current round in DAYS-HH-MM-SS

I do not know if it is feasible but it would be helpful!

thanx again!

Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!