Bitcoin Forum

Thanks to @klee we have begun a project to enable "scripts" for Nxt which will provide a "Turing complete" method of executing code to do useful things such as "pay dividends to shareholders" of a Nxt Asset.

At this stage we are still "brainstorming" mostly and the code itself won't be publicly released until it is completed (we are aiming for the start of April to coincide with other important feature releases).

CfB and myself will be sharing technical lead on this project and will be working with a small focused team in order to get this done "right" and as "quickly as possible".

+1

Good luck and all the best to the everyone involved in this project!

+100

GREAT!  :)

Okay - let's get "stuck into it" (warning - this topic is going to include a lot of "technical" discussion).

So first and foremost we have the problem of "what kind of scripting language should we use"?

In considering this we have to understand that we don't wont Nxt nodes wasting large amounts of CPU cycles on scripts when there most important function is of course to process Nxt transactions.

For this reason a "high level" language does not seem suitable (too hard to control) and instead a "low level" language (like "assembly code") seems more appropriate (we can control each "execution step" with a "low-level language" and not get tricked into accidentally executing long loops).

Also we need this "low level language" to be able to directly (and safely) communicate with the NRS otherwise it would be pretty useless (take the initial "use case" of sending dividends to shareholders - you need to know a few things like the "balance" and the "list of shareholders" to do this).

So - is there an existing "low-level" language (close to if not assembly) that is suitable or do we need to "roll our own"?

I am not sure of the answer to this question and look forward to your input.

I think basing it on a well-known system like x86/x64 assembly would be terrific.  Coders know it and it's well-documented!

The main problem with x86/x64 is the number of op-codes - to keep things simple if we are going to consider an existing "machine code" language then it should probably be more minimal than those.

Thanks - yes - a RISC style approach is what I am thinking of also.

My thinking was that you might be able to get away with a SUBSET of the command set... but then you may lose Turing-completeness..?

I think the RISC approach is interesting, too!

Actually you'd be surprised - there is a "Turing complete" language that has only 1 op code (but I am not interested in trying to be "that minimal").

;D

Good luck for the project everyone. This will definitely kill most of competitors.

Have heard some good things about it - the main question is can we have effectively API (or BIOS if you like) type functions with it?

Here is a test:
- Write a script that can forge blocks.

Will anyone challenge this task? :)

I think he means that if our language is like Assembler then function calls - getLastBlock(), for example - are BIOS calls invoked via interruptions.

Only inside the sandbox with access only to blockchain data.

Hi,  CIYAM.
Seemly like a wonderful idea,
but, what is a nxt scripts？
I'm not familiar with it. Can U provide some essaies for it? ;D

It's a good timing to beat btc,hurry up guys

so

if you do this, will etherium be left with any technical advantage over nxt

also could you write a javascript implenentaion of nxt client....?

A simple example (in fact our first "use case") is a script (or perhaps more correctly termed a "program" as we are not actually going to be using a typical "script" language) that pays a dividend to the shareholders of an Asset.

So in pseudo code this might look something like the following:


I hope that isn't too confusing.

I think that I shouldn't have used the word "script" (anyone got a better name?).

Although we may well add some sort of "higher level" language later (which might look similar to some popular scripting languages) at this stage we are focused on something that will be much more primitive.

+1

At this stage I would expect function calls "to block" although there may be some special cases for async execution but I think that such cases would be very few (if any at all) as we need to have a "deterministic" system.

I love it. This would be very useful.
Does Nxt Scripts use Nxt fees in order to be used ?

Indeed - basically a transaction to "execute" a script will be charged per "step" of execution (we can't tell how long a script will run as they will be "Turing complete"). If the payer hasn't provided enough fees then the script effectively "stops" at whatever step it is currently on (and can be resumed at a later point in time if a new fee paying tx asks it to).

There are also most likely going to be some basic limits as to the max. number of "steps" that a single forger would have to execute otherwise some paying an enormous fee to an "infinite loop" script could bring the network to a grinding halt.

This could make Nxt forging very lucrative.

Certainly the amount of fees cannot be too trivial or the burden on the network would be too great so I'd expect such "scripts" will have to be fairly generous in order to function reasonably.

instructions

Hmm... don't think the marketing team would be jumping up and down about that.

Perhaps something like "Smart Transactions" might be a little "more catchy" (although I am not a marketing guy).

Scripting or Automation.

aaa I didn't think we want it as a marketing sounding, I thought it was to be as close as possible to what you will be doing:)

for marketing: Adaptive Layer

Now that does sound like something you'd hear from marketing. ;D

If you like living on the edge these days: "Malleable Operations" ;)

Indeed - btw - after some consideration the "use case" of the "dividend" doesn't actually seem to be a very good use case for scripting anyway (it could be done more efficiently with a special "pay to many" tx type).

So we are interested in some better use cases - a couple of ideas we have so far are:

1) A "lotto" in which the script contains the "hash" of a secret. People send funds to the script and then when the secret is revealed the funds are sent to the tx whose hash (or time stamp or combination) is closest.

2) A "dead man's switch" savings account that will send your funds to another account if you don't instruct it otherwise (say once per year).

Perhaps we could come up with something better than these as a more "compelling" use case to justify why we want to create such a script system?

a use case script:
create an account by a number of people sending parts of the passphrase to account A (i.e. someone creates an account address and stores somehow that lets say 3 users will send parts of a passphrase for creating a new account)
after account A receives the expected parts of the passphrases (in this case 3) it creates a new account address B (based on the 3 passphrases in the example)
when users want to instruct account B to send NXT to another account they have to pass the 3 passphrases and same instruction in between the 3 of them, i.e. passphrase + Transfer 1000NXT to 43214321)

stupid? semi stupid?  ;D

