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.

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?

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.

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.

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

It will be a "Turing complete" language but it will not be able to do much other than examine the blockchain and create transactions so I think Automated Transactions is really "the main point".

If you are thinking that these scripts are going to be sending emails or the like the you have the "wrong idea" about what is being proposed here.

As we are going to end up needing a higher level language above the low-level "assembler" like language we could use that name for it. Good enough?


Hmm... I guess that could work through the use of AM although I wasn't planning on trying to handle AM initially but if enough people are keen on that (I know that James is) then maybe I can work that into a 3rd "use case".

Note that I've changed the title of this topic - unless we come up with a better name I think Automated Transactions (AT) is what we are going to use (as it fits in nicely along AC, AE, AM, and AS).

Having some sort of AM "data feed" would be fine (and at least it would be clear that you are having to trust whoever created it). I'm not quite sure how an AT (Automated Transaction) would "find" the AM but assuming that it could somehow be done via an API call then it should be possible for AT to use such data.

At this stage the only two "use cases" that are being considered are 1) Lottery and 2) Inactive Account Payout. A third use case would need to be no more complicated than either of those for consideration at this stage (we need to walk before we can run).

Something that works with AE could be doable - but it would need to be a really simple bot (so tying in it with AM as well is going too far IMO).

I think you've already brought that up before and it has already been answered before but I'll answer it again in the hope that you might remember it for next time.

You cannot prove anything outside of the blockchain as their is no true way to achieve consensus about that - if you are wanting to say "check the result of a Google search" then every node would have to do the same search and get the same result to "confirm" it *but* in practice they will not get the same result (some might just get an error due to the IP being blocked or some might get a different result due to geographic location, etc., etc.).

Also you would be putting a "huge" burden on every node to have to be doing an arbitrary number of perhaps slow or costly requests just to attempt said verification.

It isn't going to happen James - so please just drop it.

I think it would be a potential use case although it would need likely need a large amount of NXT to even get close to "pegging" the price.

Indeed it would be great but unfortunately the very nature of TF makes this rather tricky.

We have decided to employ the help of a math expert to study what we have come up with so far and work out whether or not it is going to be close enough to random.

Clearly the problem of Mt. Gox is hurting the Bitcoin community - yet they still keep trading (a month or so ago they were > 10% above the price of other exchanges as people couldn't get USD out and now they are nearly < 50% below other exchanges because people can't get BTC out).

Wouldn't it be best for the whole community if they just suspended trading until they fix up their software problems?

I think that Mt. Gox is not at all providing *leadership* here but instead is just providing fuel for the conspiracy theorists.

Really?

In that case I think we have met in several topics before.

As far as I know you can't make a tx with zero fee in Nxt (am I wrong?).

So if the forger forges a block with no txs what *exactly* is the problem?

Without some sort of mathematical proof I don't really see what we are talking about (and you could make the same point about PoW systems also as they could mine a block with 0 txs as has occurred many times before with Bitcoin).

These are actually *separate* things - you would need to create a "trust network" on *top* of the AE rather than *within in* as you wouldn't want any AE owner to be able to *manipulate* that "trust network".

Why? Here we see no explanation but just a statement of "fact" (or in other words "bullshit").


They seem to have overlooked the "penalty" for not forging here.

After some discussion CfB and myself are thinking that the best "random" data we can get is going to be the block id of the block 1440 blocks later than the block someone's "ticket" is purchased in the "lottery" (so the lottery would likely be a "weekly" event rather than a daily one).

What we'd really like to find is a "math guru" who could help us out with determining whether our approach will be "fair". If you are or you know any such "math guru" please let them know (there will be a reward provided the said person has the skills and the "rep").