NXT :: descendant of Bitcoin - Updated Information

[xyzzyx]

Why should we set a price per operations? Why not let the forger determine how many operations he is willing to perform for a given price?

What is an objective difference between those two options?  They look like two ways to state the same thing to me.

Is the trouble here in the fact that its would be un reasonable for the rest of the network to check the forgers work if the forger happened to be running on a really powerful computer?

One of the problems we run into is the Halting Problem -- there's just no way to know before-hand if a program will find an answer or chug away with calculations until the heat death of the universe.

[jl777]

Well ok i may have misunderstood you so let me just step back and ask some questions. Why should we set a price per operations? Why not let the forger determine how many operations he is willing to perform for a given price? Is the trouble here in the fact that its would be un reasonable for the rest of the network to check the forgers work if the forger happened to be running on a really powerful computer?

Of course if you don't set some sort of a price per instruction then you'd end up "stopping the network".

Sure it makes some sense for a forger to determine how many operations they would be willing to execute but then how would we actually "check" that this has been done correctly if other nodes are *not* doing the same work?

BTW - I am not really so excited about the whole DAC thing (which I gather James is) and would instead like to see simpler "more useful" concepts being created (rather than "pie in the skynet" ideas).

All sorts of useful things can be done using the middle of the NXTlayers.
I envision the ability for a Turing script to trigger sending an email. it would do this by processing its inputs (aliases and AM) and outputting an AM. Then services running on hub nodes process the AM and send out an email

Lots of details missing, but those are details. I am trying to understand the concepts for each layer.

Now not all forging nodes will have all services available, but as long as 90% of the forging is done on full service nodes, then within 10 minutes it is almost assured that any services needed will be done.

More details needed to make sure things are done once and only once, but these again are details.

So, if you don't like the DAC layer, you can just deal with the services layer. Whatever service we can run on 100+ hub servers can be triggered by AM created by Turing scripts.

This requires proper segmentation of the overall task to the right layer. From my understanding as long as the Turing scripts can get access to input data, it wont have to do a whole lot of complicated calculations. Though for a price any calculation is allowed.

I think 1 NXT per millisecond of compute time is reasonable.

James

[jl777]

Why should we set a price per operations? Why not let the forger determine how many operations he is willing to perform for a given price?

What is an objective difference between those two options?  They look like two ways to state the same thing to me.

Is the trouble here in the fact that its would be un reasonable for the rest of the network to check the forgers work if the forger happened to be running on a really powerful computer?

One of the problems we run into is the Halting Problem -- there's just no way to know before-hand if a program will find an answer or chug away with calculations until the heat death of the universe.

kill -9 after time limit is up. time limit = # NXT paid * milliseconds

[Eadeqa]

if on the other hand we tried to centrally plan this and dictate what sorts of code are acceptable and what sorts arnt, than who know what sort of innovation we may be stifling for lack of creativity and foresight on our part.

Good grief - suggesting ideas for a "useful instruction set" is now called "central planning"?

So - let's say we go with the idea of the 1 instruction low-level language and we charge say 1 NXT per 100 "operations".

Then a simple SHA256 operation will likely cost you 100's of NXT - so we have now a completely useless VM for doing SHA256 (but at least it wasn't "centrally planned" I guess).

No one has answered what it will do 1000 tps claims?

Indeed - the reason why I was suggesting we would need a "practical" instruction set if we are going to bother with this at all.

I would imagine much cheaper to pay 1 NXT for client generate AM that does any complex calcs. The scripts can access AM data, so the idea is for the higherlevel code to push down expensive to calculate data into AM

How would it impact the decentralized exchanges without any third part gateways when even simple SHA 256 operations would be that costly?

I think this will have serious security implications (and flaws). I doubt it work at all.

[xyzzyx]

kill -9 after time limit is up. time limit = # NXT paid * milliseconds

The time it would take to run a program would depend on the underlying computer. This may lead to a given program with the same input succeeding when run on a fast/powerful computer, but not succeeding when run on a less fast/powerful computer.

It would be better to use number of instructions as a metric.

Also, multiple nodes would have to run the program with the same input in order to check each other's work.  Otherwise, a malicious node could take your payment and lie about the result.

Edit: what he said ↓

[CIYAM]

kill -9 after time limit is up. time limit = # NXT paid * milliseconds