Well the problem is that a script can't "hide" anything (I am aware of some of the amazing new crypto ideas thanks to James but as of now they are not practical - nor will they be in the foreseeable short term future) so I don't think this is something it could be used for.

Another idea that has been suggested is a form of "hedging" where you might bet that Asset A is going to be worth more than Asset B at a certain time (or vice-versa).

Didn't think about the fact that it cannt hide.

Can an account be setup to be able to send NXT only when it receives same message from a combination of other accounts (3 in my example)?
If that's possible then is it possible to create the account with random generation password that password is not saved in the blockchain?

The "message" can only be another transaction - so I am not quite sure what you think can be achieved as any tx will be seen by the entire network.

Well that's fine that the message can be seen. If I am wasting your time please ignore me.

What I was thinking is:
We create an account with random passphrase, lets say address A.(if that's possible)
Create a script to allow the account with address A to transfer NXT when same messages from fixed number of account addresses are sent to that account A.
The addresses of these fixed accounts (say B,C,D) are listed in the script so if the account A received a message from an account address that is not part of the list of addresses it does nothing. If account A receives identical message from B and C and D (or maybe we can have a condition to be at least 2 of the accounts) then it does what the message suggests, i.e. Sent 10000 to account Z
This way we can have an account controlled from few people.

Am not ignoring you as you may have a very good idea (am just not sure yet).

Certainly a script should be able to have its "own account" so it should be possible for X people to send funds to that account (and in fact the script could possibly even decide who those should be).

So assuming we have such a script - what does it then *do* with its balance?

Is the idea that other txs will *instruct* it how to disperse its balance (maybe you could just tell me the "point" rather than the procedure)?

Yes. We can instruct how the balance will be disperse. The accounts that will decide how the balance will be managed will be fixed account addresses in the script and a condition if all accounts must "agree" or a % of them must agree or for certain transaction amount say 100nxt it will require X% to instruct" but for amounts higher it will require 100% to instruct.

So we have such an account that holds 10000NXT. Then we have in the script that only 4 accounts can instruct, these 4 accounts will be listed in the script. For transfers less than 100 we need 70% of the accounts to instruct for transfers above 100nxt we need 100% to instruct.
Then account 1, 2, 3 send instruction to the holding account to Send 50nxt To account Z and that's enough to complete a transaction for 50nxt from our main account to account Z.

I am sorry I suck in explanation!!! Maybe should write code in pseudo code to demonstrate it but programming all day drains me and would like to try talking haha

Edit: Sorry I just saw that you asked for the point. The point is that I am trying to make an account controlled by more than 1 person. So we can get as close to decentralized exchange as possible. Also if we can have an account controlled by instructions from other accounts we can have community funds controlled by few people etc..

It's okay - I think I *get* your idea now but let me just check - it is basically an "escrow" account which requires a majority vote to move funds?

yes

do we have escrow accounts implemented?! wow I didn't know :-[

Okay - am glad I worked that out - but am not sure if "scripts" are the right answer to that (as I think multi-sig txs are planned down the track).

true!! yeah no patience here to wait haha

Understood - but I think proper multi-sig txs would end up being "cheaper" than scripts (which is why I need better "use cases" for scripts).

Greetings,

Regarding "scripting" language take a look at the Arduino development language. This is a minimal subset of C which has a designer built in Java and complete tool chain.
http://arduino.cc/en/Reference/HomePage (http://arduino.cc/en/Reference/HomePage)
http://www.nongnu.org/avr-libc/user-manual/index.html (http://www.nongnu.org/avr-libc/user-manual/index.html)

Regarding use cases:
Kind of reminds me the Bitcoin payment protocol:
https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
Although I'm not 100% sure at the moment how to tie this together.

IMO, this isn't a new problem and its been solved many times before. I suggest checking out some of the scripting VM implementations out there first before reinventing the wheel -- unless you have an itch to scratch ;)

Given the above constraints and desired properties, I definitely recommend checking out and researching Lua as per Jack's suggestion -- it's lightweight, more performant than alternatives (eg. ruby, python), allows for a great deal of control and there's a very strong community behind it.

Since you're looking for some way to "instrument" opcode execution, maybe start with Lua as a base and modify its main interpreter loop. From there you can add hooks for whichever instruction that needs to be charged a fee. Lua also has a debug library that provides functions for hooking into the vm script execution. These primitives are used to implement debuggers and profilers but perhaps it can work for your use-case example too?

Another idea is to introduce new opcode primitives on top that better maps to the nxt transactions and actions you want to perform. If you look at Luajit as an example, it augmented its own custom bytecode along with Lua's which allowed it to apply some pretty impressive optimizations.

Thank u for ur answer.
I think I know what is nxt script that u want to create a host
(like V8)to execute some customized code(any protocols or rules) that user write.
Am I right?

That is a key part - also the idea is to have such code exist in the blockchain and to perhaps be run periodically.

Another use case we are considering is what is often called a "dead man's switch" - it would be a script whose purpose would be to move funds from one account to another (in case its owner has disappeared or forgotten their pass phrase).

Would it be possible to do the Following with these Scripts?
Forgers, Stakholders or some other trusted entitys post regulary what they think the current USD value of NXT is to the Blockchain.
The script Calculates somehow an average USD price.
The Script now uses its own funds to Buy and Sell an NXT Asset called USD at that price.
Which results in having an Asset USD that has a stable USD value without having a Counterparty Risks (at least as long as the Script has enough NXT to buy that USD Asset).
 

Crowdfunding could be done via Xtnd  8). Anon and I had a convo about it here: https://bitcointalk.org/index.php?topic=460343.msg5113720#msg5113720

There's one big piece missing though, can this be done?

dogecoin version of peercoin.  with scrypt and everything.  cause i'm cool

Although I'd probably need to know more details it would certainly be the kind of thing this would be able to handle (it could not have keys but instead would be presumably be "granted" control over the account of its issuer).

