Topic: Turing complete language vs non-Turing complete (Ethereum vs Bitcoin) - page 2. (Read 34821 times)

it's really much more than just a money system.  There's people on the forums making all sorts of suggestions: "Lets make a Distributed Wikipedia!".

I think it's really just an impractical use of this basic concept of a block chain.  I think they're getting carried away.  They seem to ignore the fact that in order for this to be truly p2p, every single node must execute that script and perhaps millions(or billions of them).  Of course this isn't a problem if you plan to sell the high end gear that makes this possible.  I remember for instance when color coins was at the peak of public interest there was an IBM guy hovering around, presumably he saw a market for IBM hardware there.

-bm

here's an example of an Ethereum script:


so basically you need to compute this script on the current 'global state' and hash it to verify the transactions(as I understand it).  It's certainly coming close to Java in it's complexity.  I imagine that it's optimized for object-code size and perhaps some other features.  Again what I think they might be ignoring is what it's going to take to support this and community acceptance.  Ripple had some good, 'correct' ideas but the community didn't like it.

-bm

Well I'm not sure Ethereum should have such a complex VM either :-)

As an example, JVM bytecodes are extremely verbose because it maps one class to one file and then uses strings to link them together. Dalvik solves that. Also JVM bytecode is for a stack machine that then has to be compiled down to register allocation on the fly at huge cost and complexity. You could do register allocation up front for a bunch of different register counts and simply the VM considerably. Dalvik also does this.

have you looked at Ethereum?   It's certainly not as complex as Java, but it's coming close and certainly as things progress there it will get more complex.  People have made specialize byte-code compilers before.  It would be interesting if someone could do a comparison of EVM opcodes and JVM opcodes.  Again the goal here is - how can we get this cheap?

I do somewhat agree, we don't need all this- but a new VM execution environment?  that just seems like a problem that was invented specifically so someone could solve it and make money with it.

-bm

I'm a big fan of the idea of revisiting Java mobile code at some point as there are now JVMs that are possibly simple enough to be secure with a heavily restricted class library. But not for cryptocurrency. It's just not needed and the format evolves faster than what we really need. Also it's needlessly verbose and hard to compile for no real good reasons. You'd do it quite differently if you redesigned it from scratch.

IMO evolving Script slowly and carefully is a way better path than trying to reuse Java.

Well to clarify, Java might be USED for a specific purpose today, but the original intention was to have little bits of executable code flying around the internet that are dynamically dispatched and executed.  This vision never really seemed to happen and instead we got a enhanced C("write once run anywhere") vision.

the fact is that Java bytecodes are very similar to what Ethereum has.  It's officially a "C like language" ... sound familiar?  Perhaps we could use a subset of the bytecodes?  I'm just trying to think of ways to get this functionality for cheap.  You can already see the ivory tower being constructed over at Ethereum.

So you could create a custom compilation environment that prohibits access to most of the System classes, and instead you get a very small feature set of functions(store value, check balance, etc.).  And then you get what Ethereum gives you, plus it's supported already on millions of devices and just about every computer.  They've got a couple of other things in there that would also need to be added- some complex of crypto functions on the opcodes.  I also suspect they've patented some of these ideas.

-bm

I really don't think Java bytecodes would be appropriate for a cryptocurrency. It's a tool designed for something entirely different.

Gregory is right, MASTs seem like a very reasonable way to allow larger programs to be built without causing huge blowup inside the chain, and being able to hide parts of the program opens up interesting possibilities for carefully constructed contracts.

