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

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!

This is really cool.

Interesting idea.  Keep a good handle on the quality control please.

NXT is awesome!  keep up the great work.

Any chance for a 12th API?
In order to implement NXTcoin functionality, I need to be able to transfer NXT AE Assets.
I will wait until after first release to ask for full AE API

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

The 32K program I have written *is* brand new and designed to suit our needs (and unfortunately nothing in this world is perfect). The reason it is written in C++ is because that is my preferred language but it won't be a difficult job to translate it to Java (it is currently around 1,500 lines).


Basically the "byte code" includes a few special "function call" ops which will support the creation of an API that the AT will have access to. At this stage some API functions will be to check received transactions and send NXT but if deemed useful I then other functions such as hashing ones could easily be added.

It is also wonderful,in addition to be interested.

If it's only 32K why don't we develope something brand new that perfectly suits our needs?

With optcode thats too low level i see some problems.
Interpreting such code will be slower because it takes longer to interpret many short commands, than to interpret a single long command (assuming optcode in both cases). Especially if you have to count every single command, and check you did not exceed the command limit.
Many small commands also require more space what makes these transactions larger.
In this case i think something that has commands that can directly handle strings, arrays, hashing, encryption and signature functions would be great.
This could be done by a bytecode interpreter as well (we could have bytecode commands that can handle this stuff directly).

I would be interested in creating a concept and code that. But i am a noob in Java so my code might not look that professional.

My plan is to have the community gateways peer review external website data, eg. order books for cryptos, stocks, forex, etc. when there is consensus between the gateways, one of them (blocknumber mod 5) would post a broadcast AM. At 0.1 NXT per AM, that is about 100NXT per day, or 20 NXT per gateway per day. People that want to use this data feed would pay a small subscription fee. To bootstrap it, NXTcommunityfund will pay the costs at first to create an installed base of subscribers.

Not sure how best to authenticate totally securely. Ideally there is a way to do this, but a fallback is for the community gateways to monitor all broadcast feed AM (they will need to do this anyway to verify each other) to make sure Evil Bob isnt up to his dirty tricks. So, until it is peer verified the AM could be tainted. If such a block is found all 5 gateways would spew out AM to invalidate the tainted AM.

using that model, we can have a one block behind validated data stream within AT. It needs to make sure there are no gateway objections and then it uses the previous block's AM data for the broadcast feed. Once this mechanism is setup, it is a simple matter of encoding a datafeed ID and then a whole variety of AT's can be created using whichever datafeed ID it wants.

James

P.S. If the above process works, I dont see why we cant have the gateways verify transactions using blockchain.info also cross checked with locally running bitcoind for BTC deposit/withdrawals.

That's fantastic!!
I am in contact with subleq creators and offered them the project to port their C compiler to NXT AT.

The definition of subleq is "A B C which are memory addresses. Execution of one instruction A B C subtracts the value of memory in A from the content of memory in B, depositing the result in address B. If value after subtraction in B less or equal to zero, then execution jumps to the address C; otherwise to the next instruction."

Yes, I believe your code does what subleq needs. Not sure if we need to bother with a C compiler that takes advantage of all the NXT assembler opcodes. Certainly not at first.

Thank you for the help!

James

I don't know how stable you will be able to make something but an AT would be able to make decisions based upon AMs that are sent to it.

Understand that the AT would have to check the sender of the AM in order to decide whether or not it should be trusted and also understand that in order to continually run an AT needs to be "fed" (i.e. they aren't going to be running for free).

So I think we are talking about the following:


Thus an instruction that will require three addresses (the first two being data addresses and the last being a code address).

I will add it and even give it the auspicious op code number 0x88 137. How about that?

1) Could machine readable news be utilized for price feeds?


2) Could you have one asset trade against another asset in a manner which if one were to decrease the other would increase?


3) If the above is yes for both questions, could you then have another asset pegged to the above two in an automated manner.


This would offer a stable fixed price based on real world information....I could be way off on this.

very cool CIYAM. highly interested in building distributed applications on top of this,
able to collect, aggregate and publish informations via AM and blockchain.
very good think tank here, we should collect as many ideas as possible.

If AM's can be accessed and written by AT, then I am much gratefulness. Also, if you can make sure that it is possible to have an opcode(s) that is equivalent to subleq, then I can get a small C compiler done without much work. Of course, it will be totally inefficient, but if someone is lazy and doesnt want to write assembler, they will just pay extra. For AT that are simple control flow based on AM data (most of my ideas are in this area), even 10 times bloat is OK for testing.

I am assuming that after AT 1.0, it will be possible to get more and more of the NXT blockchain data accessible within AT. The more people can use as input, the more will be possible. Will I get in trouble for asking the AT to be able to do AE operations, at least for some near future version?

I envision the workflow to be that I would write a C program that generates impossible to read subleqs, but I dont care at first because I just want the logic of the AT to be right. It is the compilers job to do that. Then after the logic is all debugged and if cost is an issue (it might not be if it is a rarely invoked AT), then I can write hand optimized assembler.

[Actually, there is a consulting business for someone here, to port C into AT assembler. Just trying to come up with as many ways as possible for people to be able to make a living with NXT]

James

P.S. Please dont hate me for wanting a C compiler with subleq. Once I get a C compiler, I can write a LOT of code myself, which will allow me to just create the entire solution, not just the incessant posts, so it really is in everyone's interest to get subleq

I am in the process of writing up a "specification" for AT which will include 3 use cases and which I hope I can finish by the end of the week.

One decision that is pretty much set in stone is that we "will roll our own machine language" (yes I know some are going to not like this). The reason is that we don't want to bloat the NRS with a language that is any more powerful than it needs to be and the project sponsor is keen to have this project completed by April.

I did consider Lua but being written in C and not so small (over 200K of source) I think the time that would have to be spent on getting it to work in Java would be time that could be better spent on other things so I have whipped up a small VM that is around 32K of very easy to follow C++ which I will get the Java developer to translate (which shouldn't take much more than a day I would think).

For those unhappy - give me Lua in a single file that is less than 40K of readable C++ (not C) and I'll reconsider.

Another thing to realise is that these programs really have to be "tiny" and use "tiny amounts of memory" otherwise they would *kill* Nxt. So languages that have been designed for modern general purpose applications are usually not so handy when you have limitations such as 1000 bytes of memory.

good

Think of the name AT just as a "project name" rather than being any intended suggestion for marketing.

Also I think our brains (or at least my own) are nearly exploding with what are considering already.

I didn't mean that. I thought we limit the discussion / our brains and the marketing potential if we chose this name.

But go ahead, people. Just wanted to write my impression on this.

Okay - I will give some thought to the idea of an Auction AT.