Topic: Understanding the Automated Transaction system (AT) (Read 5292 times)

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.

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

Indeed, that's what I was talkin about. It could be really nice, payments integration with shops and websites should be really easy.

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

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?

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

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

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.

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

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

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.

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.

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.

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!

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.

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