freigeist
|
|
February 04, 2014, 09:57:38 PM |
|
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 , 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
|
|
February 04, 2014, 09:58:03 PM |
|
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
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 04, 2014, 09:58:22 PM |
|
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
Activity: 2142
Merit: 1010
Newbie
|
|
February 04, 2014, 09:59:37 PM |
|
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
Activity: 111
Merit: 10
|
|
February 04, 2014, 10:00:54 PM |
|
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_languagemaybe its ok?
|
|
|
|
freigeist
|
|
February 04, 2014, 10:01:59 PM |
|
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
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 04, 2014, 10:02:44 PM |
|
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.pdfSee 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
|
|
February 04, 2014, 10:02:56 PM |
|
rickyjames: you failed at reading CfB's quiz Sigh. I'm not as clever as I think.
|
|
|
|
jl777
Legendary
Offline
Activity: 1176
Merit: 1134
|
|
February 04, 2014, 10:03:18 PM |
|
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
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
February 04, 2014, 10:07:13 PM |
|
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
Activity: 1176
Merit: 1134
|
|
February 04, 2014, 10:08:35 PM |
|
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
|
|
|
|
BaiMangal
Member
Offline
Activity: 111
Merit: 10
|
|
February 04, 2014, 10:09:43 PM |
|
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
Activity: 2142
Merit: 1010
Newbie
|
|
February 04, 2014, 10:10:21 PM |
|
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
Activity: 1176
Merit: 1134
|
|
February 04, 2014, 10:12:28 PM |
|
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
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 04, 2014, 10:13:13 PM |
|
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
Activity: 2142
Merit: 1010
Newbie
|
|
February 04, 2014, 10:13:28 PM |
|
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
Activity: 2142
Merit: 1010
Newbie
|
|
February 04, 2014, 10:14:54 PM |
|
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
|
|
February 04, 2014, 10:15:57 PM |
|
rickyjames: you failed at reading CfB's quiz Sigh. I'm not as clever as I think. you're killing the Santa the "can not" test took only 10 seconds btw
|
|
|
|
jl777
Legendary
Offline
Activity: 1176
Merit: 1134
|
|
February 04, 2014, 10:16:07 PM |
|
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
|
|
|
|
xyzzyx
Sr. Member
Offline
Activity: 490
Merit: 250
I don't really come from outer space.
|
|
February 04, 2014, 10:17:14 PM |
|
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
|
|
|
|