agreed

Well - one big snag with a "use case" that I think a few had hoped we would be able to do.

We were thinking of something like a Nxt "lottery" where you would send amounts to the "script" and after x amount of time it would pay out its balance to a "winner".

The problem is that it doesn't seem possible to get "random" data in Nxt. People can change txid's (due to malleability) and forgers can simply omit transactions including those that run the script making it impossible for such a lottery to be actually "fair". Also TF means that you can actually predict some hashes even in the future (was BCNext trying to tell us "not to gamble"?).

Perhaps there is something we haven't thought of yet to still make this possible so if anyone has a great idea about that please let us know!

no I know what you mean by "script"

I was just wondering independently could you write most of the nxt client in javascript

Of course that "could be done" as JavaScript is "Turing complete" but it is not an exercise that I would be interested in doing (debugging such scripting languages is a real PITA).

My proposal to solve this issue:
Add a field to every block in the blockchain. This field contains the ECDSA signature of the same field in the previous block (calculated with the forgers private Key).
Use this signature to seed the random function.

As I understand, the tx malleability in bitcoin is possible because the transaction id isn't being signed by the private key when doing ECDSA. Since Nxt is designed from the ground-up with its own protocol, why are tx id's still malleable?

If you design it so the tx id is part of the hash being ECDSA signed would this not address the malleability problem since changing the tx id at this point by an attacker would invalidate the ECDSA signature and consequently rejected by nodes?

If the lottery takes place over a long time, you could use info from a block that's generated a long time after lottery entries are no longer allowed, long enough to be essentially unpredictable.


Alternatively, this might be one way to do it. There's a flaw, I'll explain a patch to it later to keep the description simple.

1) Before the lottery starts, lottery starter chooses a hash function Hash() with range 0 to N-1 inclusive, and also picks a number OFFSET. He announces Hash, Hash(OFFSET) and the number of lottery winners publicly.

2) During the lottery, all lottery participants and the lottery starter each pick a different number l_i and announce it publicly in any order.

3) At the end of the lottery, lottery starter reveals OFFSET. Hash(l_i + OFFSET) is computed for all lottery participants and the lottery starter, and the winners are the participants whose hashes are closest to that of the lottery starter's in Z/N (i.e. regarding N-1 as "wrapping around" to 0).


If Hash is a strong hash function and if OFFSET is essentially uniform random from the perspective of the participants, then the lottery is fair, since the distribution of the Hash(l_i + OFFSET)s will be essentially uniform random and unpredictable before the lottery has ended. Any Evil Dave (note the space!) who waits until the last possible moment before announcing their l_ED so as to get as much info as possible about the other participants' l_i s can still do no better than making a random choice of l_ED.


The hitch is that this depends on OFFSET being difficult to predict. Consequently this depends on the lottery starter being competent and honest: they need to choose OFFSET sufficiently randomly, and not reveal it to any of the participants before the lottery has finished. But there is much lower burden for OFFSET to be difficult to predict than there is for the draw (all the Hash(l_i + OFFSET)) to be, since there's a large computation burden in order to make use of any bias in the distribution of OFFSET: If Evil Dave wants to find a favourable l_ED, he will need to compute Hash(l_i + OFFSET) for all participants i and all likely OFFSETs, whereas anyone verifying the lottery only needs to compute Hash(l_i + OFFSET) for all i and a fixed offset. Hash() could also be chosen to be many iterations of a common hash function.

So a way to adjust it without depending on the honesty of the lottery starter is, instead of having the lottery starter choose OFFSET, to have OFFSET be determined by the lottery participants in a difficult to predict way (not necessarily uniform random). OFFSET = sum of account numbers of all participants might work, if participants don't need to pre-register for the lottery.

@Fry - I like your thinking as the forger can't do anything to change that (other than not forge which results in the not allowed to forge for a while penalty), however, it still means that the forger at least knows this value and so might decide whether or not to include their own tx depending upon whether they win (effectively improving their odds vs. non-forgers).

@greatwolf - I am not sure of the exact reason for the malleability (perhaps it is due to the choice of a random value for the signature stuff?) but have been assured by CfB that this is the case. This type of malleability also exists in Bitcoin but it isn't the cause of the recent problems as only the private key holder can create a different but still valid signature by using a different random number (if you play with "signrawtransaction" you'll notice that each time you call it you end up with a result due to this behaviour).

@Zahlen - I had also started to think along those lines and it could work fairly for players other than in the "final" block. The problem in the final block is once again the forger can check whether or not their own tx will be a winner and if not simply omit it. In fact you could even end up with the lottery being stuck as each forger might refuse to run that script unless their own tx can be inserted as the winner.

Effectively you need the block that marks where the payout applies from to be one that has already been forged *but* not knowable until a subsequent block and also not even approximately knowable in order to prevent gaming the system.

And btw thanks for the input guys - as you can see we are dealing with some rather tricky problems.

Okay - one thing that does help out with this difficult problem is "confirmations" as we wouldn't accept "tickets" that aren't fully confirmed.

So if people are going to wait until the "last minute" to purchase a ticket then that isn't going to be perfectly predictable as the timing for block forging isn't exact (so hard to know when we are exactly 10 blocks before the "payout"). This also means it isn't dead easy for the forger to know that the current block they are forging will be *the* block that counts.

