Nxt :: Automated Transactions (AT) - progress and discussion

[CIYAM]

There is no need for AT to know "Secret Key". I think we mean the same!

Okay - I must have misread your hash values (as I couldn't get one from the other) - but yes it is a neat method.

[Zahlen]

Sorry Fry, I got it the wrong way round.

[CIYAM]

Sorry Fry, I got it the wrong way round.

It's fine - we have created something very interesting - hopefully we can get a few more such great ideas happening here!

[ChuckOne]

This can even be further optimized on memory usage.
1. TAN = Hash(2. TAN)
2. TAN = Hash(3. TAN)
3. TAN = Hash(4. TAN)
...
30. TAN = Hash(whatever)

So i only have to save the hash of the first TAN in the AT.
If for example the 7. TAN is provided, it has to be hashed 7 times and will result in hash of first TAN.

This is a very nice idea! What Fry means is the user first supplies 30. TAN to the AT to access the account the AT is running on for the first time. AT checks that 30. TAN is valid by hashing it 29 times. After that, AT increments TAN_count by 1. Subsequently, AT will hash the user supplied TAN 29 - TAN_count times. Once TAN_count = 29 and 1. TAN is supplied, the AT considers all TANs to be used up.

Since the size of hashes might be small, rainbow attacks could be feasible, to guard against that, you could do e.g. n-1. TAN = Hash(n. TAN  XOR  Salt), where Salt could be e.g. account number.


EDIT: Hmm, but one problem: If an attacker somehow acquires n. TAN, then he gains all of n-1. TAN to 1. TAN.

Agree. Salt should be added one way or another.

[ChuckOne]

But then a hacker could send a new hash as well we he has stolen a TAN sucessfully.

Yes- fair point.

Tan 4: 5eb6bb157528b365f84c27bb4784031b
Tan 3: 60639a308365b50c6f531b0b05018210
Tan 2: 56600d988bbaa252ac565d57dd1fc686
Tan 1: 0355f7b531a7ccc9d4287b664f1da644
Hash delivered in AT: e2603ffd11ae2f4fce1aa84cb461f6d5

That doesn't work as the AT would need to know "Secret Key" but I think if we just simplify it then it will work:

md5(secret) = 5ebe2294ecd0e0f08eab7690d2a6ee69
md5(5ebe2294ecd0e0f08eab7690d2a6ee69) = 7022cd14c42ff272619d6beacdc9ffde
md5(7022cd14c42ff272619d6beacdc9ffde) = 19ff59e135cce19e3493402cb3884628
md5(19ff59e135cce19e3493402cb3884628) = b61a3c39ea31f66f0adf883bbc154786

So we give the AT b61a3c39ea31f66f0adf883bbc154786 and the the 1st TAN is 7022cd14c42ff272619d6beacdc9ffde (which we hash and verify) and change the AT's state to say that it is *used* (basically increment the # of hashes counter).

So the next TAN is now 5ebe2294ecd0e0f08eab7690d2a6ee69 which we hash twice and get back to our b61a3c39ea31f66f0adf883bbc154786 value, etc.

The trick being of course that you can't reverse the hash - I like it a lot!

Actually the CIYAM Open "client-side crypto" works in the same sort of way. Your "password" hash is hashed with a unique id to create an initial "one time pad" which is then extended to the length required by rehashing.

Just wanted do add: don't use MD5 if nobody else had already mentioned it.

[CIYAM]

Just wanted do add: don't use MD5 if nobody else had already mentioned it.

Of course MD5 was only being used as a simplistic example - most likely the hash function would be SHA256 or similar (but we will have to consider whether to use 256 bits or less as that will eat up precious data bytes).

[ChuckOne]

Just wanted do add: don't use MD5 if nobody else had already mentioned it.

Of course MD5 was only being used as a simplistic example - most likely the hash function would be SHA256 or similar (but we will have to consider whether to use 256 bits or less as that will eat up precious data bytes).

Just to get sure. Sometimes, news spread slowly.

[Zahlen]

It's fine - we have created something very interesting - hopefully we can get a few more such great ideas happening here!

This is where it's AT!

* Dodges rotten vegetables *

[hill]

+1

[CIYAM]

@Fry - actually your neat hash idea can be implemented better by replacing the "expected" hash value with the TAN after verification. This would mean that the AT would only ever be doing a single hash per TAN that you send.

So you could generate as many TANs as you like with the "cost per TAN" being the same!

[Zahlen]

Just read the spec document, was a pleasure to read. Wish more devs (and mathematicians!) would write as clearly and explain motivations like you do.

Some thoughts about the op codes:

1) Would it be useful to have a pause code and a resume code? Maybe for event handling, e.g. onAMReceived() { resume; } ? (Is running out funds the only way to pause a running script?)

2) A note for James: subleq isn't exactly 0x89 SUB_LEQ, it's actually
@addr1 -= $addr2, if $addr1 <= 0 then pc = addr3,    rather than  pc += $addr3 . James, you'll need to compose it with additional instructions to have it match up with the subleq used in the example C++ libraries.

