Understanding the Automated Transaction system (AT)

[vbcs]

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!

We could put normal timestamps, but they would be estimations. For example the average block time in burst is around 4 minutes. So when the page says ends in 5000 blocks that's about 1250min almost one day, but that figure is just an estimation based on the average block time.

[redHairy]

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!

We could put normal timestamps, but they would be estimations. For example the average block time in burst is around 4 minutes. So when the page says ends in 5000 blocks that's about 1250min almost one day, but that figure is just an estimation based on the average block time.

i get it
you are right..
if so... we can just add 2 simplest colums:

1) BlockRemaining --> NexDrawBlockNumber - CurrentBlockNumber
2) EstimatedTimeForNextDraw --> BlockRemaining * 4, writing note like "this is the estimated until next draw"

if you want to enance the time forecasting, you can use a linear regression of the last 50 or 100 block time...
or if you have not the possibility to use regLnr, you can use a simples moving average...

i do not know assembly...

so, i cannot implement it...

hope a framework who can handle programming in C, C# come out soon!

in any case
thanks for everything

[CIYAM]

I noticed the start of "sig campaign" posts so I have deleted a few posts.

If you have a sponsored sig then don't bother posting here (without posting something of actual relevance) as I will delete your post (unlike the mods I don't care for that shit).

[CIYAM]

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

[Gyrsur]

is this turing complete and comparable to ethereum.org?

[CIYAM]

is this turing complete and comparable to ethereum.org?

Yes AT is Turing complete and is already live on Burst (the first "mainnet" to be able to offer Smart Contracts which has been made possible through its use of AT).

It is expected that AT will be included in Qora soon and that then the world's first "atomic cross-chain transfer" between two different blockchains will be able to take place (using the ACCT AT we have already written).

This should be the basis for a completely decentralised exchange for cryptos (i.e. no trusted parties or servers). Understand that this only applies for trading cryptos for cryptos (not fiat).

[Gyrsur]

thank you! I want to know about how secure is such a decentralized turing complete system in the wild.

[CIYAM]

thank you! I want to know about how secure is such a decentralized turing complete system in the wild.

It is running now on Burst and we have so far seen no problems. What issues in particular are of concern?

[Gyrsur]

thank you! I want to know about how secure is such a decentralized turing complete system in the wild.

It is running now on Burst and we have so far seen no problems. What issues in particular are of concern?

an attack to recurrence ability because resources are not infinite.

[CIYAM]

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 as ATs work like "transactions" with funds needed to run them and fixed limits as to how many steps can be run per block)

[Gyrsur]

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! 

[CIYAM]

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

[burstcoin]

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.

[fastBeast]

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!

[CIYAM]

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.

[unsoindovo]

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

[CIYAM]

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.

[CIYAM]

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.

[burstcoin]

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.

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.

[CIYAM]

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