Bitcoin Forum
November 16, 2024, 06:18:52 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 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 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761606 times)
freigeist
Hero Member
*****
Offline Offline

Activity: 1110
Merit: 534


View Profile
February 04, 2014, 09:57:38 PM
 #29161

Turing complete code executing is nice and flexible, but there still need to be useful solutions that are implemented based on this.

Let's just do it.
Will the Turing code be able to invoke higher level functions like "escrow NXT from acct to acct", "release escrow txid", "send DOGE", etc.

It would be great if the language had primitives for useful high level operations and made it so even incompetent guys like me can take a stab at writing some scripts.

What about something interactive like FORTH? I dont really like it, but I think it would be really quick to implement. Any chance to make it run a subset of Java?

The big problem that I see with DACs is reliably giving execution context to the scripts. That is really the issue, so why do we even have to lock down a language? Implement a VM with its own machine code (probably best to use existing simplified machine language) and then people can use any language they want as long as there is a compiler that emits the simplified machine code. The constraint on the execution time would be a time budget in addition to obvious memory limits, etc.

Would that be too difficult for your team to do? It would be cool to see a small unix running within NXT Smiley, very slow and expensive as it would need to allocate disk space using AM 1K blocks. Probably too crazy.

It would be cool to be able to interactively test the scripts. Maybe even make it like having a console and issue one off commands? Make NXT an OS that can do things only a decentralized system can do. This probably ties into the grid computing bullet point on the potential features list.

James


Choose your language:

Versions of non-JVM languages Language    On JVM
Erlang    Erjang
JavaScript    Rhino
Pascal    Free Pascal
PHP            Quercus
Python    Jython
REXX    NetRexx[2]
Ruby    JRuby
Tcl            Jacl
   
Languages designed expressly for JVM Language
BBj
Clojure
Fantom
Groovy
MIDletPascal
Scala
Kawa

Ebrelus
Full Member
***
Offline Offline

Activity: 186
Merit: 100



View Profile
February 04, 2014, 09:58:03 PM
 #29162

We will see soon a real battle between NXT, eMunie and Ethereum.

Ethereum can get big launch like Ripple because it is backed by wallstreet banksters... but it is doomed from start just because of this fact and manipulation possibility and lack of ability to make it trully anonymous and untraceable.

Both other has a real shot just because of being independent hand-made system (non-corporation product) with help of common people's money feedback.

You can see NXT decline now, because of approaching eMunie launch already. But it will recover very fast because ppl always want buy cheap coins and to not be late for a hype.  

Things which will be trully important to win this battle or be a step ahead will be:

- implementation of fluent, cheap and anonymous multi-currencies exchange
- coins mixing to hide currency and not be tracked by banks by default btc addresses (very important)
- nice easy to use wallet for non-geeks
- innovative features showing faster development than other cryptos and building a brand easy to remember
- cheapest and fastest possibility to exchange bitcoins for this second generation crypto  


Who will create a such easy to use "black market 2.0" will be unbittable because of hype.
No promotion will be needed when it will kick off. Just being first or second will be important.
xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 04, 2014, 09:58:22 PM
 #29163

What about something interactive like FORTH? I dont really like it, but I think it would be really quick to implement.

See Threaded Interpretive Languages by Loeliger [Scribd]

...why do we even have to lock down a language? Implement a VM with its own machine code (probably best to use existing simplified machine language) and then people can use any language they want as long as there is a compiler that emits the simplified machine code. The constraint on the execution time would be a time budget in addition to obvious memory limits, etc.

See:
https://bitcointalk.org/index.php?topic=345619.msg4937622#msg4937622

"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: 2142
Merit: 1010

Newbie


View Profile
February 04, 2014, 09:59:37 PM
 #29164

Choose your language:

Versions of non-JVM languages Language    On JVM
Erlang    Erjang
JavaScript    Rhino
Pascal    Free Pascal
PHP            Quercus
Python    Jython
REXX    NetRexx[2]
Ruby    JRuby
Tcl            Jacl
   
Languages designed expressly for JVM Language
BBj
Clojure
Fantom
Groovy
MIDletPascal
Scala
Kawa

We need a low-level language. Most (all?) languages in ur list r high-level.
BaiMangal
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
February 04, 2014, 10:00:54 PM
 #29165

Choose your language:

