Understanding the Automated Transaction system (AT)

[burstcoin]

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

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.

[CIYAM]

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

[burstcoin]

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.

[CIYAM]

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

[CIYAM]

So let's take a look at the assembly code for our Crowdfund AT:

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

[Chesteer]

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?

[CIYAM]

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.

[CIYAM]

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

[Chesteer]

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.

[CIYAM]

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!!

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

[CIYAM]

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.