NXT :: descendant of Bitcoin - Updated Information - page 1086.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: jl777 on February 05, 2014, 02:08:06 AM

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

xyzzyx

sr. member

Activity: 490

Merit: 250

I don't really come from outer space.

Quote from: jl777 on February 05, 2014, 01:58:19 AM

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.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: xyzzyx on February 05, 2014, 02:07:40 AM

Quote from: swartzfeger on February 05, 2014, 02:05:08 AM

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

Quote from: jl777 on February 04, 2014, 06:40:15 PM

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

Eadeqa

hero member

Activity: 644

Merit: 500

Quote from: jl777 on February 05, 2014, 01:55:06 AM

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

legendary

Activity: 1176

Merit: 1134

Quote from: CIYAM on February 05, 2014, 01:59:03 AM

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

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

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

xyzzyx

sr. member

Activity: 490

Merit: 250

I don't really come from outer space.

Quote from: swartzfeger on February 05, 2014, 02:05:08 AM

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

Quote from: jl777 on February 04, 2014, 06:40:15 PM

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.

swartzfeger

full member

Activity: 350

Merit: 100

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

Quote from: jl777 on February 04, 2014, 06:40:15 PM

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?

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: CIYAM on February 05, 2014, 01:59:03 AM

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

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

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?

I have suggested that scripts be able to access a subset of NXT core, that would include Curve25... and SHA256 can be easily added if it is not there already

xyzzyx

sr. member

Activity: 490

Merit: 250

I don't really come from outer space.

Quote from: Anon136 on February 05, 2014, 01:55:01 AM

Oh so you are saying that the amount of operations required would be something of a time limit. it couldn't be included in a block until after enough blocks had passed inorder to make sure that low power cpus could keep up. that would address the transaction per second problem but it would address other problems.

Yes. The one requesting the work could say "I want this calculated with these parameters, and I don't need the result until X blocks" or something similar.

Referenced transactions could be utilized to make sure payment is only done when a good result is verified.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

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

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?

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Come-from-Beyond on February 05, 2014, 01:56:40 AM

Quote from: jl777 on February 04, 2014, 06:40:15 PM

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.

OK, then one of the 28 to 32 instruction ones

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

Come-from-Beyond

legendary

Activity: 2142

Merit: 1010

Newbie

Quote from: jl777 on February 04, 2014, 06:40:15 PM

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.

Anon136

legendary

Activity: 1722

Merit: 1217

Quote from: Eadeqa on February 05, 2014, 01:52:51 AM

Quote from: Anon136 on February 05, 2014, 01:26:26 AM

If the network didnt check the forgers work than forgers could just publish false answers every time and claim the transaction fees anway. meaning they would have no incentive to actually execute the code.

The whole idea has security implications that we haven't even considered yet. This will turn out to be real bad for Nxt if malicious nodes are able to steal money.

There are many other things in the pipeline:

- Distributed Storage - In progress
- Multi-signatures - In progress
- Blockchain Shrinking - In progress
- Two-phase Payments - In progress
Software supported escrow transactions
- Voting System - In progress
- Reputation System - Will be implemented after Voting System
Account trust rating system. Check if sellers on the distributed exchange have a good history, if stock issuers pay dividends and if gateways honor their asset redemptions.
- Decentralized Mixing Service - Concept not ready - Cryptographers please contact core dev team members
- Distributed Computing - Concept not ready
- Smart Contracts - Concept not ready

Why not work on these?

It appears cfb has very short attention spam. Last week it was zerocoin, and now it's built in VM.

I hope he doesn't follow through this and focuses on finishing things already listed. Maybe more trusted developers should be added to the team. Looking at his posting history, I will vote for "CIYAM Open".

+1

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Eadeqa on February 05, 2014, 01:52:51 AM

Quote from: Anon136 on February 05, 2014, 01:26:26 AM

If the network didnt check the forgers work than forgers could just publish false answers every time and claim the transaction fees anway. meaning they would have no incentive to actually execute the code.

The whole idea has security implications that we haven't even considered yet. This will turn out to be real bad for Nxt if malicious nodes are able to steal money.

There are many other things in the pipeline:

- Distributed Storage - In progress
- Multi-signatures - In progress
- Blockchain Shrinking - In progress
- Two-phase Payments - In progress
Software supported escrow transactions
- Voting System - In progress
- Reputation System - Will be implemented after Voting System
Account trust rating system. Check if sellers on the distributed exchange have a good history, if stock issuers pay dividends and if gateways honor their asset redemptions.
- Decentralized Mixing Service - Concept not ready - Cryptographers please contact core dev team members
- Distributed Computing - Concept not ready
- Smart Contracts - Concept not ready

Why not work on these?

It appears cfb has very short attention spam. Last week it was zerocoin, and now it's built in VM.

I hope he doesn't follow through this and focuses on finishing things already listed. Maybe more trusted developers should be added to the team. Looking at his posting history, I will vote for "CIYAM Open".

