Really - so the person with the most "alts" wins!

A very easy thing to write - but actually *impossible* to create unless your idea of a fair vote is say "proof of stake" (which means the people with the most Bitcoins win the vote) or perhaps "proof of work" (in which case those with the most powerful mining devices win).

You could do either of those but my guess is that you'll find most people are likely to think that a "fair vote" should be 1 vote per person. Just one snag with that though - there is simply no way to do that online!

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

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

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

An important qualification - and I hope we are going to employ someone with the appropriate ability and reputation to audit this (I have already said I would contribute 5 BTC towards this).

For those not following the AT topic that might still be interested:

http://ciyam.org/nxt/

It is still a work in progress but at least you can see that progress is being made (I know that in Nxt land progress is generally measured in days rather than weeks or months).

We have already come up with some interesting ideas beyond the two current use cases such as a "Term Deposit" AT that would earn you NXT by leasing your forging power for x blocks then return the initial balance + forging interest to you and I think James will probably blow everyone's mind with some of his ideas.

The more I look at the flexibility of the Nxt design the more I think it really is the "next" thing. I just hope that TF can be proven to have no attack vector (beyond a 90% stake ownership one).

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

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/

Yes- fair point.


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.

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

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

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

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.

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

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

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.

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 a quick update to let you know how things are progressing.

I have been focused on the "virtual computer", the AT API (i.e. the functions that an AT will use to get access to Nxt info) and the first two use cases.

Prototypes for the Lottery and Dormant Funds Transfer (aka "dead man's switch") have been written in NxtAT machine code with the former having been checked with test data (I will do the same for the latter tomorrow).

Both programs come in at under 500 bytes and require less than 160 bytes of memory (which I think is pretty good).

The instruction set I have come up with is 39 op codes so far (including the SUB_LEQ one for James) and the C++ NxtAT machine emulator has been extended to be able to use test data for returning values from the pseudo API function calls (this should make it easier to create test cases).

The 11 API functions that so far comprise the AT API (in order to satisfy the two test cases) are as follows:

01. get a time stamp value for the last block in the blockchain
02. get txid for the first tx after the provided time stamp
03. get a time stamp value for a given txid
04. get ticket for a given txid
05. get source account for a given txid
06. get balance of own account
07. pay account balance to a given account
08. get NXT amount for a given txid
09. get tx type and subtype for a given txid
10. get the AT owner's account
11. get first 64 bits of AM data

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

Also the "ticket" will be the lower 64 bits of an SHA256 hash of the tx id after the block id of the block 1440 blocks in the future is added to it (if no such block exists it will return 0).

It may seem odd to have an API function for a "ticket" but I get the feeling that there might be more than one type of "game" that will want this functionality (so seems better to just have an API for it rather than needing more byte codes and API functions).