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

[CIYAM]

I think it would be wise to implement more triggers to AT execution later, like appeareance of a new block with a specific block height (number).

I think we could consider the idea that an AT could "stop" for X blocks then continue as we are already going to have to consider the idea that AT execution might have to carry over from one block to the next (this will need some thought).

Currently i am not forging with my main stake because i fear losing it when my computer gets compromised.
Probably AT provide a solution to that, where i can forge with my computer while my NXT are in cold storage.
Even if a hacker steals my forging rights from my computer i can recover them with my paper wallet.

I guess a twist on the Dormant Funds Transfer would be that provided the AT could grant its own forging power to a pool (or perhaps its creator would do this - not sure about this yet) then your funds could earn you interest with their final account destination being an account whose private key was created offline (you would want to make sure that the public key for the account is known in the blockchain of course as the account # would be *visible*).

[Fry]

What could probalbly be considered as well is the use of iTAN (Indexed Transaction authentication number) for access to the dormant funds.
These TAN numbers would have much more than 4 digits, more likely 20 or 30 or so, but it would definitely increase security.

EDIT: Transactions that are authenticated with a iTAN would have a transaction Limit

[CIYAM]

...iTAN (Indexed Transaction authentication number)...

I am not familiar with this iTAN idea - was it discussed somewhere else?

[bitcoinpaul]

...iTAN (Indexed Transaction authentication number)...

I am not familiar with this iTAN idea - was it discussed somewhere else?

It's a secure mechanism of real life online banking.

http://en.wikipedia.org/wiki/Transaction_authentication_number#Indexed_TAN_.28iTAN.29

[CIYAM]

It's a secure mechanism of real life online banking.

Thanks (hadn't come across that term before) but I don't think that would be possible as an AT has no way to hide secret data.

[Fry]

...iTAN (Indexed Transaction authentication number)...

I am not familiar with this iTAN idea - was it discussed somewhere else?

No, it wasn't discussed before, it just came to my mind. This is used by Banks.
I try to explain it:
Like a paperwallet you have several keys on a piece of paper (Cold storage).
My Bank has 5 digit numbers, every number can be used for one transaction, after that never again.
When all numbers on a sheet have been used, my Bank sends me a new sheet with new iTANs.

This can be also done with ATs.
But with 5 digit numbers it will not work. My Bank will lock me, when i entered a false iTAN.
In ATs it's not that easy. Because i can see what the AT is doing.
So every iTAN has to be longer - let's say 30 digits.
The hashs of every single iTAN could be safed in the AT.
When i want to transfer from the dormant AT i have to provide one iTAN. The AT can check it against it's hash list only if it's valid it will transfer the funds.
If someone has compromised my computer he probably might steal on iTAN (example: he is running an keylogger while i enter it), but he cannot steal all my funds because the AT will only send funds up to a previous set limit for one iTAN.

So it's a safer Paperwallet.

[CIYAM]

The hashs of every single iTAN could be safed in the AT.

Okay - now I see where you are coming from. I guess as long as we have an AT API command that returns the hash value then this should be straight forward.

Bear in mind data size will "cost you" so you wouldn't want to have too many of these TAN's in the AT (for this reason I'd probably use no more than 128 bits of say an SHA256 hash).

[Fry]

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.

[klee]

Hi all,

I have good news - neer.g will help this effort too with 500K NXT!!!

neer.g thank you very much for your contribution, the early adopters united can make Ethereum dead on arrival!

[CIYAM]

So i only have to save the hash of the first TAN in the AT.

Am not quite following how that would work sorry - perhaps you could show me with an actual example using say MD5?

[bitcoinpaul]

Hi all,

I have good news - neer.g will help this effort too with 500K NXT!!!

neer.g thank you very much for your contribution, the early adopters united can make Ethereum dead on arrival!

hell yeah!

[klee]

...the early adopters united can make Ethereum dead on arrival!

Just a handful of you have made most crypto obsolete already!   

[Zahlen]

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.

[jl777]

In order to implement NXTcoin functionality, I need to be able to transfer NXT AE Assets.

Am not clear what you mean by "transfer" - can you give me the exact Nxt API function call (I am guessing it is probably not going to be a simple as 1 call)?

I have now finished basic testing of the Dormant Account Transfer AT and in doing so I've realised that we could use a simplified version of it to act as a "term savings" account assuming that we allow the AT creator to be able to transfer its forging rights.

In this way your NXT could be locked up for say 6 months earning interest for you just like at a bank!

Just one call.
http://wiki.nxtcrypto.org/wiki/Nxt_API#Transfer_asset
Transfer asset[edit]
Used to transfer a quantity of asset from one account to another

Request[edit]
http://localhost:7874/nxt?
     requestType=transferAsset&
     secretPhrase=SECRET&
     recipient=ACCOUNT&
     asset=ASSETID&
     quantity=QTY&
     fee=FEE&
     deadline=DEADLINE&
     referencedTransaction=REFTXID
Where:

SECRET is the secret passphrase of the account transferring the asset
RECIPIENT is the recipient account number
ASSETID is the ID for the asset being transferred
QTY is the amount of the asset being transferred
FEE is the fee for the transaction
DEADLINE is the deadline for the transaction to get a confirmation, expressed in minutes
REFTXID is a previous transaction ID that you want to reference. This creates a chained transaction, meaning that the current transaction cannot be confirmed unless the referenced transaction is also confirmed. Optional parameter.
'Response'[edit]
{
     "transactionId":       "TXID"
}

Also, one more API call? It is really important that AT be able to write an AM. Otherwise it wont be possible to save any state information across invocations.

[CIYAM]

RECIPIENT is the recipient account number
ASSETID is the ID for the asset being transferred
QTY is the amount of the asset being transferred

Hmm... will have to think about having so my args (max. of two are allowed) - am guessing what would have to be done is to place the values in consecutive addresses and pass the function the first address (and maybe the number of args for safety).

Also, one more API call? It is really important that AT be able to write an AM. Otherwise it wont be possible to save any state information across invocations.

All state is saved so no need to use AM for that (although most likely an API for sending an AM will be added even in the initial version).

[CIYAM]

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

Actually I think a much simpler approach could be used.

Just send a new TAN hash along with your TAN in the AM (the AT data state is persistent).

[Fry]

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

Actually I think a much simpler approach could be used.

Just send a new TAN hash along with your TAN in the AM (the AT data state is persistent).

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

<?php
echo "Tan 4: " . md5("Secret Key"). "<br>";;
echo "Tan 3: " . md5(md5("Secret Key",true)) . "<br>";
echo "Tan 2: " . md5(md5(md5("Secret Key",true),true)) . "<br>";
echo "Tan 1: " . md5(md5(md5(md5("Secret Key",true),true),true)) . "<br>";
echo "Hash delivered in AT: " . md5(md5(md5(md5(md5("Secret Key",true),true),true),true)) . "<br>";
?>


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

To check wheather the delivered Tan is vaild, the delivered Tan has to be hashed several times. When it results in the "Hash delivered in AT" then the TAN is valid.

But the first TAN you use is the first TAN. Because if you deliver TAN 4 then all other TANs will be known.

EDIT: TAN5=Secret Key

[CIYAM]

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.

[CIYAM]

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/

[Fry]

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!

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