Etherium

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

Anon136

legendary

Activity: 1722

Merit: 1217

Quote from: xyzzyx on February 05, 2014, 01:51:15 AM

Quote from: Anon136 on February 05, 2014, 01:50:07 AM

Quote from: xyzzyx on February 05, 2014, 01:44:02 AM

Thought experiment time. Let's say each node gets to run an arbitrary program in a VM, but only 1 instruction per block. Will that impact 1000 TPS transaction times?

How about 2 instructions per block?

I think you see where this is going.

N instructions per block (where N is variable based on the speed of the underlying hardware)?

Will that impact 1000 TPS transaction times?

It would make the problem even worse

I am a poor communicator. Sad

Oh so you are saying that the amount of operations required would be something of a time limit. it couldn't be included in a block until after enough blocks had passed inorder to make sure that low power cpus could keep up. that would address the transaction per second problem but it would address other problems.

LiQio

legendary

Activity: 1181

Merit: 1002

Quote from: xyzzyx on February 05, 2014, 01:51:15 AM

Quote from: Anon136 on February 05, 2014, 01:50:07 AM

Quote from: xyzzyx on February 05, 2014, 01:44:02 AM

Thought experiment time. Let's say each node gets to run an arbitrary program in a VM, but only 1 instruction per block. Will that impact 1000 TPS transaction times?

How about 2 instructions per block?

I think you see where this is going.

N instructions per block (where N is variable based on the speed of the underlying hardware)?

Will that impact 1000 TPS transaction times?

It would make the problem even worse

I am a poor communicator. Sad

*backslapping* - i got it

Eadeqa

hero member

Activity: 644

Merit: 500

Quote from: Anon136 on February 05, 2014, 01:26:26 AM

If the network didnt check the forgers work than forgers could just publish false answers every time and claim the transaction fees anway. meaning they would have no incentive to actually execute the code.

The whole idea has security implications that we haven't even considered yet. This will turn out to be real bad for Nxt if malicious nodes are able to steal money.

There are many other things in the pipeline:

- Distributed Storage - In progress
- Multi-signatures - In progress
- Blockchain Shrinking - In progress
- Two-phase Payments - In progress
Software supported escrow transactions
- Voting System - In progress
- Reputation System - Will be implemented after Voting System
Account trust rating system. Check if sellers on the distributed exchange have a good history, if stock issuers pay dividends and if gateways honor their asset redemptions.
- Decentralized Mixing Service - Concept not ready - Cryptographers please contact core dev team members
- Distributed Computing - Concept not ready
- Smart Contracts - Concept not ready

Why not work on these?

It appears cfb has very short attention spam. Last week it was zerocoin, and now it's built in VM.

I hope he doesn't follow through this and focuses on finishing things already listed. Maybe more trusted developers should be added to the team. Looking at his posting history, I will vote for "CIYAM Open".

Anon136

legendary

Activity: 1722

Merit: 1217

Quote from: Zahlen on February 05, 2014, 01:46:34 AM

Quote from: Anon136 on February 05, 2014, 01:26:26 AM

If the network didnt check the forgers work than forgers could just publish false answers every time and claim the transaction fees anway. meaning they would have no incentive to actually execute the code.

Algos could be designed to be easy to check. Like factoring numbers: difficult to factor, but easy to check that the product of factors is the original. Proof of computation! So one (or a few) beefy nodes have a large computation burden while many smaller nodes have a lower burden.

(Can't be done for all algos. This will incentivize and select for those which can be done more intelligently.)

Maybe but i don't know any good reason to expect this to be possible.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: Come-from-Beyond on February 05, 2014, 01:50:40 AM

Quote from: jl777 on February 04, 2014, 06:17:11 PM

So the script will be able to access any AM in the blockchain. The app needs to seed the script with the required block#, etc.
Will the scripts have an easy way to access alias data also? If so, that could be another way to pass data to the script

Scripts will have easy way to access any data on the blockchain.

Good morning Belarus!!!

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: CIYAM on February 05, 2014, 01:48:08 AM

Quote from: jl777 on February 05, 2014, 01:44:21 AM

If it is about bandwidth why was everyone so worked up about inefficiencies of subleq?

So interpreted subleq VM is not a CPU bottleneck?

You are worried about bandwidth and amount of AM?

I do think that "subleq" would end up becoming a CPU bottleneck but I am now going on the assumption we have an *efficient* instruction set (so am now ignoring the CPU issue) but I think that even assuming no CPU issue the bandwidth problem will be an even bigger problem.

I agree bandwidth is a big problem, but 1Mbps is supposed to available everywhere and much much more in Belarus

I am worried about beefy hub servers. We need lots of them to support 1000TPS and if we are going to have all those servers anyway, might as well use the CPU power. I have a feeling without running Turing scripts they will get bored at 1% load factor

Topic: NXT :: descendant of Bitcoin - Updated Information - page 1086. (Read 2761629 times)