Pages:
Author

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

Fry
newbie
Activity: 45
Merit: 0
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.

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

legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
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).
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
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).
legendary
Activity: 1176
Merit: 1132
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.
member
Activity: 98
Merit: 10
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.
legendary
Activity: 1498
Merit: 1000
...the early adopters united can make Ethereum dead on arrival!

Just a handful of you have made most crypto obsolete already!    Wink
Cool
hero member
Activity: 910
Merit: 1000
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!
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
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?
legendary
Activity: 1498
Merit: 1000
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!
Fry
newbie
Activity: 45
Merit: 0
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.
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
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
newbie
Activity: 45
Merit: 0
...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.
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
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.
hero member
Activity: 910
Merit: 1000
...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
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
...iTAN (Indexed Transaction authentication number)...

I am not familiar with this iTAN idea - was it discussed somewhere else?
Fry
newbie
Activity: 45
Merit: 0
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
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
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
newbie
Activity: 45
Merit: 0
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.
legendary
Activity: 1890
Merit: 1078
Ian Knowles - CIYAM Lead Developer
2^24 tx per block= 16777216 tx per block or approx. 279620 txs per sceond?

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

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

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

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?

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.
Fry
newbie
Activity: 45
Merit: 0
Sounds good!

Note that a "time stamp" is expected to include the transaction # (not id - I mean # of the tx in the block). I have discussed this with CfB and that will likely be the lower 40 bits of a 64 bit "unix time" shifted to the left with the remaining 24 bits for the transaction # (allowing for a max. 640K txs per second which I am assured Bill Gates agrees we'll never need more than).
Huh Huh Huh 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?
Pages:
Jump to: