NXT :: descendant of Bitcoin - Updated Information

[swartzfeger]

CfB, what is your opinion of subleq? It seems we just need to implement one opcode.

There already exists Higher_subleq (assembly language) and C compiler, so that sure sounds like the quickest path. The CPU model they use doesn't seem too crazy.

James

We don't need as less instructions as possible. We need a usable language.

So does this mean Subleq is out of the running for VM? What's considered a 'usable' low-level language?

[xyzzyx]

CfB, what is your opinion of subleq? It seems we just need to implement one opcode.

There already exists Higher_subleq (assembly language) and C compiler, so that sure sounds like the quickest path. The CPU model they use doesn't seem too crazy.

James

We don't need as less instructions as possible. We need a usable language.

So does this mean Subleq is out of the running for VM? What's considered a 'usable' low-level language?

Brainfuck.  I vote for Brainfuck.

[jl777]

We don't need as less instructions as possible. We need a usable language.

Indeed I had thought that was what you *meant* (rather than what you actually said).

Do you agree that it should have op codes for things like SHA256 and what about the whole problem of the impact of running said scripts on the TPS rate?

In any case, since 1000TPS is bandwidth limited, we dont really have any CPU bottleneck issues, unless you actually want to calculate crypto functions in the script instead of pushing it down with the script embedded in the AM

[Eadeqa]

Edit: I think it would be really cool to do to Etherium what XCP did to mastercoin
Edit2: Plus I think CfB was getting bored doing easy stuff, this is not so easy

Forget  Etherium. Nxt has first mover advantage. Finish the client and "features" that are already listed before introducing even new "me too" complexities with so many security and performance implications.    If CFB is so easily bored, he should add more developers to the team to work on things that are already in the pipleline.

[jl777]

CfB, what is your opinion of subleq? It seems we just need to implement one opcode.

There already exists Higher_subleq (assembly language) and C compiler, so that sure sounds like the quickest path. The CPU model they use doesn't seem too crazy.

James

We don't need as less instructions as possible. We need a usable language.

So does this mean Subleq is out of the running for VM? What's considered a 'usable' low-level language?

Brainfuck.  I vote for Brainfuck.

Has a nice ring to it, but it is too easy to program with compared to subleq

[xyzzyx]

Edit: does this mean you don't consider C a usable language?

He means at the virtual hardware level.  C is an abstraction layer above that.

There are multiple levels here, like the movie Inception it can be hard to keep track.

[CIYAM]

In any case, since 1000TPS is bandwidth limited, we dont really have any CPU bottleneck issues, unless you actually want to calculate crypto functions in the script instead of pushing it down with the script embedded in the AM

Each node (perhaps other than "light nodes") would have to *do* the crypto calculations as part of running the script otherwise once again you can just be tricked.

Again CPU may not be the main problem - but the size of the scripts would for sure be bigger than standard NXT txs are plus the VM "state" would also need to be stored somewhere (presumably as an AM - although currently that limits your persistent state to a paltry 1000 bytes).

[Anon136]

We don't need as less instructions as possible. We need a usable language.

Indeed I had thought that was what you *meant* (rather than what you actually said).

Do you agree that it should have op codes for things like SHA256 and what about the whole problem of the impact of running said scripts on the TPS rate?

It wouldn't technically change the max transactions per second because the max transactions per second would be a function of the total number of transactions that could fit in a block that contained nothing other than transactions. eventually at some point in the future transactions and scrips would come into conflict and would start bidding against eachother for block space. the balance would be struck that would tend to lean in favor of transactions since they would be so relatively tiny compared to scripts with similar utility. The more demand that arose for transactions the more scripts would tend to be crowded out by transactions. Eventually they may become quite rare and expensive and only used for very high value utilities.

[jl777]

Edit: I think it would be really cool to do to Etherium what XCP did to mastercoin
Edit2: Plus I think CfB was getting bored doing easy stuff, this is not so easy

Forget  Etherium. Nxt has first mover advantage. Finish the client and "features" that are already listed before introducing even new "me too" complexities with so many security and performance implications.    If CFB is so easily bored, he should add more developers to the team to work on things that are already in the pipleline.

This stuff has nothing to do with the client. Do you want everyone who is not working on the client to just twiddle our thumbs while we wait?

I figured it was better to create new exciting features building on top of what we will have in the near future.

I want the killer app that is decentralized trustless exchange of any crypto to any crypto.
In order to do that, we need some sort of scripting. Might as well be Turing complete

Who else has a decentralized trustless exchange of any crypto to any crypto?
How is that a me-too? Not that there is anything wrong with some me too stuff
Also, there is currently no working zeroknowledge based ecash system. Not exactly in the me-too category

[xyzzyx]

In any case, since 1000TPS is bandwidth limited, we dont really have any CPU bottleneck issues, unless you actually want to calculate crypto functions in the script instead of pushing it down with the script embedded in the AM

Each node (perhaps other than "light nodes") would have to *do* the crypto calculations as part of running the script otherwise once again you can just be tricked.

Again CPU may not be the main problem - but the size of the scripts would for sure be bigger than standard NXT txs are plus the VM "state" would also need to be stored somewhere (presumably as an AM - although currently that limits your persistent state to a paltry 1000 bytes).

In the end, there can be only one.

[Fatih87SK]

IMAGE

looks like a fancy chocolate birthday cake

While I commend you for your work, I am wondering what is this for specifically?