(This must be Ian's plan to slow subleq even further )

[Fry]

@CIYAM Open I have read the spec document now.
Some suggestions from me:
I would rather like to see some event handling than this blocking with Sleep_Until_Creator or Sleep_For_Blocks or when the script is running out of coins.
The AT running out of coins should be the exception, and not a regular used mechanism. Otherwise in some usecases you don't know how long the script will actually run, so you have to send more coins to it just to keep it in a loop later.
If event handling is used then there also is no need to keep all data persistent, remember that all persistent data will need to be copied about a dozen times with every new block creation.
Here's a example AT with event handling.:


register event handler "block 1000 apeared" :block1000
register event handler "AT received coins" :newcoins
end

:block1000
'do what needs to be done when block 1000 appears
end

:newcoins
'do what needs to be done when at the AT account gets new coins
end

[CIYAM]

@Zahlen and @Fry thanks for taking the time to read the spec. and comment.

I had thought about "events" but am worried it will complicate the design also I think that the functionality you are wanting can be achieved without too much coding effort. Consider this (taken from the Dormant Funds Transfer use case):

Code:

:loop
get tx at after @timestamp and store in @txid
if @txid is zero finish
get timestamp for @txid and store in @tx_time
get tx type for @txid and store in @tx_info
if @tx_info != @am_type_subtype goto skip

So although the basic rule is that for the "event to run" a tx is sent to the AT with enough fees to pay for execution (unless it is in hibernation) the API functions will make it easy enough for the AT to determine what kind of tx has arrived and therefore what to do about it (you could create a bunch of subroutines which are called according to the @am_type_subtype or according to data in an AM, etc.).

Understand also that the hibernation idea is simply for an AT to be able to "save wasted cycles" as even if execution is being paid for there is no point in it just checking the block height and stopping.

In regards to "subleq" I thought it was doing what I had read but if it isn't then don't worry James - it can easily be fixed up.

[Zahlen]

Code:

:loop
get tx at after @timestamp and store in @txid
if @txid is zero finish
get timestamp for @txid and store in @tx_time
get tx type for @txid and store in @tx_info
if @tx_info != @am_type_subtype goto skip

But this way requires the script to be constantly polling for "triggers" (here am_type_subtype), which will require extra cycles (and hence cost) right? (Or would the extra cost be negligible?)

I was thinking that instead of pausing/sleeping for a predetermined period, during which the script can't execute and can't poll, you could have some mechanism that allow triggers to wake up the script (or at least run a function that checks whether the trigger is something valid for the script to wake up for).

[CIYAM]

But this way requires the script to be constantly polling for "triggers" (here am_type_subtype), which will require extra cycles (and hence cost) right? (Or would the extra cost be negligible?)

Indeed the normal thing for an AT to do *is* to poll for triggers, as transactions (which *are* its events) are exactly what drives it, so I don't really see that as "wasting cycles".

The idea of the hibernation is just to stop it polling completely until a given block height (as I think that could be reasonable for some use cases). There might also be a case for being able to send an AT NXT without letting it execute code (will have to think about this as you wouldn't want the AT to be easily starved).

It might also make sense to have an AT "priority" setting (a bit like task priority) so that lower priority ATs might only be run at most every X blocks.

Although obviously a lot of careful measuring will need to be performed at the testnet stage the design itself is aimed at being very minimal in "cost" (current use cases would require no more than 1K of memory and would only need to execute 5..10 instructions per "poll".

[Fry]

Do i get this right, everytime a new transaction comes in, the AT is beeing executed from the beginning, but the memory is at the state where it ended last time?

From where is execution time purchased from the ATs XNTs or from a fee in the incoming transaction?

[jl777]

Just read the spec document, was a pleasure to read. Wish more devs (and mathematicians!) would write as clearly and explain motivations like you do.

Some thoughts about the op codes:

1) Would it be useful to have a pause code and a resume code? Maybe for event handling, e.g. onAMReceived() { resume; } ? (Is running out funds the only way to pause a running script?)

2) A note for James: subleq isn't exactly 0x89 SUB_LEQ, it's actually
@addr1 -= $addr2, if $addr1 <= 0 then pc = addr3,    rather than  pc += $addr3 . James, you'll need to compose it with additional instructions to have it match up with the subleq used in the example C++ libraries.

(This must be Ian's plan to slow subleq even further )

I missed that. Hopefully I wont have to pay double for all the subleqs. It will be so inefficient as it is. I just want a C compiler out of the box, which is my only motivation for subleq

[CIYAM]

After some consideration I am now thinking that a simple "crowd funding" AT could be a better 3rd use case (I was considering an "auction" but it seems to me the VS could probably handle that with some very minor modifications).

The idea would be that this AT would check its balance after n blocks (so it would be a good candidate to use the "sleep until block X") and if it is >= X then it would send all its funds to account Y (being the "project's account") otherwise it would iterate through all the txs it had received and refund the amount back to the sender (minus a small amount to run itself).

What do you guys think?

Do i get this right, everytime a new transaction comes in, the AT is beeing executed from the beginning, but the memory is at the state where it ended last time?

Pretty much although it actually depends how it had halted - if it had finished running (or reached a "finish" op) then yes it does that but if it hit a "stop" op (or it was halted due to lack of funds) then it continues from that point rather than from the start.

From where is execution time purchased from the ATs XNTs or from a fee in the incoming transaction?

The execution time is in accordance with the AT's balance although a fee (possible mandatory) will cover a small amount of execution (so an AM would actually trigger execution).

[Fry]

I think it would be nice to have the possibility to execute the AT at a specific block height (Time) without the need for a incoming transaction to that AT.

[CIYAM]

I missed that. Hopefully I wont have to pay double for all the subleqs.

Strange, I wrote it in the spec as state.pc += $addr3 but didn't actually code it that way in the prototype - anyway I've changed the code (locally for now but will republish soon) to the following:

Code:

                  if( state.jumps.count( state.pc + addr3 ) )
                     state.pc += addr3;

so this ought to be the "subleq" you were expecting James.

I think it would be nice to have the possibility to execute the AT at a specific block height (Time) without the need for a incoming transaction to that AT.

Agreed - so I think part of the AT "header" will include an "execute at" block # (or approx. time). Another related idea is that if an AT is currently hibernating then the extra fee required for sending a tx to an AT (to allow it to execute a minimum # of steps) would be instead added to the AT's balance (i.e. so it is paying for those steps to be executed later).