My guess it was thanks to the ad sig posters that this topic got moved into alts *even though AT is not an alt*.
Will lock this topic now - thanks a lot *mods* for being unable to even understand a technology from an alt and thanks for nothing ad sig posters.
Topic: Understanding the Automated Transaction system (AT) (Read 5267 times)
if i understand wrong,
you can explain me better... instead delete all the post...
i'm interested to understand better and i'm buying burst for the long run...
I think it's one of the few valid altcoin!!
you can explain me better... instead delete all the post...
i'm interested to understand better and i'm buying burst for the long run...
I think it's one of the few valid altcoin!!
I don't really care about whether people invest in BURST or not (I own *zero* BURST) and I will quote valid points if made but if the content is not adding anything of use (and especially if the poster has an ad sig) then I will delete it.
Hope this is clear (my topic so my rules).
So if you have an "ad sig" then please create a new account without it (for forum is happy for everyone to have multiple accounts) and please post with that account instead (if you are truly interested in this topic rather than just trying to meet your ad sig quota then I don't think it is too much to ask).
If there are any valid points made from ad sig posters then I'll quote them (but will still delete their ad sig post).
I think we can make similiar script to adopt a payment system (with an automatic confirmation of transactions). What do you think about it?
Certainly ATs could be used as an automatic funds dispersing agent (if that is your concept).
One idea that we have thought of that could be useful is an AT that acts as a "pocket money" sender so that you could send it some large amount of funds which it would send a small portion to another account regularly.
It could also be handy for scheduled payments with an option to send it a message to redirect the funds back to its creator (i.e. "cancel subscription").
this could be used to pay for a service regularly.
I buy some service from A with address XYZ.
I have to pay it weekly with 10 burst.
i charge via AT 1000 burst.
every week 's, AT, pays to A.XYZ, 10 burst.
this could be useful!
if i understand wrong,
you can explain me better... instead delete all the post...
i'm interested to understand better and i'm buying burst for the long run...
I think it's one of the few valid altcoin!!
Indeed, that's what I was talkin about. It could be really nice, payments integration with shops and websites should be really easy.
I think we can make similiar script to adopt a payment system (with an automatic confirmation of transactions). What do you think about it?
Certainly ATs could be used as an automatic funds dispersing agent (if that is your concept).
One idea that we have thought of that could be useful is an AT that acts as a "pocket money" sender so that you could send it some large amount of funds which it would send a small portion to another account regularly.
It could also be handy for scheduled payments with an option to send it a message to redirect the funds back to its creator (i.e. "cancel subscription").
How can each AT access its account's funds without its address's corresponding public key? Does it still store its funds cryptographically secured on the blockchain? I don't understand how each account can securely hold funds without holding a secret key. I thought secrets were impossible to hold in an AT.
An AT account has no public or private key - each peer knows that an AT account is not a normal account and that its funds can only be "spent" via executing the AT code.
Great work! BURST community should be really proud of your work 
I think we can make similiar script to adopt a payment system (with an automatic confirmation of transactions). What do you think about it?
I think we can make similiar script to adopt a payment system (with an automatic confirmation of transactions). What do you think about it?
So let's take a look at the assembly code for our Crowdfund AT:
Only 28 lines (25 of which are actual steps and 3 of which are "labels").
So amazingly enough we have built a crowdfunding system that requires only 25 steps of code!
And one of the key things that makes this use case "so efficient" can be found in the first two lines of assembly (which are the first two steps executed after the AT has been created and funds are sent to it).
The first step stores the current block height in a variable (used by the UI so it knows when the crowdfunding actually "started") and the second "key" step puts the AT "to sleep" until the crowdfunding decision time (in blocks) has been reached.
So apart from being executed *once* after creation this AT actually *does nothing* until the time for the decision of whether the target has been reached occurs.
This means it is costing *zero* resources for each node to run after the first two steps until decision time (you couldn't get much more efficient than that).
Code:
FUN @block_height get_Block_Timestamp
SLP $decision
FUN @amount get_Current_Balance
BGE $amount $target_amount :funded
FUN @timestamp get_Creation_Timestamp
refund_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @tx_amount get_Amount_for_Tx_in_A
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Tx_in_A
SET @funded #0000000000000002
FUN send_to_Address_in_B $tx_amount
JMP :refund_loop
funded:
SET @funded #0000000000000001
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
FUN @timestamp get_Last_Block_Timestamp
end_loop:
FUN A_to_Tx_after_Timestamp $timestamp
FUN @tx_info check_A_Is_Zero
BZR $tx_info :end_loop
FUN @timestamp get_Timestamp_for_Tx_in_A
FUN B_to_Address_of_Creator
FUN send_All_to_Address_in_B
JMP :end_loop
Only 28 lines (25 of which are actual steps and 3 of which are "labels").
So amazingly enough we have built a crowdfunding system that requires only 25 steps of code!
And one of the key things that makes this use case "so efficient" can be found in the first two lines of assembly (which are the first two steps executed after the AT has been created and funds are sent to it).
The first step stores the current block height in a variable (used by the UI so it knows when the crowdfunding actually "started") and the second "key" step puts the AT "to sleep" until the crowdfunding decision time (in blocks) has been reached.
So apart from being executed *once* after creation this AT actually *does nothing* until the time for the decision of whether the target has been reached occurs.
This means it is costing *zero* resources for each node to run after the first two steps until decision time (you couldn't get much more efficient than that).
Great to see the debugger published!
I have been thinking that we might be wise to add a couple of "end of life" variables to the creation data (with constant values for defaults) in order to provide a way that ATs can actually become "de-activated" (with any tx attempting to send simply becoming an invalid tx from that point on).
One might be an absolute block number to cease being valid (default to zero meaning lasts forever as is currently the case) and the second would be a maximum blocks for inactivity (and as we haven't released any "dormant funds" ATs into the wild yet this value might be fairly small by default - say a few thousand blocks).
Not only would this provide a natural way to "clean up" old CFs that are just hanging around for no further real purpose (such as say a "2015 NY Conference Airfare" AT) but will also allow a neater way to create CFs that might simply stop functioning after their deadline has been reached (rather than continue as a donation as it doesn't always make sense for it to work that way).
I'd think that in the UI ATs which are inactive would appear "disabled" and after they have been inactive for a period of time (say a week?) then they would cease to be display at all (and can be removed from any DB index).
I realise that this sort of change would introduce a fork risk so it would of course need to be introduced at a particular block height to minimise that potential problem (it would also need to be decided where any remaining balance for the AT gets sent).
I have been thinking that we might be wise to add a couple of "end of life" variables to the creation data (with constant values for defaults) in order to provide a way that ATs can actually become "de-activated" (with any tx attempting to send simply becoming an invalid tx from that point on).
One might be an absolute block number to cease being valid (default to zero meaning lasts forever as is currently the case) and the second would be a maximum blocks for inactivity (and as we haven't released any "dormant funds" ATs into the wild yet this value might be fairly small by default - say a few thousand blocks).
Not only would this provide a natural way to "clean up" old CFs that are just hanging around for no further real purpose (such as say a "2015 NY Conference Airfare" AT) but will also allow a neater way to create CFs that might simply stop functioning after their deadline has been reached (rather than continue as a donation as it doesn't always make sense for it to work that way).
I'd think that in the UI ATs which are inactive would appear "disabled" and after they have been inactive for a period of time (say a week?) then they would cease to be display at all (and can be removed from any DB index).
I realise that this sort of change would introduce a fork risk so it would of course need to be introduced at a particular block height to minimise that potential problem (it would also need to be decided where any remaining balance for the AT gets sent).
My AT debugger is now on github here: https://github.com/BurstProject/ATDebugger
You can load AT source and run it, set breakpoints, step through it, and view and edit variables.
You can load AT source and run it, set breakpoints, step through it, and view and edit variables.
I do get the concern and would not protest if we decide that "sticking to the initial UI" is the rule.
Whether there is any reasonable way to upgrade UI (beyond the generic side) is perhaps not something to be considering at this stage anyway (I think if we get the metadata approach right we hopefully won't have any real problems).
Whether there is any reasonable way to upgrade UI (beyond the generic side) is perhaps not something to be considering at this stage anyway (I think if we get the metadata approach right we hopefully won't have any real problems).
Indeed I do think this is a complicated area as you would not want the user to be "tricked" by a new UI that apparently "changes the rules" (although the underlying rules in the AT themselves cannot be changed).
For sure I would not want to see UI upgraded "automatically" (it would need to be up to each user to decide) and perhaps there would need to even some sort of majority agreement amongst nodes to accept any change.
The case in point that lead me to ponder this was the CF AT which currently displays "Pledge" even when the CF has reached 100% (arguably it should show "Donate" after this point even before the target block is reached).
Such a UI update would not alter the function of the AT at all but I do agree that some other change might not be as acceptable. Another possible idea is that you could choose to use the original UI always (if you don't trust any updated UI).
This is one of the main reasons why I think that UI needs to be implemented using metadata rather than any "code" in the AT.
Also with metadata I think it might be easy enough to recognise "display only" changes (i.e. not functional ones) which should be harmless enough to permit.
Fundamentally the "real interface" is defined by the AT itself in terms of the "txs and messages" it processes - so you could actually allow for multiple UIs for the same AT (none should be able to cause any trouble so let the users work out which they like the most).
For sure I would not want to see UI upgraded "automatically" (it would need to be up to each user to decide) and perhaps there would need to even some sort of majority agreement amongst nodes to accept any change.
The case in point that lead me to ponder this was the CF AT which currently displays "Pledge" even when the CF has reached 100% (arguably it should show "Donate" after this point even before the target block is reached).
Such a UI update would not alter the function of the AT at all but I do agree that some other change might not be as acceptable. Another possible idea is that you could choose to use the original UI always (if you don't trust any updated UI).
This is one of the main reasons why I think that UI needs to be implemented using metadata rather than any "code" in the AT.
Also with metadata I think it might be easy enough to recognise "display only" changes (i.e. not functional ones) which should be harmless enough to permit.
Fundamentally the "real interface" is defined by the AT itself in terms of the "txs and messages" it processes - so you could actually allow for multiple UIs for the same AT (none should be able to cause any trouble so let the users work out which they like the most).
Even "display only" changes can be dangerous, such as swapping the labels on buttons to make users choose the wrong choice.
Any sort of offering multiple interfaces complicates things for the end user, who is most likely to accept the most recent version without considering the consequences or comparing the differences. People are already blindly trusting ATs that they haven't looked at the code at, and I wouldn't expect any better for interface metadata.
Indeed I do think this is a complicated area as you would not want the user to be "tricked" by a new UI that apparently "changes the rules" (although the underlying rules in the AT themselves cannot be changed).
For sure I would not want to see UI upgraded "automatically" (it would need to be up to each user to decide) and perhaps there would need to even some sort of majority agreement amongst nodes to accept any change.
The case in point that lead me to ponder this was the CF AT which currently displays "Pledge" even when the CF has reached 100% (arguably it should show "Donate" after this point even before the target block is reached).
Such a UI update would not alter the function of the AT at all but I do agree that some other change might not be as acceptable. Another possible idea is that you could choose to use the original UI always (if you don't trust any updated UI).
This is one of the main reasons why I think that UI needs to be implemented using metadata rather than any "code" in the AT.
Also with metadata I think it might be easy enough to recognise "display only" changes (i.e. not functional ones) which should be harmless enough to permit.
Fundamentally the "real interface" is defined by the AT itself in terms of the "txs and messages" it processes - so you could actually allow for multiple UIs for the same AT (none should be able to cause any trouble so let the users work out which they like the most).
For sure I would not want to see UI upgraded "automatically" (it would need to be up to each user to decide) and perhaps there would need to even some sort of majority agreement amongst nodes to accept any change.
The case in point that lead me to ponder this was the CF AT which currently displays "Pledge" even when the CF has reached 100% (arguably it should show "Donate" after this point even before the target block is reached).
Such a UI update would not alter the function of the AT at all but I do agree that some other change might not be as acceptable. Another possible idea is that you could choose to use the original UI always (if you don't trust any updated UI).
This is one of the main reasons why I think that UI needs to be implemented using metadata rather than any "code" in the AT.
Also with metadata I think it might be easy enough to recognise "display only" changes (i.e. not functional ones) which should be harmless enough to permit.
Fundamentally the "real interface" is defined by the AT itself in terms of the "txs and messages" it processes - so you could actually allow for multiple UIs for the same AT (none should be able to cause any trouble so let the users work out which they like the most).
In thinking about the UI we have made some interesting observations.
Firstly the "code" for an AT cannot be changed (otherwise you could never trust it and basically the main point of ATs is that can act as entities that require no trust beyond understanding their code) but it is possible that the UI could be improved (without changing any of the machine code of that AT).
How this is best handled is still something that requires some consideration but it does make sense that the UI might be able to be upgraded despite the fact that the AT machine code cannot be.
Firstly the "code" for an AT cannot be changed (otherwise you could never trust it and basically the main point of ATs is that can act as entities that require no trust beyond understanding their code) but it is possible that the UI could be improved (without changing any of the machine code of that AT).
How this is best handled is still something that requires some consideration but it does make sense that the UI might be able to be upgraded despite the fact that the AT machine code cannot be.
It seems to me that if the ui is intended to be a reliable method of viewing and interacting the AT, the ui should not be updatable. If the ui can be swapped out and show different variables or send a different message when a button is clicked it could cause a user to perform unintended actions or make decisions on wrong information even if the AT and ui has been previously confirmed to work as expected.
In thinking about the UI we have made some interesting observations.
Firstly the "code" for an AT cannot be changed (otherwise you could never trust it and basically the main point of ATs is that can act as entities that require no trust beyond understanding their code) but it is possible that the UI could be improved (without changing any of the machine code of that AT).
How this is best handled is still something that requires some consideration but it does make sense that the UI might be able to be upgraded despite the fact that the AT machine code cannot be.
Firstly the "code" for an AT cannot be changed (otherwise you could never trust it and basically the main point of ATs is that can act as entities that require no trust beyond understanding their code) but it is possible that the UI could be improved (without changing any of the machine code of that AT).
How this is best handled is still something that requires some consideration but it does make sense that the UI might be able to be upgraded despite the fact that the AT machine code cannot be.
The metadata for new ATs will be stored in the AT creation txs themselves so your client will automatically how to generate the UI for those ATs as soon as it first seems them.
I am not sure exactly how @burstcoin wants to present the ATs (and some ability to search them is going to be essential as it could be expected that their number could grow rapidly) but most importantly you won't need to have to download separate UI files.
a possible solution it is to create a repository and a new function on burstcoin left pane like "check for update".
this function do some simple task:
1) check the html\ui\ folder to check if all file are downloaded...
--> new files/versions found in repository do:
- download/update the local files...
--> nothing new found:
- do nothing
i do not know hot to ensure client write/read rules...
I am not sure exactly how @burstcoin wants to present the ATs (and some ability to search them is going to be essential as it could be expected that their number could grow rapidly) but most importantly you won't need to have to download separate UI files.
In regards to the UI for AT we are currently creating a new design that should mean that .html files won't need to be installed manually (the UI will be able to be automatically generated according to metadata stored in the AT creation tx).
hi CIYAM..
are you telling us who next burst release will have new sections in left menu pane?
like AT or AT_Lottery or AT_Crowd_Funding??
this could be great
thanks!
an attack to recurrence ability because resources are not infinite.
Try creating an "infinite loop" AT - I'll even give you the machine code for that here:
Code:
1A000000
Now see what damage you can do with it.
(hint - you can't do any more damage with that than any other sort of DoS type of attack on the network)
ok, will try it! thank you!
That code is missing a byte on the end, should have 8 0s, not 6. Also if entered into burst the parser assumes lowercase on the hex, so 1a00000000 is correct.
Here's what would happen if that was submitted on burst(or any other coin that implemented AT):
that hex is the equivelant of JMP 0 (jump to first position, which is that same instruction again)
once submitted to the network, the AT will be created and not do anything yet.
Once funds are sent to it, it will run the loop, subtracting a step fee each time it executes that instruction until it runs out of funds or hits the max steps for one block.
If the max steps were hit, it will continue the next block.
Once the funds have been used up it will stall until more are sent.
In burst it has a per block limit of 2000 steps, with normal operations counting as 1 step, and api calls counting as 10 steps, so it could run 2000 iterations per block, costing 200 burst per block until it is drained.
Due to the step costs, it would be much more effective and cheaper to attempt to dos the network by spamming it with normal transactions than with loops like that.
ok, will try it! thank you!
What you'll find is that unless you send it funds it will actually do nothing at all (so won't waste anyone's resources beyond the actual AT creation tx data in the blockchain).
And even if you send it say 1M BURST it won't cause the next block minter to run out of memory (or get stuck forever) as the fixed maximum steps per AT will mean it won't spend more than a fraction of a second processing that (there is also a max. number of ATs that can be processed per block limit so you can't screw things up by creating 1M such ATs).
So any such "attack" would actually be less effective than just sending millions of "normal txs".
Jump to: