Nxt :: Automated Transactions (AT) - progress and discussion - page 3.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Zahlen on February 20, 2014, 08:18:52 PM

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 Grin

)

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

Fry

newbie

Activity: 45

Merit: 0

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?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Zahlen on February 20, 2014, 11:46:22 PM

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

Zahlen

member

Activity: 98

Merit: 10

Quote from: CIYAM on February 20, 2014, 11:34:21 PM

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

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

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

Fry

newbie

Activity: 45

Merit: 0

@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

Zahlen

member

Activity: 98

Merit: 10

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 Grin

)

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

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

hill

member

Activity: 68

Merit: 10

+1

Zahlen

member

Activity: 98

Merit: 10

Quote from: CIYAM on February 19, 2014, 11:59:47 AM

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 *

ChuckOne

sr. member

Activity: 364

Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82

Quote from: CIYAM on February 19, 2014, 12:06:38 PM

Quote from: ChuckOne on February 19, 2014, 12:03:30 PM

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

Sometimes, news spread slowly.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: ChuckOne on February 19, 2014, 12:03:30 PM

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

sr. member

Activity: 364

Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82

Quote from: CIYAM on February 19, 2014, 08:37:02 AM

Quote from: Fry on February 19, 2014, 08:08:46 AM

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

Yes- fair point.

Quote from: Fry on February 19, 2014, 08:08:46 AM

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.

ChuckOne

sr. member

Activity: 364

Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82

Quote from: Zahlen on February 19, 2014, 06:58:54 AM

Quote from: Fry on February 19, 2014, 06:11:39 AM

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.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Zahlen on February 19, 2014, 11:50:15 AM

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!

Zahlen

member

Activity: 98

Merit: 10

Sorry Fry, I got it the wrong way round.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Fry on February 19, 2014, 09:32:45 AM

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.

Fry

newbie

Activity: 45

Merit: 0

Quote from: CIYAM on February 19, 2014, 08:37:02 AM

Quote from: Fry on February 19, 2014, 08:08:46 AM

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

Yes- fair point.

Quote from: Fry on February 19, 2014, 08:08:46 AM

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!

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

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Although not complete yet here is a preview of the specification, use cases and the sample .cpp program for testing the use cases.

http://ciyam.org/nxt/

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Fry on February 19, 2014, 08:08:46 AM

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

Yes- fair point.

Quote from: Fry on February 19, 2014, 08:08:46 AM

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.

Topic: Nxt :: Automated Transactions (AT) - progress and discussion - page 3. (Read 17307 times)