Versions of non-JVM languages Language    On JVM
Erlang    Erjang
JavaScript    Rhino
Pascal    Free Pascal
PHP            Quercus
Python    Jython
REXX    NetRexx[2]
Ruby    JRuby
Tcl            Jacl
   
Languages designed expressly for JVM Language
BBj
Clojure
Fantom
Groovy
MIDletPascal
Scala
Kawa

We need a low-level language. Most (all?) languages in ur list r high-level.

I knew this one 20 years ago
http://en.wikipedia.org/wiki/Assembly_language

maybe its ok?
freigeist
Hero Member
*****
Offline Offline

Activity: 1110
Merit: 534


View Profile
February 04, 2014, 10:01:59 PM
 #29166


We need a low-level language. Most (all?) languages in ur list r high-level.

Sorry my mistake I though you need something that could work on java VM
and is already implemented.


xyzzyx
Sr. Member
****
Offline Offline

Activity: 490
Merit: 250


I don't really come from outer space.


View Profile
February 04, 2014, 10:02:44 PM
 #29167

We need a low-level language. Most (all?) languages in ur list r high-level.

There's always the simple VM outlined in this as a starting point:
http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf

See chapter 9: A RISC-Architecture as Target.

"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
rickyjames
Full Member
***
Offline Offline

Activity: 196
Merit: 100


View Profile
February 04, 2014, 10:02:56 PM
 #29168

rickyjames: you failed at reading CfB's quiz  Cool

Sigh.  I'm not as clever as I think.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1134


View Profile WWW
February 04, 2014, 10:03:18 PM
 #29169


I want NXT AE to be able to do trustless trading of all other cryptos. No more waiting for centralized exchanges to find the missing deposit/withdrawal, just trade with NXT and BAM! you get DOGE in your DOGE wallet. much trading

It this is build into the protocol and the minimum transaction fee is 1 NXT, we will get a LARGE amount of Chinese traders making 100,000 BTC worth of trades every day. High frequency traders are very sensitive to any fees they incur. A fully decentralized and automated exchange of all cryptos against NXT will instantly make NXT the reserve currency of crypto.

The point for Turing complete is to allow others to build useful solutions. The above is such a useful solution and we need it live BEFORE any other crypto enables it

I have already 100000 NXT bounty allocated for this, regardless of how it is implemented. XCP is the initial other crypto, but it should be modular so we can pop in any other crypto realtively easily.

James

How do you imagine to be able to trade BTC on the NXT AE without having a gateway? I saw other guys talking about trustless trading but without gateway how one would enter with BTC or DODGE or EURO value in the NXT AE?

We have a gateway ready to launch as soon as the AE is released but thats not 100% trustless becuase people will have to get our assets, either in BTC or LTC or EURO(soon).
This way we can have NXT Assets traded but its not completely trustless...
The problem with colored coins concept, ripple, AE, XCP, all of them, is there is always the gateway that needs to be trusted. No offense to you, but this is fundamentally a single point of failure.

I am talking about directly doing trades with other coins blockchains so there is no need for any trust. The code is open source and deals with the escrow process on both coins and makes sure each party gets the other coin. Some magic with multisig and timeouts can implement this, eg from URLs I posted.

A simplified idea is to automate the functions of a gateway deposit and withdrawal. Put in escrow checkpoints (this is the hard part as funds need to get swept into a separate escrow acct) and the only thing you need to trust is that the software continues running. We can provide that assurance by making sure altcoind's are installed on 100+ hub servers and that the software that manages the escrow process gets runtime on these hub servers.

I see the high level pieces, but I cannot solve all the details myself. The big problem is how to be able to set aside DOGE in a "global" account that can then be accessed by whichever node is the forging node when the time comes to finalize the transaction.

I need help from some of the smarter guys here to figure this out. We will get NXT escrow ability, if anything from the NXTcash effort, so once we have that, the NXT side is done for this. Just need a way to do trustless decentralized escrow of BTC and other altcoins.

James

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

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
February 04, 2014, 10:07:13 PM
 #29170

Choose your language:

Versions of non-JVM languages Language    On JVM
Erlang    Erjang
JavaScript    Rhino
Pascal    Free Pascal
PHP            Quercus
Python    Jython
REXX    NetRexx[2]
Ruby    JRuby
Tcl            Jacl
   
Languages designed expressly for JVM Language
BBj
Clojure
Fantom
Groovy
MIDletPascal
Scala
Kawa

