If the amount is the same to each output then it would be much smaller and even if not you only need 1 sig for all the outputs rather than 1 sig per output (so yes it should be a lot cheaper).

That would cost you n NXT at the moment.

That is a little expensive don't you think (and even if the fee was reduced it will still be very wasteful if you couldn't "compress" the tx to 1 amount and n accounts)?

I do remember CompuServe (and even used it) and just like the initial MSN (when they were trying to kill the internet with their binary protocols) it died.

For sure the forging fees are not going to make people rich but at the same time we do need to ensure that the network is looked after so I think that the fees should always at least make it viable to make a small amount of money forging as that is a useful benefit for the Nxt system.

It actually would "kill" the first "use case" for the Nxt Scripting system (which was to "pay dividends to asset holders).  

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.

Okay - the Nxt Script stuff is probably going to open a few such nasty cans.

Good to know - btw - if you are going to have to "upgrade" the tx format are you also considering adding "pay to many" txs (and for even better compression also "pay the same amount to many" which could be useful for things like sending "dividends")?

I just want to be sure about one thing - you aren't planning on using any floating point numbers for this are you (i.e. all the arithmetic will be using integers I hope)?

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

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?

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

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

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.

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.

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

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.

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?

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

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