What I am thinking might work (although I doubt it is perfect) is that you combine the public key of the tx owner (which can't be changed thus avoiding malleability) with the "secondary hash" (which can't really be predicted) of a block that comes x blocks *after* it (in order to be more sure of that block you'd want to make sure that it has had at least 10 confirmations).

So in this case a valid entrant might be a tx with say 15 confirmations and the entrant's public key is concatenated with the hash of the block that is 5 in front of its own and then hashed with the lowest 64 bits returned as your "ticket number".

I don't think that this idea is perfect but I do think it is at least getting closer to being a "fair" lottery.

Ah, right! I forgot that some of the lottery players could actually control execution. Wow, crypto$ thinking is tricky...



I thought about this as well, but figured it might cause players who missed out by 1 block to scream bloody murder. Even if you know intellectually and logically that the rule is "fair" for everyone, psychologically it still sucks. (But I'm thinking about how people respond to games of chance in RL; maybe I'm misunderstanding the mindsets of crypto$ dice rollers?)

Actually as it would be a "continuous" lottery they would just end up with a ticket in the "next round" so I don't think it would be such a problem (the draws could be done daily or weekly I guess).

Now that I think about it perhaps instead of using the secondary hash (which can be altered by the forger) it might be better just to simply add up x time stamps from the following blocks and hash that (as a forger can't modify the time stamp by very much or they would end up creating an invalid block).

So given that the forger can only alter the time stamp by +-15 seconds (or it is more - am not sure about that) then at best they can decide which of 30 different values would be most suitable for a ticket that was purchased x blocks ago. It is still of some advantage to the forger who happens to be a player but it isn't a huge advantage (and you wouldn't always be able to predict that you will be the one forging the block x blocks in the future so you are still taking a risk by "buying a ticket").

Timestamp sounds like a good hard-to-predict data source! Will the timestamp be in seconds or something smaller like milliseconds? And how punctual will most forgers be in practice, once TF is activated? But whatever the case, you can control the granularity by taking e.g. floor(time / CONSTANT), or some other more sophisticated function that makes all output values approximately equally likely, so you can control how many possibilities a forging entrant could choose from.

Let N be the number of possibilities of the timestamp -> data function. You'll want N small enough to minimize cheating forger advantage, but N^x large enough that it's impractical for other cheating participants to compute a significant advantage. It's a balancing act, but sounds doable with suitable obfuscations/iterations to the lottery function.

Is there another hard-to-predict data source that can be used in addition to timestamp?

EDIT: Plenty I think, if we're sampling over multiple blocks. Total # of transactions, total Nxt transacted, sum of account numbers of everyone who made a transaction, etc. Granularity can again be controlled by suitable functions. The key thing is that we're taking data over multiple blocks, not just one, so no single forging participant can have large control.

In future we'll get rid of timestamps, we don't need them coz block height will define the timestamp (we'll have exactly 60 sec between blocks).

That means the network will treat blocks as generated right on the minute then? (In practice they won't be, due to processing lag, connection lag, etc, just that for computation purposes we regard it as exact, then try to adjust the practice to keep as close to that as possible?)

Indeed - as CfB has pointed out "time stamp" isn't going to cut it so I think something like a hash of the sum of account numbers will probably have to do the trick.

I guess also that if the number of blocks required to be known about in the future is big enough (maybe something like 100 might be a more reasonable choice) then hopefully the uncertainty of at least a few forgers not "taking their turn" would make the chance of a forger being able to gain an advantage by omitting some transactions fairly slim (as they would have to had to purchase their own "lottery ticket" exactly x blocks before).

EDIT: Perhaps 64 will be the magic number. I am thinking we take 1 bit (say mod 2 of the second hash) from each of the 64 blocks that come after the block that the tx comes from and then finally hash that. In this way there is no benefit to "mine" for a better hash as each forger (on their own) can only affect the outcome by 1 bit so you would require collusion from numerous forgers (who are all forging one after another) to have a real chance of being able to "rig" the result.

See this one: https://bitcointalk.org/index.php?topic=458036.msg5158434#msg5158434

What about network topology (even if Nxt'll be world-wide network, in some areas for plenty of reasons could happen blackouts) and orphans?

Distributed computing in general. The fees should be therefore really small to encourage it.

Will we limit the number of ops per block as we limit the number of transactions per block?

TF requires that rate of orphaned blocks is very high.

Speaking of orphaned blocks, I would say limiting the number of ops per block can be healthy to reduce wasted computing.

Thinking this further: nodes are then interested to get their blocks accepted because computing is expensive.

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

I see the problem with my proposal.
But having true random data would be great.
If we had true randomness on the Blockchain we could even do this:
For specific accounts we could set a random lock time for new outgoing transactions to be added to the Blockchain.
This would make Instant Payments for such accounts possible because an attacker would not know who the forger is, that can add the next transaction for this account to the Blockchain.

Autonomous pegging is it even possible?

USD Asset price can be set extremely low...

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.

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.

I think the Killer App for NXT VM would be a reference implementation of a coin built on top of NXT, using AM and Asset Exchange. I envision a whole set of NXTcoins built on top of NXT, each addressing a specific market niche. Like it or not, the altcoin concept is here to stay for a bit and there are so much mining resources, I want to create a bridge for all the miners to become NXT'ers, without feeling any pain.

Maybe such functionality will be built into NXT core itself, but in general we can see what sort of NXT VM scripts are popular enough to warrant conversion and inclusion into the NXT core.

A NXTcoin should be able to be PoW or PoS, or maybe even a hybrid with a certain percentage PoS for initial investors and the rest PoW. One thing that bothers me about the usual setup where the initial investors get 100% of their share upfront, while the miners can only get incremental amounts. There is always the big amount from IPO investors waiting for a decent price to dump.

My idea around that is to sell presale amounts in the form of a future dividend flow. For example, if 10% of a coin is presold or reserved for coin creators, and the rest for miners. At first the 10% of investors would have 0 coins. for every 10 coins that are mined, the investors would share 1 coin proportionally. This could be implemented as an automatic dividend each time coins are created via mining. we would need a special dividend version of the coin and that is what would be presold, but it would be linked to the coin.

To implement this using AE, I was hoping for a method to increase the coin supply via API, but CfB politicized that request by requiring it to be a test of NXT change request process. So, my workaround is to issue 1 billion of the coin Asset and have the DAC (or whatever it is we are calling the automated process) originally own all of them. We need to somehow restrict usage of these coins or we need to trust the DAC from sending them without permission. Not sure of the right mechanism. One crazy way I thought of was to also seed the DAC with anti-coins. The restriction would be only net positive amounts of coins could be transferred. Then the mining process triggers via validated AM to distribute coins to a set of accts. This number of anti-coins are sent to genesis acct and the freed up coins sent to the specified accts

Since this method uses AE to keep track of the coins, there isnt any worry about 51% attack, etc. Just need to make sure the AM that triggers coin "issuance" is secure. Still working on more details, but I thought this would be a good use case for you to ponder as it doesnt require voodoo magical maths, or anything fancy, but is complicated enough to make sure NXT VM will be able to be used to make useful things.

James

P.S. I just got a suggestion about a Nodecoin, which would simply issue a coin if somebody was forging at the time of a block. Maybe we need to limit it to prevent explosion in number of coins, but some intangible thing that people got just for forging. Who knows, a market could even develop for this and people might find it profitable to get low cost computers that are able to forge.

I think a nice use case would be obtaining data from a public website. If we can do this in a decentralized way, it solves the whole trustless broadcast of data feed problem. Once that problem is solved, then betting against the data feeds becomes possible. Once that is possible, CFD and other derivatives can be created.

If the forging node published an AM of what it thought the website said, it could be verified by a "randomly" selected subset of forgers (dont want to Ddos the website!) and as long as a super-majority agreed with the data, it would be officially place in the NXT blockchain

I think we would need a way for a script to do an http get or post call, alternatively, the NXT core needs to provide this support directly. i hope we are open to such radical and crazy ideas. If we can solve this, it will open up a lot of possibilities.

James

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.

OK, am I allowed to have NXT nodes voluntarily run software and publish AM data with datafeeds that these nodes will peer validate? It wouldnt be in the NXTcore at all, just an application on top of NXT using AM, so I think it is ok, but I wanted to make sure I am not forgetting something and making you upset

James

P.S. Any feedback on NXTcoins is that DOA also?

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

Nodecoin might be simple enough. Just need to transfer Nodecoin asset to all accts that were forging that block, but that would require NXTcoins to be there and if you are saying no using AM for your use cases, it seems NXTcoins wont be guaranteed to be done via NXT VM

I will go to plan B then.

James

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

Ok now here is the solution to the random data issue:
Every forger creates a very large random number. He hashes this number and adds the hash to to block he is forging.
 
He than creates a transaction that will reveals this random number. This transaction in not yet beeing pusblished to the network. Instead this transaction is beeing sent as encrypted arbitrary message to the 10 previous forgers. These 10 previous forgers decrypt that
 arbitrary message and check the random number against the hash in the blockchain. When everything is ok every previous forger creates an arbitrary message that states that he recieved the correct transaction (these 10 arbitrary message will be added to the blockchain).


After 100 blocks the transaction that reveals the random number is beeing published to the network (and added to the Blockchain).

Now the last known 100 random numbers are hashed together to seed the random function (Only those random numbers are used where short after creation most of the previous forgers stated they have received the revealing transaction).


It's just that easy!  ;)

If one change will slow or risk of bugs  i recommend staying away at this point. It's seen by Bitcoin how falling with hack attacks...

+1

If you're calling the scripts Automated Transactions, what about calling (some level of) the scripting language Xtnd?

EDIT: Then we can call the scripts Xtnded Transactions.

Another possible use case is for alias auction, after alias transferring is enabled.

How will everyone else verify that the number was indeed generated randomly? The forger could have used a biased generator, or just chosen it themselves.

Yes, but before the number will be used to seed the random function, it will be hashed together with 100 other numbers of other block forgers. If at least one of these 100 numbers is random then the  whole resulting hash is random

Isn't it more then just automated transactions? Aren't we talking about the scripting language in general also?

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

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.

Yeah sounds good. Xtnd (like Nxt) is a name that appeals towards users (both casual programmers and regular folks) more. AXs would be more convenient terms for experts.



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".
[/quote]

I'm interested too. :) A lot of possibilities open up if users can send scripts more specific information.

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

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.

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. ;D

good ;)

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.

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

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.

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.

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

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

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.

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.

It is also wonderful,in addition to be interested.

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.

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

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

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

NXT is awesome!  keep up the great work.

This is really cool.

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!

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?

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.

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.

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

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 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 (http://en.wikipedia.org/wiki/Transaction_authentication_number#Indexed_TAN_.28iTAN.29)

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.

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.

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

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.

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!

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

hell yeah!

8)

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.

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.

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

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.

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


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

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.

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/

There is no need for AT to know "Secret Key". I think we mean the same!

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

Sorry Fry, I got it the wrong way round.

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

Agree. Salt should be added one way or another.

Just wanted do add: don't use MD5 if nobody else had already mentioned it.

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

Just to get sure. ;) Sometimes, news spread slowly.

This is where it's AT!

* Dodges rotten vegetables *

+1

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

Just read the spec document, was a pleasure to read. Wish more devs (and mathematicians!) would write as clearly and explain motivations like you do.

Some thoughts about the op codes:

1) Would it be useful to have a pause code and a resume code? Maybe for event handling, e.g. onAMReceived() { resume; } ? (Is running out funds the only way to pause a running script?)

2) A note for James: subleq isn't exactly 0x89 SUB_LEQ, it's actually
@addr1 -= $addr2, if $addr1 <= 0 then pc = addr3,    rather than  pc += $addr3 . James, you'll need to compose it with additional instructions to have it match up with the subleq used in the example C++ libraries.