We need a low-level language. Most (all?) languages in ur list r high-level.

Why? What's the difference?
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1134


View Profile WWW
February 04, 2014, 10:08:35 PM
 #29171

Will the Turing code be able to invoke higher level functions like "escrow NXT from acct to acct", "release escrow txid", "send DOGE", etc.

I think it's a bad idea. The language should have simple operations with near-equal consumption of resources. In this case it will be easy to assess fee required for contract execution.
Time used should be the key, maybe adjust it for CPU speed of forging node. Current swap state would need to be put into blockchain so next forging node can pick up where it left off, but we can limit memory space.

I am envisioning services provided by code running on the hub servers, so it is feasible to have 20 different altcoind's running and ready to be called. Also, anything else we can think of can be encapsulated into a function call. Need to be able to suspend a script after time limit anyway, otherwise infinite loop will be bad problem

James

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

Activity: 111
Merit: 10


View Profile
February 04, 2014, 10:09:43 PM
 #29172


I want NXT AE to be able to do trustless trading of all other cryptos. No more waiting for centralized exchanges to find the missing deposit/withdrawal, just trade with NXT and BAM! you get DOGE in your DOGE wallet. much trading

It this is build into the protocol and the minimum transaction fee is 1 NXT, we will get a LARGE amount of Chinese traders making 100,000 BTC worth of trades every day. High frequency traders are very sensitive to any fees they incur. A fully decentralized and automated exchange of all cryptos against NXT will instantly make NXT the reserve currency of crypto.

The point for Turing complete is to allow others to build useful solutions. The above is such a useful solution and we need it live BEFORE any other crypto enables it

I have already 100000 NXT bounty allocated for this, regardless of how it is implemented. XCP is the initial other crypto, but it should be modular so we can pop in any other crypto realtively easily.

James

How do you imagine to be able to trade BTC on the NXT AE without having a gateway? I saw other guys talking about trustless trading but without gateway how one would enter with BTC or DODGE or EURO value in the NXT AE?

We have a gateway ready to launch as soon as the AE is released but thats not 100% trustless becuase people will have to get our assets, either in BTC or LTC or EURO(soon).
This way we can have NXT Assets traded but its not completely trustless...
The problem with colored coins concept, ripple, AE, XCP, all of them, is there is always the gateway that needs to be trusted. No offense to you, but this is fundamentally a single point of failure.

I am talking about directly doing trades with other coins blockchains so there is no need for any trust. The code is open source and deals with the escrow process on both coins and makes sure each party gets the other coin. Some magic with multisig and timeouts can implement this, eg from URLs I posted.

A simplified idea is to automate the functions of a gateway deposit and withdrawal. Put in escrow checkpoints (this is the hard part as funds need to get swept into a separate escrow acct) and the only thing you need to trust is that the software continues running. We can provide that assurance by making sure altcoind's are installed on 100+ hub servers and that the software that manages the escrow process gets runtime on these hub servers.

I see the high level pieces, but I cannot solve all the details myself. The big problem is how to be able to set aside DOGE in a "global" account that can then be accessed by whichever node is the forging node when the time comes to finalize the transaction.

I need help from some of the smarter guys here to figure this out. We will get NXT escrow ability, if anything from the NXTcash effort, so once we have that, the NXT side is done for this. Just need a way to do trustless decentralized escrow of BTC and other altcoins.

James

I completely agree that having a gateway is not the real solution.
If trusltless exchange can be done this will be the best thing ever!!! This will solve so many issues!
Having hub or what ever with some sort of access is always going to be attacked etc.. but yes hopefully some genius guy will have a solution.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1010

Newbie


View Profile
February 04, 2014, 10:10:21 PM
 #29173

Choose your language:

Versions of non-JVM languages Language    On JVM
Erlang    Erjang
JavaScript    Rhino
Pascal    Free Pascal
PHP            Quercus
Python    Jython
REXX    NetRexx[2]
Ruby    JRuby
Tcl            Jacl
   
Languages designed expressly for JVM Language
BBj
Clojure
Fantom
Groovy
MIDletPascal
Scala
Kawa

We need a low-level language. Most (all?) languages in ur list r high-level.

Why? What's the difference?

Once we have a low-level language we'll be able to use any high-level language to translate it into low-level one.

Translation from high-level to high-level is much more difficult.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1134


View Profile WWW
February 04, 2014, 10:12:28 PM
 #29174