You couldn't use "milliseconds" as the instructions would be processed at different times on different hardware.

Understand that you'd ideally want *every node* to be able to verify *every transaction* which is going to have to include any VM script operations performed (otherwise how could you ever trust the "state" of the specific instance?).

I guess "light nodes" could skip that work but that would lesson the security of the blockchain (if we are assuming that say only Hallmarked nodes are going to check the code has been executed correctly).

[l8orre]

We need some kind of a competition. The goal is to find a language with min number of opcodes.

OH NO! NOT BRAINFUCK !!!!!!!!!!!!!!!!!

[CIYAM]

We need some kind of a competition. The goal is to find a language with min number of opcodes.

OH NO! NOT BRAINFUCK !!!!!!!!!!!!!!!!!

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

[Eadeqa]

kill -9 after time limit is up. time limit = # NXT paid * milliseconds

The time it would take to run a program would depend on the underlying computer. This may lead to a given program with the same input succeeding when run on a fast/powerful computer, but not succeeding when run on a less fast/powerful computer.

And it would mean the idea of "forging" on cell phones would be dead, aside from giving up fast transactions, 1000 tps, as some have been claiming.

[CIYAM]

And it would mean the idea of "forging" on cell phones would be dead, aside from giving up fast transactions, 1000 tps, as some have been claiming.

*Exactly* - it seems there is a problem of "wanting to have cake and to eat it too" here.

It will be almost impossible to a have 1000+ TPS *and* be able to execute "arbitrary code" (and certainly not using low-end hardware).

CfB had already spelled out that to even achieve 1000+ TPS requires the "non-script" idea of very simple transactions and would also require a "binary protocol" (which currently is not being used).

Now you want to add a "Turing complete" VM to the mix and still somehow get to that magical 1000+ TPS?

So guys - I see it has being a case of wanting A or B - either you want A (1000+TPS) or you want B (arbitrary code execution a la Ethereum).

[jl777]

if on the other hand we tried to centrally plan this and dictate what sorts of code are acceptable and what sorts arnt, than who know what sort of innovation we may be stifling for lack of creativity and foresight on our part.

Good grief - suggesting ideas for a "useful instruction set" is now called "central planning"?

So - let's say we go with the idea of the 1 instruction low-level language and we charge say 1 NXT per 100 "operations".

Then a simple SHA256 operation will likely cost you 100's of NXT - so we have now a completely useless VM for doing SHA256 (but at least it wasn't "centrally planned" I guess).

No one has answered what it will do 1000 tps claims?

Indeed - the reason why I was suggesting we would need a "practical" instruction set if we are going to bother with this at all.

I would imagine much cheaper to pay 1 NXT for client generate AM that does any complex calcs. The scripts can access AM data, so the idea is for the higherlevel code to push down expensive to calculate data into AM

How would it impact the decentralized exchanges without any third part gateways when even simple SHA 256 operations would be that costly?

I think this will have serious security implications (and flaws). I doubt it work at all.

CPU intensive calculations will be done in the client (or service module on hub) and pushed down to the Script via AM data

The problem is not calculation time, as with proper allocation of work to the appropriate layer you have access to the local CPU, the hub server CPU before it goes into the molasses slow VM. The key to designing practical system is to minimize the work that the Turing script needs to do. Its goal is to generate AM data that is then processed by hub server modules and/or client

My thinking on automating gateways already has several solutions using multisig approaches, I have posted before. However, I think there could well be a way to implement a method similar to XCP's escrow process followed by BTCpay. Just need to add LTCpay, DOGEpay, etc.

There will certainly be bugs at first, but a gateway does not do any really complicated tasks. Deposit and withdraw. Not sure why you are so skeptical that it wouldn't work.

I dont understand the multisig methods with timeouts in the articles, but I am sure someone else will. I also think someone else will be able to figure out an analogue for XCP escrow process.

When someone says something is impossible, it only means that it is impossible for them to do it. I just keep asking until I find someone that says it is really difficult!

James

[xyzzyx]

And it would mean the idea of "forging" on cell phones would be dead, aside from giving up fast transactions, 1000 tps, as some have been claiming.

*Exactly* - it seems there is a problem of "wanting to have cake and to eat it too" here.