(This must be Ian's plan to slow subleq even further ;D)

@CIYAM Open I have read the spec document now.
Some suggestions from me:
I would rather like to see some event handling than this blocking with Sleep_Until_Creator or Sleep_For_Blocks or when the script is running out of coins.
The AT running out of coins should be the exception, and not a regular used mechanism. Otherwise in some usecases you don't know how long the script will actually run, so you have to send more coins to it just to keep it in a loop later.
If event handling is used then there also is no need to keep all data persistent, remember that all persistent data will need to be copied about a dozen times with every new block creation.
Here's a example AT with event handling.:


register event handler "block 1000 apeared" :block1000
register event handler "AT received coins" :newcoins
end

:block1000
'do what needs to be done when block 1000 appears
end

:newcoins
'do what needs to be done when at the AT account gets new coins
end

@Zahlen and @Fry thanks for taking the time to read the spec. and comment.

I had thought about "events" but am worried it will complicate the design also I think that the functionality you are wanting can be achieved without too much coding effort. Consider this (taken from the Dormant Funds Transfer use case):


So although the basic rule is that for the "event to run" a tx is sent to the AT with enough fees to pay for execution (unless it is in hibernation) the API functions will make it easy enough for the AT to determine what kind of tx has arrived and therefore what to do about it (you could create a bunch of subroutines which are called according to the @am_type_subtype or according to data in an AM, etc.).

Understand also that the hibernation idea is simply for an AT to be able to "save wasted cycles" as even if execution is being paid for there is no point in it just checking the block height and stopping.

In regards to "subleq" I thought it was doing what I had read but if it isn't then don't worry James - it can easily be fixed up. :)