We will see soon a real battle between NXT, eMunie and Ethereum.

Ethereum can get big launch like Ripple because it is backed by wallstreet banksters... but it is doomed from start just because of this fact and manipulation possibility and lack of ability to make it trully anonymous and untraceable.

Both other has a real shot just because of being independent hand-made system (non-corporation product) with help of common people's money feedback.

You can see NXT decline now, because of approaching eMunie launch already. But it will recover very fast because ppl always want buy cheap coins and to not be late for a hype.  

Things which will be trully important to win this battle or be a step ahead will be:

- implementation of fluent, cheap and anonymous multi-currencies exchange
- coins mixing to hide currency and not be tracked by banks by default btc addresses (very important)
- nice easy to use wallet for non-geeks
- innovative features showing faster development than other cryptos and building a brand easy to remember
- cheapest and fastest possibility to exchange bitcoins for this second generation crypto  


Who will create a such easy to use "black market 2.0" will be unbittable because of hype.
No promotion will be needed when it will kick off. Just being first or second will be important.
I have 100000 NXT bounty to solve your first item
Actively working on adding zerocoin to NXT
Four clients released already or soon to be
Turing complete scripting discussed right now

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 04, 2014, 10:13:13 PM
 #29175

Once we have a low-level language we'll be able to use any high-level language to translate it into low-level one.

If you use the abstract syntax tree based approach of Franz, your code would be platform neutral and any high-level language would only need to target the AST.

"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: 2142
Merit: 1010

Newbie


View Profile
February 04, 2014, 10:13:28 PM
 #29176

Will the Turing code be able to invoke higher level functions like "escrow NXT from acct to acct", "release escrow txid", "send DOGE", etc.

I think it's a bad idea. The language should have simple operations with near-equal consumption of resources. In this case it will be easy to assess fee required for contract execution.
Time used should be the key, maybe adjust it for CPU speed of forging node. Current swap state would need to be put into blockchain so next forging node can pick up where it left off, but we can limit memory space.

I am envisioning services provided by code running on the hub servers, so it is feasible to have 20 different altcoind's running and ready to be called. Also, anything else we can think of can be encapsulated into a function call. Need to be able to suspend a script after time limit anyway, otherwise infinite loop will be bad problem

James

Resource/fee consumption must be forger-agnostic.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1010

Newbie


View Profile
February 04, 2014, 10:14:54 PM
 #29177

Once we have a low-level language we'll be able to use any high-level language to translate it into low-level one.

If you use the abstract syntax tree based approach of Franz, your code would be platform neutral and any high-level language would only need to target the AST.

Nxt is simple. Let's follow KISS principle as long as possible.
salsacz
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


View Profile
February 04, 2014, 10:15:57 PM
 #29178

rickyjames: you failed at reading CfB's quiz  Cool

Sigh.  I'm not as clever as I think.
you're killing the Santa Sad the "can not" test took only 10 seconds btw
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1134


View Profile WWW
February 04, 2014, 10:16:07 PM
 #29179

Choose your language:

Versions of non-JVM languages Language    On JVM
Erlang    Erjang
JavaScript    Rhino
Pascal    Free Pascal
PHP            Quercus
Python    Jython
REXX    NetRexx[2]
Ruby    JRuby
Tcl            Jacl
   
Languages designed expressly for JVM Language
BBj
Clojure
Fantom
Groovy
MIDletPascal
Scala
Kawa

We need a low-level language. Most (all?) languages in ur list r high-level.

Why? What's the difference?

Once we have a low-level language we'll be able to use any high-level language to translate it into low-level one.

Translation from high-level to high-level is much more difficult.
So we agree then. Simplified machine language of some sort. Preferably one that already has compilers for C!

Just add ability to make function calls that are implemented by processes running on hub servers. Saving state to blockchain and each forging node restores it. Might need to charge 1 NXT for each context, but I bet a lot of people will gladly pay that to make sure their withdrawals are verified on external blockchain!!

James

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 04, 2014, 10:17:14 PM
 #29180

Once we have a low-level language we'll be able to use any high-level language to translate it into low-level one.

If you use the abstract syntax tree based approach of Franz, your code would be platform neutral and any high-level language would only need to target the AST.

Nxt is simple. Let's follow KISS principle as long as possible.

Is there something that you would need me to code up as a proof-of-concept in order to consider the AST approach?

"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
Pages: « 1 ... 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 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 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!