Anyway, I'm sure there's a ton of cool stuff we can think of for Script 2.0 (I'd quite like some kind of reflection abilities), but we barely exploit Script 1.0 today! It seems kind of weak to be running ahead of ourselves here. The right place to invest at the moment IMHO is other parts of the toolchain, to make it really easy to build slick usable GUI apps that can manipulate contracts. That's what I've been working on with bitcoinj + the wallet-template app. Good cross platform APIs + lots of documentation + reusable templates to speed up development all give bigger wins right now that a more powerful scripting language, IMO.

also an interesting prospect: we already have Java-bytecode specific hardware, not only in Android but there was PicoJava.  http://en.wikipedia.org/wiki/PicoJava

so if Bytecode can be TX scripts, we've got a lot of stuff out of the box.  No need for VC, everything stays 'community'.  There are also open source implementations of the JVM.

-bm

btw - gmaxwell, gave some more thought to your points.  I think you need to read into the latest from Ethereum.  It's a lot more than just expanding the OPCODE set.  They have a random access memory system there and other functions available to the script environment.  It's a LOT more than just expanding the OPCODEs.

I think that doing DAC properly certainly would require something like this and in that sense it's good.  Every corporation has it's own distinct operator agreement thus we would need a way to define those rules on a per DAC basis.  But perhaps there are easier ways to do this?  I wonder if we can re-purpose Java bytecodes?  Not only do you get lots of tools, lots of existing community, lots of existing security and credibility, but the engine runs natively on Android.

so the basic question is do these break anything, and can we ascribe a 'gas' price to each code?  If we can do that, we can get something like a EVM for cheap- that gives up instant compatibility with a lot of platforms.  There are other functions as well that are required.

Also I think there are some holes to some of their premises, certainly has ramifications in the realm of 'but is it Peer to Peer'?  one thing I heard them say is 'you can turn off the script engine...', implying that we leave the heavy lifting up to 'professional nodes' - essentially disenfranchising most p2p network users, which isn't very p2p is it?  there is a solution to this but I won't say for now.

Also it seems that they were trying to achieve a way to have the Work in the PoW be something useful, they intimate this in various parts of the paper, however didn't achieve it.  So for now, it's a beefed up scripting engine for Bitcoin(they also updated the algorithm using something called GHOST).

Also I suspect many parts of this wont be open source.  Expect to see lots of smoke and mirrors here.

-bm

correct me if I'm wrong here, but it seems like you're suggesting just put a bound on the number of FLOPS, and if you exceed that they you pull some trigger that says 'BAD TX!  Dos PEER!', or some sort of punitive response.

this will give you the basic ability to loop, sure.  But as you say upgrading the script OPCODE set will be a significant deployment effort, so maybe it's best to go whole hog and group it with other desired features.

-bm

So in other words in Bitcoin the equivalent of Ethereum's "gas limit" is a single #define (or const int)?

Some links and concrete examples of advantages from you would be helpful. There is a lot of newfangled research in front-ends that I admittedly don't follow because I care too much about back-ends and overall quality and breadth of the implementations.

Yep. The only issue there that I'm aware of is the issue of priority calculation... but there are straightfoward ways to address that.

Why? The interpreter is already protected against this. Once the opcode limit is exeeded, the execution terminates, the transaction is rejected, and the peer is DoS banned.


Stack-based does not mean Forth. Just like LISP does not mean Common Lisp.

I suggest you look into Joy, Cat, Kitten, or one of the many other newer generation "concatenative" languages.

The way you describe it, I'm not sure I understand you properly. To me it reads somewhat like: a dynamic linker of scripts that uses late binding. Unlike conventional ld.so it does it not by name but by hash of the "_text" section.

Verification is then optimized because the actual linking wasn't really performed.

But getting back couple of pages to the requirements of resistance to DoS attacks (stated by Gavin), you'll still have to design your interpreter to be able to defend itself against somebody implementing a factorial or even an Ackermann function using the mutual recursion of a set of P2SH.
In light of P2SH it would be more like "stack of Forth derivatives" not a "single Forth derivative".
I'm not trying to say that Lisp is ideal. But in school I had to maintain both Forth and Lisp interpreters and deal with the bugs and improvement requests. Lisp tends to bunch all the pain at the beginning of the project. Forth projects start easily but continue to bleed you later on.

If you consider a task: "write a program in language X that takes another program in language X and transforms it in a certain way or verifies if it satisfies a certain condition" then for X == Lisp those programs tend to be the shortest or have already been written and debugged. This is the reason why I advocated Lisp for scripting in cryptocurrencies.

To add loops to script.cpp in the simplest way that achieves the goal in a hardforking change is that you add a "jump opcode" to the big switch statement which, if executing, changes the instruction pointer to a new value within the size of the script and continues execution. The patch is roughly four lines of code. Thats it, no "thread monitoring" (there is already an operation counter that will halt execution if more than 201 steps are taken), no "whole new VM", etc.

Like any change to the consensus code— which is a cryptosystem— It would, of course, require extensive review and to make it efficient you'd want to do as I said with making the nOpCount explicit, turned into a soft-forking change, or not be quite so ugly as a bare loop, etc. so a real implementation would be moderately more complex, but not like you seem to be thinking. Perhaps people in altcoins are proposing far more complicated things, but the currently published ethereum code (the older stuff that has almost nothing to do with their recent whitepapers) is pretty much precisely this "simplest thing" which I described above.

Now all the other things some people are talking about... I mean, some of these pure-whitepaper altcoins advertise features which I believe are impossible while their authors seem to have no concern that they might not be. About that stuff, who knows? But looping? Looping is not _that_ big deal it's also not obviously (to me) all that valuable either. "Meh."

maybe a derivative of Forth that doesn't have conditionals or loop statements?  that would make things much more manageable.

-bm

Lisp is actually not ideal here. Some sort of stack-based language with strong static typing would be an optimal choice (see, for example Kitten & Joy). But yes, Ethereum is re-inventing a square wheel here.

believe it or not I actually know how to use Lex and Yacc!  LOL.

still though, the project has a budget.  They've clearly got a sizeable marketing budget.  Have yet to see any Ethereum marketroids on here, perhaps soon...

-bm

From the purely-computer-science point of view the required interpreters, compilers, theorem-provers, etc. already exist and are well-debugged. They are available in every decent CS library under the very dirty and dusty keyword: Lisp. In one of those books there is a maxim: Those who don't know Lisp are doomed to reinvent it.

Obviously, Lisp doesn't directly plug into the Ethereum implementation. But knowing it would certainly remove lot of "fun" from reinventing the wheels for the Ethereum.

there are some intensely thought out ideas in the whitepaper.  That doesn't necessarily mean it's going to be a winner.  Sounds like another Ripple.

"All language designers are arrogant. Goes with the territory... " -Larry Wall

"not necessarily 100% open source"  and if it's anything like Ripple theyre going to do a little dance with this to keep people on the line.  Release some code, code some more privately, release a little here and there, "oh it's coming soon", "that part isn't open source", "did we say that?", etc.  Fact is there's an asymmetry here, the VCs are top down, and the community of potential users is decentralized.  Eventually though it seems Ripple lost the battle.  I heard they might be selling off to ABA or SWIFT.

-bm