But this way requires the script to be constantly polling for "triggers" (here am_type_subtype), which will require extra cycles (and hence cost) right? (Or would the extra cost be negligible?)

I was thinking that instead of pausing/sleeping for a predetermined period, during which the script can't execute and can't poll, you could have some mechanism that allow triggers to wake up the script (or at least run a function that checks whether the trigger is something valid for the script to wake up for).

Indeed the normal thing for an AT to do *is* to poll for triggers, as transactions (which *are* its events) are exactly what drives it, so I don't really see that as "wasting cycles".

The idea of the hibernation is just to stop it polling completely until a given block height (as I think that could be reasonable for some use cases). There might also be a case for being able to send an AT NXT without letting it execute code (will have to think about this as you wouldn't want the AT to be easily starved).

It might also make sense to have an AT "priority" setting (a bit like task priority) so that lower priority ATs might only be run at most every X blocks.

Although obviously a lot of careful measuring will need to be performed at the testnet stage the design itself is aimed at being very minimal in "cost" (current use cases would require no more than 1K of memory and would only need to execute 5..10 instructions per "poll".

Do i get this right, everytime a new transaction comes in, the AT is beeing executed from the beginning, but the memory is at the state where it ended last time?

From where is execution time purchased from the ATs XNTs or from a fee in the incoming transaction?

I missed that. Hopefully I wont have to pay double for all the subleqs. It will be so inefficient as it is. I just want a C compiler out of the box, which is my only motivation for subleq

After some consideration I am now thinking that a simple "crowd funding" AT could be a better 3rd use case (I was considering an "auction" but it seems to me the VS could probably handle that with some very minor modifications).

The idea would be that this AT would check its balance after n blocks (so it would be a good candidate to use the "sleep until block X") and if it is >= X then it would send all its funds to account Y (being the "project's account") otherwise it would iterate through all the txs it had received and refund the amount back to the sender (minus a small amount to run itself).

What do you guys think?


Pretty much although it actually depends how it had halted - if it had finished running (or reached a "finish" op) then yes it does that but if it hit a "stop" op (or it was halted due to lack of funds) then it continues from that point rather than from the start.


The execution time is in accordance with the AT's balance although a fee (possible mandatory) will cover a small amount of execution (so an AM would actually trigger execution).

I think it would be nice to have the possibility to execute the AT at a specific block height (Time) without the need for a incoming transaction to that AT.

Strange, I wrote it in the spec as state.pc += $addr3 but didn't actually code it that way in the prototype - anyway I've changed the code (locally for now but will republish soon) to the following:


so this ought to be the "subleq" you were expecting James. :)


Agreed - so I think part of the AT "header" will include an "execute at" block # (or approx. time). Another related idea is that if an AT is currently hibernating then the extra fee required for sending a tx to an AT (to allow it to execute a minimum # of steps) would be instead added to the AT's balance (i.e. so it is paying for those steps to be executed later).

Yeah some form of triage makes sense, since computational resources may be limited. AT coders should be coding ATs in such a way that they don't have to be running every block to successfully complete execution anyways, since things like running out of funds could happen.



Actually, that still isn't the subleq branching. SUBLEQ a, b, c means that after you perform a = a - b, if that is <= 0, you goto c, not the address pointed to by c, or advance the code point by c. So you'll want pc = addr3 instead.

(I don't know whether to feel proud or guilty about optimizing subleq!)

Oh - so I changed the code which was actually already correct - doh!

Okay so I'll put the code back the way it was and change the spec. to this:


Please tell me I've got it right this time!

I'm sorry, I don't think I can.  :D Spec needs to be pc = addr3, without the $.

Maybe it's my use of the variable name "addr3" that's the confusion; addr3 is supposed to be a value representing an address, not the value pointed to by an address. It should behave like JUM_ADR. (I do math mainly, not coding, so I'm not used to naming conventions.) So maybe


would remove any confusion?

Yup - my bad again - actually the code had it right all the time I just wrote the spec. wrong (twice now).

It will be fixed to: pc = addr3 in the spec. (which is how it actually had been coded in the prototype originally - guess I code better than I write specifications).

Just a post to let you guys know that I've updated the documents at http://ciyam.org/nxt and have added the 3rd use case which is a Crowdfunding Agent.

I have yet to create sample data and test this last use case (will do that by early next week) but I think the basic form of the AT concept is taking shape.

When will this be fully functional and implemented?

The plan is to get this ready for release in April (which I think should easily be achieved provided that we can organise a team in the next week or two).

From the technical side there will still need to be quite a bit of further work done on the specification (adding "meat" to the "bones") and then a lot of test cases need to be created (both for the AT interpreter itself and for each of the use cases mentioned in the specification).

The actual coding for the AT interpreter itself is not likely to be a huge job (I'd say a week or two) so the testing is going to probably require the most effort.

Just to note I've updated the specification and the "Crowdfunding Agent" use case after testing it today.

A new op code SET_PCS has been introduced and "pcs" has been added to the "persistent state". Its purpose is to hold the "program counter start" (normally zero) which is where the "pc" will start after a FIN op has occurred (or after the last op has been executed).

This allows an AT to set a new point to begin execution from if/when it is "awoken" by a new tx. In the case of the "crowdfunding agent" this will be conditionally set depending upon whether the balance of the AT had met its target amount by the target time so that if further txs occur then any balance will be either (a) sent to the project because it had met its target or (b) refunded to the sender because it had not.

Another update - I've removed four op codes (ADD_VAL, SUB_VAL, MUL_VAL and DIV_VAL) so that the only op code that requires a 64 bit value is SET_VAL.

Other changes were in the description about the stacks (there are two - a "call stack" and a "user stack").

Further update - it took a bit of time (to rework the use cases) but now there is no use of "unsigned integers" (except for some "prints") which should make porting to Java easier (most op code values have been changed so no op code > 0x7f).

The next stage is to get some tasks put up on CIYAM Open (http://ciyam.org/open/?cmd=view&data=20140220164742097000&ident=M100V137&chksum=065ecf7d) and organise some people to "put dibs" on them.

Hey CIYAM, would an "Escrow" use case be possible with AT?  I feel that this would be very useful and have been thinking about how it's possible with AT.

Hmm...  I am thinking what might work is this sort of approach (not ideal but still could be useful).

An AT is created that can only send funds to 1 of 2 addresses with 1 of those being to "the void" (or a charity if preferred) and the other being to the person you are buying goods from with an AM (from only its creator) being used to instruct it to send to the vendor (and with a timeout to send to the void after x days/weeks/months).

So once you have funded that AT then the guy selling you the goods can see that your funds are "committed" (i.e. you can't get them back) then he sends you the goods and you release the funds to him.

You'd want to tie this in with a "rating" system I'd guess also but I think we do have another use case here (it's actually just a variation on the Dormant Funds Transfer technically).

Great, I think an Escrow AT would be a great seller, perhaps we can talk to Nexern about adding to his client as his client has a functional reputation system.  I like your approach of sending to void (perhaps genesis block or Nxt bounty fund), so buyer is committed regardless and seller has no incentive to scam.  Really interesting stuff, perhaps someone has a better approach but I like it.

Furthermore, the 1st account could be a specific market escrow committee, so if the funds end up there and the seller has a case, he can argue for the funds with proof.  Great work here CIYAM

Thanks - after some thought it actually is probably better to always send to the void than to anything else.

(someone who "loves the whales" but "hates X tee-shirts" could always make an order for a tee-shirt and then just send the money to the "help the whales" organisation claiming to have been not sent a tee-shirt)

How is "void" defined?  Perhaps Genesis Block?  Could incorporate AE and DAC later into escrow.  For example:  Buyer purchases goods.  Buyer converts Nxt to "Escrow coin" via AE.  Buyer submits Escrow coin to Seller via AT.  Buyer receives goods and releases Escrow coins to Seller.  Seller then converts Escrow coin to Nxt or any crypto via DAC.  That way we are never really losing any Nxt to void, only Escrow coins.  Although not sure where Nxt would end up if transaction falls through, perhaps to owner of Escrow Coin Asset.

I think the problem could perhaps only be solved by some sort of more "random" process (which is not simple with an AT as it is not easy for an AT to actually get *random* data).

I am guessing if we could get enough randomness then our "whale lover's" donation (and I am not against the whales - so replace them with any other creature you like or dislike) could actually be just as likely to go to the "whale eater's" foundation.

That I guess would stop the money going into the "void" but keep anyone from having an "agenda" to not release funds.

Yeah, AT randomness is difficult, so perhaps an Escrow Coin Asset business would be better suited to handle.

We can possibly achieve it by using the "weight" of a block in the future.

Unfortunately as per my attempts to do some statistical analysis I don't if anyone will actually be able to provide any real data upon "how random" such a result would be (so am not thinking the "lottery" use case is now such a great one).

People on Speculation forum talking about Turing Completeness:

There's a good reason I *ignore* the Speculation part of this forum.

Just trying to inform here. Speculation forum is usually full of bullshit and madness, but I found really interesting that they are carrying such a topic there. Anyway, I have not the skills if those things they are saying are true or just bullshit as usual.

P.D: Cheers for your work!

And that is always the problem with that part of the forum as basically no-one with real technical skills posts there (no point as they wouldn't understand a word of it).

But it isn't surprising that the "Turing complete" buzz word has caught some attention (as I think has DAC - and who knows - maybe they'll even end up posting questions about Nxt AT in the coming months).

:)

Regarding Turing completeness, I have the math background to answer:

Saying that a programming language (whether AT, or Ethereum, or C++, or anything else) is "Turing complete" means that it can perform all the calculations that a Turing machine (https://en.wikipedia.org/wiki/Turing_machine) can perform. A Turing machine is a technical math/CS concept, but the key thing to take away for this discussion is that Turing completeness only says something about the calculations that can be performed. It doesn't say anything about actions.

Turing completeness is a good thing! It means ATs can read data sent to it and add, subtract, multiply, divide, compare this data, and perform all other computations that you'd normally expect a computer to be able to do.

Bad AT behaviour may indeed be possible, from actions like e.g. spamming AMs. But Turing completeness doesn't say anything about actions like sending nxt, or composing and sending an AM. These would be additional features of ATs. It's up to Ian and his team to decide what actions ATs should be allowed to/not allowed to do, to guard against bad behaviour.

As I understand, Ian's writing a virtual machine (VM) for ATs. That means a place set aside for ATs to perform their calculations, and that means ATs won't be allowed to interfere with the rest of your computer. I think ATs will also only be allowed to send transactions from the account that they're "assigned" to, so that's another good restriction.

Pretty close - certainly an AT won't be able to "damage" the forger's computer (even if it has an "infinite loop" coded it is of zero concern) but at this stage I hadn't planned restrictions on which account an AT could send money to (although it is perhaps unlikely that we would be letting it say iterate all accounts).

In general the practice of spamming should be taken care of by the fact that all txs require a fee (and we could even increase those fees for txs that originate from an AT). Also understand that the Nxt AT won't be talking to the Nxt API but to a Nxt AT API to keep it safely "sand-boxed".

With this change, would it still be wise to initialize data pages as 0? Cause then you may have to SET a lot of VALs through the code pages first.

EDIT: I was just talking about which accounts an AT could send transactions from, definitely makes sense to restrict that. Hadn't thought about the "to" part either.

All data in the VM would be expected to be zeroed prior to it being called and I've also specified that the start of the data area (for constants) could be provided with the AT creation tx.

Also I have now added "indirect assignment" and "indexed indirect assignment" op codes so that if such initialisation was required then it would not take many op codes to do it.

Oh right! I missed that.

All AT txs come "from the AT" (as it has it's own account).

May be just implement nasx.com escrow scheme on protocol level?
http://nashx.com/HowItWorks
http://nashx.com/FAQ

This scheme dont need reputation or trustness. If automate this in nxt-protocol then we dont need third-party as nasx.com for exchange.

Nice - I think we could indeed create an AT to do this. Because the code is open and unable to be changed after the AT creation tx is confirmed then it can actually be "trusted" to do things like this.

The tricky part is going to be able to make sure that people know a trustworthy AT from an "evil" AT (that requires being able to understand the code which is why that code needs to be as simple as possible).

+1, I like the nashx approach.  Also, really like the idea of posting Nxt projects on your site, I have BTC saved for it!
https://bitcointalk.org/index.php?topic=345619.msg5403299#msg5403299

This was posted in main Nxt thread, might be a good guideline.

Smart Contracts used by Ethereum

http://www.actuss.com/doc/classes.html

Features

ACTUS Contract Calculator
4.1 Principal At Maturity (PAM)

The PAM contract type encompasses many common financial contracts. Most typical representative is the classical government bond. It also covers money market funds, fixed deposits and also all sorts of bullet type loans. Beyond simple fixed rate instruments it accommodates many complex variants such as variable rate instruments and instruments with capitalization.
Principal At Maturity Calculator
4.2 Annuity (ANN)

ANN contract type at its simplest form represents an annuity payment, where principle and interest are paid out over a specified period of time. Common mortgages in several countries follow this pattern. This contract type can represent fixed and variable rate annuities, also including grace period, irregular payments and so on.
Annuity Calculator
4.3 Stock (STK)

A STK contract represents a certain quantity of equity issued by a company.
Stock Calculator
4.4 Future (Futur)

A FUTURE is a standardized contract to buy or sell specified asset at a price agreed upon today with payment occurring at a specified future date. Underlying assets can be Bonds, stocks, commodities or FX rate related instruments. In ACTUS, a FUTUR is represented with a parent-child relationship, with the child being the underlying asset. Closely related to FUTURE is the margining process, which can be modeled in many facets.
Future Calculator
4.5 Swap (SWAP)

A SWAP is a derivative in which counterparties exchange cash flows of one party's financial instrument for those of the other party's financial instrument. In ACTUS, it is represented with a parent-child relationship having two children, which are basic CT’s (such as PAM or ANN). This method of combination of basic CT’s allows ACTUS to represent multiple other variants of swaps, an example being amortizing swaps.
Swap Calculator
4.6 Option (OPTNS)

An OPTION gives the holder the right to buy or sell an underlying asset for a given price (Strike) on or before a specified future date. In ACTUS, it is represented with a parent-child relationship, where the underlying child can be a Bond, stock, commodity or FX rate related instrument. All variants of call/put and American, Bermudan and European options are (or will be) supported in ACTUS.
Option Calculator

How far do you intend go with the turing-complete vm? Do you have similar plans as the Ethereum guys who apparently want to run everything on top of their turing-complete contracts and include options like decentralized paid storage etc. Do you intend to include similar options as well, like paid storage and other more external oriented options, or do you have other goals in mind?

I think CIYAM will develop to the point where others can continue in any direction they want.  I'm not sure if there are any specific plans, but I would also like to know the answers to your questions.

As AT has a "Turing complete" instruction set and state then aside from restrictions to the max. # of steps that can be executed by any "forger" and restrictions to the max. # of bytes of state you will be permitted to use you will be able make an AT do whatever you like it to.

For the initial implementation there will be fairly strict limits on data storage (state). A possible way to be able to have more state will be to use Service Providers for that down the track.

I have decided to move further discussion about AT to CIYAM Open:

http://ciyam.org/open/?cmd=view&data=20140228080813138000&ident=M100V120&chksum=ba3b7b5c

It's free to sign up for an account (and CIYAM Open supports OpenID so you can use a gmail account or the like) so don't be shy!