Bitcoin Forum
July 21, 2019, 05:53:14 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 [1476] 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 ... 2567 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2755394 times)
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
February 05, 2014, 06:56:40 AM
 #29501

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.
1563731594
Hero Member
*
Offline Offline

Posts: 1563731594

View Profile Personal Message (Offline)

Ignore
1563731594
Reply with quote  #2

1563731594
Report to moderator
1563731594
Hero Member
*
Offline Offline

Posts: 1563731594

View Profile Personal Message (Offline)

Ignore
1563731594
Reply with quote  #2

1563731594
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563731594
Hero Member
*
Offline Offline

Posts: 1563731594

View Profile Personal Message (Offline)

Ignore
1563731594
Reply with quote  #2

1563731594
Report to moderator
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 05, 2014, 06:58:19 AM
 #29502

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?

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2014, 06:59:03 AM
 #29503

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?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 05, 2014, 07:00:41 AM
 #29504

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. 

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 05, 2014, 07:04:54 AM
 #29505

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
swartzfeger
Full Member
***
Offline Offline

Activity: 350
Merit: 100


View Profile
February 05, 2014, 07:05:08 AM
 #29506

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
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 05, 2014, 07:07:40 AM
 #29507

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.

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 05, 2014, 07:08:06 AM
 #29508

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
February 05, 2014, 07:08:46 AM
 #29509


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.

NXT-GZYP-FMRT-FQ9K-3YQGS
https://nxtforum.org
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 05, 2014, 07:10:25 AM
 #29510

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 05, 2014, 07:11:17 AM
 #29511

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.

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2014, 07:12:20 AM
 #29512

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Anon136
Legendary
*
Offline Offline

Activity: 1666
Merit: 1211



View Profile
February 05, 2014, 07:13:13 AM
 #29513

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?


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.

Rep Thread: https://bitcointalk.org/index.php?topic=381041
If one can not confer upon another a right which he does not himself first possess, by what means does the state derive the right to engage in behaviors from which the public is prohibited?
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 05, 2014, 07:14:05 AM
 #29514


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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 05, 2014, 07:14:29 AM
 #29515

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.

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
Fatih87SK
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500



View Profile
February 05, 2014, 07:15:29 AM
 #29516

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!  Shocked
I'm just speaking out loud.   Cheesy

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
Legendary
*
Offline Offline

Activity: 857
Merit: 1000



View Profile WWW
February 05, 2014, 07:15:58 AM
 #29517

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
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 05, 2014, 07:17:04 AM
 #29518

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.

"An awful lot of code is being written ... in languages that aren't very good by people who don't know what they're doing." -- Barbara Liskov
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2128
Merit: 1009

Newbie


View Profile
February 05, 2014, 07:19:24 AM
 #29519

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

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
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
February 05, 2014, 07:19:49 AM
 #29520

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.

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Pages: « 1 ... 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 [1476] 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 ... 2567 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!