I thought we all agreed that coins and similar representations should not be a thing in NXT?
NXTs logo is all we really need? Why do we need a geometric shape?

This is the ugliest thing i seen this month!  
I'm just speaking out loud.  

I'm just visualising ideas of BCNext. When I'm finished with that. I will make a new one to satisfy your eyes. Maybe.

[gimre]

In any case, since 1000TPS is bandwidth limited, we dont really have any CPU bottleneck issues, unless you actually want to calculate crypto functions in the script instead of pushing it down with the script embedded in the AM

Each node (perhaps other than "light nodes") would have to *do* the crypto calculations as part of running the script otherwise once again you can just be tricked.

Again CPU may not be the main problem - but the size of the scripts would for sure be bigger than standard NXT txs are plus the VM "state" would also need to be stored somewhere (presumably as an AM - although currently that limits your persistent state to a paltry 1000 bytes).

I assumed, not every transaction would contain code to execute...

[xyzzyx]

I'm just visualising ideas of BCNext. When I'm finished with that. I will make a new one to satisfy your eyes. Maybe.

I liked it.

[Come-from-Beyond]

Except CfB said it had to be a low level (assembly language) type of language. He started a contest to find language with fewest opcodes for Turing complete. I doubt anything is less than 1, though there were half a dozen variants of single opcode Turing completes

This isn't a competition to find the least # of instructions (but if it was then "you won").

I am guessing CfB just isn't keen on something that is too complicated but believe me *without* instructions such as SHA256 such a VM would really be of no practical use at all.

So I guess it depends whether we are wanting to add something "useful" or whether we just want to say "me too" when it comes to having some sort of "Turing complete VM".

I keep in mind our 1000 tps goal. If we let to execute SHA256 as a single opcode then we'll face the problem Ethereum is faced with - what a fee multiplier should be used for this opcode. 100x? 500x? 2700x? In my vision if a script requires to calculate SHA256 then it's supposed to implement it using simple opcodes.

PS: We can always add SHA256-opcode in the future if it's really necessary.

[jl777]

In any case, since 1000TPS is bandwidth limited, we dont really have any CPU bottleneck issues, unless you actually want to calculate crypto functions in the script instead of pushing it down with the script embedded in the AM

Each node (perhaps other than "light nodes") would have to *do* the crypto calculations as part of running the script otherwise once again you can just be tricked.

Again CPU may not be the main problem - but the size of the scripts would for sure be bigger than standard NXT txs are plus the VM "state" would also need to be stored somewhere (presumably as an AM - although currently that limits your persistent state to a paltry 1000 bytes).

OK, you confused me. If a client precalculates all the big calculations that is needed and pushes that onto the blockchain, then I dont think any node has to do any big calculations. They all can just use the data in the AM that the script reads in.

I think you are thinking about the scripts as running big huge programs, but I am thinking of them as doing stuff like check for data in AM, do a little work, save state in AM, done.

All the stuff like sending emails, sending DOGE, etc. would be done on the forging node's services modules. Something like that. Scripts are more like OpenCL kernels. Just the 1% that has to be done in the script as it gets a guaranteed runtime context on decentralized set of servers.

Just check to see if an email came in (via looking at input AM) and then triggering some external action with output AM.

[bitcoinpaul]

Hey, I'm not selling any XCP for a while, maybe a long while. I am just trying to establish what a fair market value is. .01 BTC puts XCP at approx 50% mastercoin valuation.

Maybe some XCP holders didn't know this, I didn't realize the huge disparity in valuation until I looked it up.

If all XCP holders know the actual value of what they have, then it is much less likely for a crazy speculative bubble to form. Granted this links XCP value to mastercoin, but that seemed to be the closest reference point. Gotta start somewhere.

James

P.S. I own a larger percentage of XCP than NXT, so I am fully motivated to help  XCP values increase.

I hope you put your energy still in Nxt.

[pandaisftw]

I think I mentioned this hundreds of pages ago, but why do we assume transactions and DACs have to be on the same blockchain? The beauty of multiple chains is that people can choose which chains to point their devices at. Smartphone users would be happy to point their smart phones at the main chain only, while those with powerful desktops can point their machine at both the main chain and the DAC chain. Both chains can be run at 1 minute between blocks, to maintain consistency. Also, I wonder if coins can be transferred between chains? If not, I'm 99% sure the AE can take care of that.

Also, can anyone answer this: how does etherium handle a situation where one computer is faster than the other? Does the network just work at a predefined speed (# of OPs per minute) and anyone who can't reach that quota is kicked off the network? Or do they have some method of comparing output from multiple nodes to make sure the same inputs produce the same outputs (unlimited OPs per minute, depending on size of network and # of matching answers needed)?

[Come-from-Beyond]

Apparently we managed to get even worse than that - I think maybe CfB might have changed his mind about this now.

Well, I meant "without losing common sense".

[CIYAM]

Just check to see if an email came in (via looking at input AM) and then triggering some external action with output AM.

I don't think you are understanding the concept of "trust" here - if you want to write some code that does that then just write it.

Why do you even need Turing complete tx's when you don't want them to be run without trust?

[Eadeqa]

All the stuff like sending emails, sending DOGE, etc. would be done on the forging node's services modules.

How on earth would you guarantee that "stuff like sending emails, sending DOGE, etc." were indeed done by  forging node's services modules?

I have absolutely no reason to believe this would be safer than just using a third party gateway -- at least there I could complain to someone if "stuff wasn't done"

This is total fail.

I would never trust it