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

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

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


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

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

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


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

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.

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.

hell yeah!

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

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!

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.

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

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.

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.

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

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

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

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

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


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

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

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.

Oops - got my math way off - anyway CfB wants to allow for a potentially huge # of txs per block so I guess even 2^20 would be more than enough (I'll let him decide the exact #).


The creation transaction would trigger execution provided that enough fees have been paid (as there may be some cases where you don't want the AT to immediately run).

After that any tx sent to the AT's account would trigger further execution (there might have to be a higher minimum fee for txs sent to ATs to make this work properly).

As well as providing the AT with its "juice to run" special txs such as AMs can be used to "communicate" with the AT (I've coded this into the Dormant Funds Transfer use case sol that an AM from the AT's creator can be used to change the "output" account).


I probably should have used "creator" rather than "owner" but in any case I think that the AT will have its "own" account (which could be derived from a hash of its byte code) which will be given an initial balance by the creator.

Also I think that the "creator" would be able to assign the forging rights of the AT unless the AT will be able to that itself (actually it is probably a better idea if it could do that itself).

I think it could make things a little easier for the AT to be able to identify its creator via an API function but in practice the creator's account could just as easily be hard-coded into the AT itself.

Sounds good!

2^24 tx per block= 16777216 tx per block or approx. 279620 txs per sceond?

May i ask what events in the blockchain can trigger the execution of the AT code?

Is the "AT owner's account" a usual account that can not control its funds after the AT has been activated? Instead only the AT can access its funds?
Do i get this right?