It will be almost impossible to a have 1000+ TPS *and* be able to execute "arbitrary code" (and certainly not using low-end hardware).

Not necessarily.  Just don't expect the result to be available by the next block.

[Anon136]

Well ok i may have misunderstood you so let me just step back and ask some questions. Why should we set a price per operations? Why not let the forger determine how many operations he is willing to perform for a given price? Is the trouble here in the fact that its would be un reasonable for the rest of the network to check the forgers work if the forger happened to be running on a really powerful computer?

Of course if you don't set some sort of a price per instruction then you'd end up "stopping the network".

Sure it makes some sense for a forger to determine how many operations they would be willing to execute but then how would we actually "check" that this has been done correctly if other nodes are *not* doing the same work?

BTW - I am not really so excited about the whole DAC thing (which I gather James is) and would instead like to see simpler "more useful" concepts being created (rather than "pie in the skynet" ideas).

point taken

[CIYAM]

Not necessarily.  Just don't expect the result to be available by the next block.

CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple".

So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS?

Does anyone else see the problem here?

[jl777]

kill -9 after time limit is up. time limit = # NXT paid * milliseconds

You couldn't use "milliseconds" as the instructions would be processed at different times on different hardware.

Understand that you'd ideally want *every node* to be able to verify *every transaction* which is going to have to include any VM script operations performed (otherwise how could you ever trust the "state" of the specific instance?).

I guess "light nodes" could skip that work but that would lesson the security of the blockchain (if we are assuming that say only Hallmarked nodes are going to check the code has been executed correctly).

I cant see how we avoid relying on hub (hallmarked?) servers. For advanced services we need beefy servers.

I think CfB's plan was to simply count the number of instructions and then abort the interpreter session. If your loop exceeds the instruction limit, then it stops after 10000 opcodes are executed. Something like that.

Time would vary based on server spec, but not too dramatically. I guess it wont be exact cost per millisecond, but approximate cost per millisecond of execution time

James

[Anon136]

We need some kind of a competition. The goal is to find a language with min number of opcodes.

OH NO! NOT BRAINFUCK !!!!!!!!!!!!!!!!!

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

well this sort of thing would be a long way off anyways even if we did do it. the more i think about it the more i think about how important specialization is. these sorts of blockchains should probably best be built on a per application basis. one unique blockchain per dac. part of the beauty of nxt forging is that multiple blockchains can coexist with out competing for security resources. (atleast not in the way of a POW coin)

[xyzzyx]

Not necessarily.  Just don't expect the result to be available by the next block.

CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple".

So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS?

Does anyone else see the problem here?

Don't tie them together.  The VM runs in a separate thread from the Nxt protocol.  Use the referenced transaction option of the Nxt protocol to link the result to whatever you want to do with it.

It doesn't matter if the result comes in the next block, or 100 blocks later.

[jl777]

kill -9 after time limit is up. time limit = # NXT paid * milliseconds

The time it would take to run a program would depend on the underlying computer. This may lead to a given program with the same input succeeding when run on a fast/powerful computer, but not succeeding when run on a less fast/powerful computer.

And it would mean the idea of "forging" on cell phones would be dead, aside from giving up fast transactions, 1000 tps, as some have been claiming.

Services provided by "Service Providers" on beefy servers
cell phones are expected to go to slim clients, forging via Account Control and pooled forging

[jl777]

Not necessarily.  Just don't expect the result to be available by the next block.

CfB *himself* said 1000+ TPS would only be *possible* if protocol was changed to binary and kept "dead simple".

So - how is it now suddenly become *possible* to also execute (even just a few) instructions of VM "per transaction" (as you can't assume they won't *all* want to do that) and still have 1000+ TPS?

Does anyone else see the problem here?

see above

[jl777]

We need some kind of a competition. The goal is to find a language with min number of opcodes.

OH NO! NOT BRAINFUCK !!!!!!!!!!!!!!!!!

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

well this sort of thing would be a long way off anyways even if we did do it. the more i think about it the more i think about how important specialization is. these sorts of blockchains should probably best be built on a per application basis. one unique blockchain per dac. part of the beauty of nxt forging is that multiple blockchains can coexist with out competing for security resources. (atleast not in the way of a POW coin)

Yes!

I knew big brained guys will figure out the parts I cant. I just see the high level picture, need help with the details

James