Pages:
Author

Topic: On the way to the post-Ethereum world (Read 1942 times)

hero member
Activity: 672
Merit: 500
June 17, 2016, 06:56:12 PM
#44
  I don't know as much about Serpent, but it appears to have the same goals and purpose as Solidity, but is meant to be similar to Python (and therefore be great for Python devs.) This, along with the range of clients, also showcases the dedication that Ethereum has to being appealing to a wide range of developers, not just Javascript developers.

The range of clients at Ethereum in Go, C++, Python, JavaScript, Java and other languages is a support disaster. Right now it may work OK, but once Ethereum attracts a critical mass there will be 1 (or maybe 2) clients which will be used by 99% of the users. Otherwise, it's just not feasible.

You also say that Ethereum is trying to appeal a wide range of developers. Lisk tends to focus on the JavaScript group, it's just a fact that this is a huge crowd already. Lisk removes friction, it's very hard to get developers for a platform. If they now need to learn a new language (besides the whole blockchain concepts) attracting them will be even more difficult. Lisk is all about staying lean, efficient and focused.

Btw. JS is extremely powerful any goof on this forum with some legendary status who says other wise has other motives or is really ignorant: asmjs.org, pyjs.org etc.

    Above only covers Smart Contracts for Etheruem; what about the more fully-encompassing "Dapp"?

Here is the difference between Lisk and Ethereum. Ethereum is doing smart contracts which are all saved on one blockchain. If you want to develop a dapp in Ethereum you need to connect the functionalities of several smart contracts.

In Lisk you get a complete package. You don't develop single smart contracts. You build an entire application which is running on its own blockchain. It's like you develop a new crypto-currency platform with an extended feature-set, the platform itself is already finished and provided by our Lisk SDK. As a developer you just need to implement the necessary new features on top of the already existing platform.

    So, for Lisk to be implying that Javascript developers cannot create Dapp for Ethereum is a bit misleading. They can absolutely use primarily Javascript for the Dapp and then Solidity (which is so close to Javascript) for smart contracts.

We never said that JavaScript developers cannot create dapps for Ethereum. Of course they can, but they need to learn a new language first. This is like you would say a plumber cannot paint walls.

At Ethereum they can use JavaScript for the dapp front end, and Solidity for the dapp back end. It's not like they are using JavaScript "for the [complete] dapp" as you said. No, only for the front end.

    The difference is that Lisk is entirely Javascript (and node.js) through and through, Ethereum has a large number clients in different languages[2], has two custom-written languages for smart contracts, and still allows for Javascript where you need it most (the UI).

Yes, we tend to focus on one technology. Focus is key.

Your statement that Ethereum "allows for JavaScript where you need it most (the UI)", is really only the case for Ethereum. JavaScript is globally accepted for many different tasks on the front and back end (e.g. NodeJS). Not just for "the UI". You are making JavaScript smaller as it is, only to get more arguments for Solidity.

    Javascript numbers are....not the greatest or most reliable. Especially when we are dealing with a crypto-currency, you really want your numbers to be on point. Basically JS uses floating point which means some things get approximated and digits get lost in certain cases.

We are only using integers at Lisk. For big numbers we are using bignumber.js. It's not about the language you choose, it's about your coding skills. If you know what you are doing JavaScript is entirely fine. However, yes this is a weakness. But a weakness which is manageable.

    Javascript uses weak dynamic typing. If you are not careful, you can pass strings instead of numbers.

Honestly, if you are building a serious project you should at least get this thing right. Otherwise, every JavaScript project would fail according to your argument.

    Lisk has "rules" that they ask contract developers have to follow to avoid breaking consensus.

Yep. It seems Ethereum has these "rules" directly embedded into their compiler, at Lisk developers just have to follow them. The biggest difference here is, if they do a mistake and the consensus is broken, then the dapp needs a hard fork. But Lisk itself is entirely fine, because the dapp is only running in a sidechain.

This is a huge security advantage. If a dapp fails, the Lisk network doesn't even hiccup. However, if one smart contract fails at Ethereum, it can mean game over for Ethereum.

    Disadvantages of Solidity

Other disadvantages may be that it's a very young language and therefore unproven. Also there is very little documentation available, and even less developers know this language.

    On the blockchain

You are mixing up different things now. You download the Bitcoin client also from an HTTP link. However it "cannot be corrupted, can be audited, cannot be changed, can reach consensus". That means all these important properties you mention are also valid for Lisk. If you change a dapp code, your node will end up on a fork. Same as if you change the Bitcoin code.

The HTTP link is only the way to distribute a dapp source code. Later on we will integrate decentralized storage methods (e.g. IPFS), so the distribution itself can be decentralized as well.

However, the distribution model doesn't define if an application is centralized or decentralized. Or do you say that every crypto-currency on the market is centralized? Because you download the clients from a centralized location? If yes, then how can Ethereum dapps even be decentralized, if the network itself is centralized? Wink

Your line of arguments is wrong here. Another important fact is, that this method allows Lisk to scale massively easier than Ethereum. Besides the huge advantages our sidechains already bring to the table.

    I don't know much about Crypti, but they did have a presale and they did get a decent amount of money (at least $200k USD) but I can't find the exact figures because everything has been wiped. Nothing came of Crypti. Literally. So...that's scary. The lack of transparency, also scary.

We are not associated with Crypti anymore. However, saying that everything is wiped and that there is no transparency is a huge lie. There are over 600 pages on Bitcointalk (https://bitcointalksearch.org/topic/xcr-crypti-dapps-sidechains-dapp-store-open-source-100-own-code-dpos-654463) and dozens of blog posts (https://blog.crypti.me) which contain ALL information.

Additionally, if you say that "nothing came of Crypti" then you are completely wrong. Crypti developed a working dapp platform, the huge success of Lisk is proving this. The only thing which just didn't work at Crypti was marketing. That means nobody knows about Crypti. There was also a big lack of leadership at Crypti.

    So I guess the main difference I want to point out between Ethereum and Lisk here is that Lisk is two guys who rebranded a previous coin that had a presale and delivered nothing while Ethereum has Vitalik Buterin, a large team of well-known, community-engaged, crazy talented developers, and a large community of developers creating Dapp and third-party wallets and hardware wallets and all sorts of amazing stuff. I mean, look at Augur, Slock.it, and ConsenSys alone. It's crazy!

Yes, I'm glad that those two guys at Google never started their company because there were so many great search engines back then with hundreds of employees. Smiley

Don't understand me wrong, I like Ethereum and the whole team/movement behind it. I'm a big supporter. But you are just refusing innovation at this point of time. You are comparing a 2 years old platform (Ethereum) with 18M in fundings, with a not even launched platform (Lisk) with no access to the funding as of yet. That's kind of silly.

    Another key difference is Ethereum has the Ethereum Foundation, a non-profit Swiss organization and Lisk has....an unknown foundation / company associated with it.

Everyone at Lisk knows that we are in the process of creating a legal entity in Germany, most probably as a gGmbH. This is also a non-profit organisation structure.

    One final note: Lisk really likes to claim they have partnerships with big names. First it was ShapeShift. Now it is Microsoft. They loooove to use that partnership word. In reality, they were just using the Shifty button, not really a partnership.

We had a technologic partnership with ShapeShift. It was a big mis-understanding at that time. They already fixed that mistake.

All in all, I would like to say that your points are quite weak. You didn't point out the biggest weaknesses of Lisk. In my opinion this is sidechain security. That means small dapps probably won't have a chance long-term to attract enough nodes to secure them.

For this I suspect that there will be special dapps, who will run smaller dapps in a SaaS way. Until we implemented a sidechain forging marketplace, finding sidechain forgers is also quite a difficult task. However, these are all just starting problems. Everything is solvable. At the end of the day Lisk is just software which is actively developed.

It's important to mention that Lisk just gets started and we are already making big changes. At this point of time it's just to early to evaluate Lisk and the team (us) behind it. You should just wait for a year before making a final conclusion. All arguments right now just look like you are afraid. Personally, I think there is far more than enough room for Ethereum and Lisk. In the end we are solving the "problems" very differently and are attracting different niches.

I hope that Ethereum and Lisk can work together in the future in order to solve important problems within the dapp and blockchain industry. I say it again, we are in this "game" together.


full member
Activity: 734
Merit: 109
June 17, 2016, 04:32:29 PM
#43
What a "wanker" you are.

Every time I win the technical argument, you refuse to mea culpa. Stubborn ox.

Except you have never won a single technical argument against me (you idiot).

Try actually arguing rather than insulting next time (but I know you won't as you never do).


This is not a technical problem more.
Overall investment in The DAO is 11,725,223.9 Ether...

I am curious: who and how many invest in the next eth application.
sr. member
Activity: 336
Merit: 265
June 17, 2016, 03:37:37 PM
#42
Can we just close this thread already. Well known developer posts about most important topic of the day and you guys get into 2-page pissing match over browser crashes. Sorry Kushti.

Right, this is very sad. Do we have a chance to have a thoughtful online discussion somewhere these days?

What would you like to discuss?

Call me skeptical, but your reply to froggy512 seems to be more about you two colluding for political and promotional reasons, trying to paint you as well known developer and CIYAM and myself as not well known (or somehow unimportant relative to yourself) developers.

Excuse me if I am mistaken, but if you want to have a discussion then it doesn't help if you offend the person who was doing correct technological and meritorious posting in the thread. I really can't help it that CIYAM went off into a tirade. Do you think it makes me feel good when you slander me by agreeing with froggy512?

Sorry that BCT is all politics and grandstanding. I tried to participate in your thread and I get labeled as a troublemaker by you and froggy. That doesn't feel like a meritocracy to me, but any way it is your thread, so I'll just not participate further. Good luck.

P.S. you'll note I tried to ask CIYAM not to continue derailing the thread. I couldn't stop him.  I don't have control over his fingers.
full member
Activity: 317
Merit: 103
June 17, 2016, 01:54:55 PM
#41
Can we just close this thread already. Well known developer posts about most important topic of the day and you guys get into 2-page pissing match over browser crashes. Sorry Kushti.

Right, this is very sad. Do we have a chance to have a thoughtful online discussion somewhere these days?
sr. member
Activity: 336
Merit: 265
June 17, 2016, 10:59:05 AM
#40
Can we just close this thread already. Well known developer posts about most important topic of the day and you guys get into 2-page pissing match over browser crashes. Sorry Kushti.

Btw, that wasn't fundamentally about browser crashes; it was addressing which high-level-language is appropriate for smart contract VMs, which was what Kushti and CIYAM were discussing. CIYAM seemed to be suggesting we should employ only assembly or C, and I was pointing out that ASM.js is almost native speed and runs every where as JIT.

Hey I didn't want that. I had to respond to his pissing. I just suggested he not speak incorrectly about JS and be aware of ASM.js.

The likely reasons CIYAM has some vengeance towards me include:

https://bitcointalksearch.org/topic/m.15233941
https://bitcointalksearch.org/topic/m.13926249  (was followup to: https://bitcointalksearch.org/topic/m.13580146)
https://bitcointalksearch.org/topic/m.13887894

I'll chime in before @TBTB comes in and tells everyone that they are stupid and only he knows the answer to everything (at that point I'll quit watching this topic as I've done with every other topic he has ruined - and he ruins every topic he posts in basically).

The relationship between "reward" and "minting" could be made less "one-to-one" but more statistically probable if you mint more blocks (thus providing an incentive to mint but not even needing to be POW).

You need ways to discern "winners" if you aren't using POW as the only measurement (although I think some amount of POW is going to always be required to help prevent the NAS attack issue which I've discovered can even occur "by accident" when using different approaches).

This is a key part of the CIYAM blockchain design (which I am not going to discuss here, however, unlike some others it isn't some silly conjecture or "academic breast beating" but already published open source code which it seems @TBTB is actually unable to understand which rather pleases me).

As a simplistic idea imagine that a block reward only occurs every X blocks but is more likely to favour the minter that has produced as many of those X blocks as possible (and also imagine that rules prevent them from being able to produce all of the blocks).

newbie
Activity: 19
Merit: 0
June 17, 2016, 10:43:08 AM
#39
Can we just close this thread already. Well known developer posts about most important topic of the day and you guys get into 2-page pissing match over browser crashes. Sorry Kushti.
sr. member
Activity: 336
Merit: 265
June 17, 2016, 10:06:18 AM
#38
If you won't even bother to read the information then there is really no point in any discussion.

You have failed to point out any mistake on my part. I did read it. They confirm what I am telling you.

I maintain you are wrong. You are welcome to point out what you think is my  mistake. Until you do, you are a liar.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 10:05:02 AM
#37
If you won't even bother to read the information then there is really no point in any discussion.

I'm sure that the @OP is sick of this so I am going to unwatch and leave you to your stupid "final troll" (am sure you will).

(the thing that will piss you off is that I won't read your final troll post and don't give a fuck about you or your stupid posts anyway)
sr. member
Activity: 336
Merit: 265
June 17, 2016, 10:03:39 AM
#36
Please educate yourself: https://groups.google.com/forum/#!topic/comp.lang.javascript/332YSnPsw_w/discussion

Memory is a finite resource and the OS will be forced to kill the thread as virtual memory is exhausted else the entire OS will come crashing down.

So sorry, that is the only way to crash JS as I said.

CPU hogging can be handled by setting the thread to lower priority. But memory exhaustion can't be handled without halting.

Sorry you are still wrong.

(only an idiot would "assume" that GC is the cause of all browser crashes)

Wake me up when you realize the relevance of "no GC" to your point about the browser crashing.

What on earth does GC have to do with that?

Btw, memory leaks without GC often result in a crash by accessing a pointer after freeing the memory. In JS which is memory safe, the crash is by exhausting all resources.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 09:57:45 AM
#35
You have failed to point out any mistake.

I provided a llink (which you didn't quote) - read it.

And again debating about the meaning of the word "crash" is just your way of trying to save face.

If you didn't try to be such an arrogant "know it all" asshole then these "discussions" wouldn't occur - ever considered that maybe you should try and "tone it down" a notch or two?
sr. member
Activity: 336
Merit: 265
June 17, 2016, 09:55:57 AM
#34
Sorry - you just don't understand how .js works do you?

Please don't lie.

Your slimy ethics are coming clear to all readers now.

I didn't lie (and you have failed to admit your mistake).

You have failed to point out any mistake.

Memory (semantic) leaks are the only way I know of to exhaust resources and cause a JS program to halt in a way not encoded intentionally (e.g. throw) in the source code (other than killing the thread which the browser may even prompt the user to do but that isn't a "crash").

Of course I guess you can apply those leaks to any exhaustable resource, not just memory such as disk space.

This is not really a crash if you ask me. It just makes the browser unresponsive by using all the CPU.

You should ask yourself who would benefit from making someones browser unresponsive. Not site owners, they generally like their users. Not hackers, they would only crash your browser if it allowed them to run privileged code on your machine. That leaves trolls.

But assuming this is a real issues, think about how you could stop it.
Most browsers already do detect infinite loops and let you stop the script.
But in the complex case, how do you distinguish a CPU intensive page from one that intentionally hogs the CPU? You can't, so you'd hamper JS games and the like by limiting their CPU usage.

Edit: just in case someone is thinking that JS can crash with an exception due to dynamic types, e.g. when calling a function that expects a certain type and throws when it doesn't ... please make sure you remember that my point was ASM.js eliminates the dynamic typing (and GC). That was already factored into my logic. Wink
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 09:54:13 AM
#33
Sorry - you just don't understand how .js works do you?

Please don't lie.

Your slimy ethics are coming clear to all readers now.

I didn't lie (and you have failed to admit your mistake).

The only one with "slimy ethics' here is you (and I have now "caught you out").

Please educate yourself: https://groups.google.com/forum/#!topic/comp.lang.javascript/332YSnPsw_w/discussion
sr. member
Activity: 336
Merit: 265
June 17, 2016, 09:50:40 AM
#32
You wouldn't get a "crash" according to your definition with a GC issue either.

Learn to read:

A crash is when there is an exception and the program can't continue executing. Since JS is memory safe, the only way to accomplish that is to exhaust resources.

Now that you've been spanked by an expert, go cry to moma.

Sorry - you just don't understand how .js works do you?

Please don't lie.

Your slimy ethics are coming clear to all readers now.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 09:48:58 AM
#31
You wouldn't get a "crash" according to your definition with a GC issue either.

Learn to read:

A crash is when there is an exception and the program can't continue executing. Since JS is memory safe, the only way to accomplish that is to exhaust resources.

Now that you've been spanked by an expert, go cry to moma.

Sorry - you just don't understand how .js works do you?

(now go and read up yourself and apologise after you work out your mistake)

I am enjoying making fun of you.

Cheesy
sr. member
Activity: 336
Merit: 265
June 17, 2016, 09:47:44 AM
#30
You wouldn't get a "crash" according to your definition with a GC issue either.

Learn to read:

A crash is when there is an exception and the program can't continue executing. Since JS is memory safe, the only way to accomplish that is to exhaust resources.

Now that you've been spanked by an expert, go cry to moma.



Why don't you just stop trying to be a smart-arse?

(no-one admires you for it)

Hey I just informed you about ASM.js and you got all offended and derailed the thread. You wanted to pick a fight, and so you induced me to fight back. See how that works.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 09:46:38 AM
#29
Perhaps you don't know how to use terminology correctly. CPU hogging or infinite loop is not a "crash" and both can be written in any language.

You really are an idiot aren't you.

Supposedly if one engages in discussion with you then one needs to first check "your personal dictionary" about what words to use.

You wouldn't get a "crash" according to your definition with a GC issue either.

Cheesy

Why don't you just stop trying to be a smart-arse?

(no-one admires you for it)
sr. member
Activity: 336
Merit: 265
June 17, 2016, 09:44:19 AM
#28
Since you've entirely derailed this thread with your ego, I will remind you that your browser crashing is most often due to memory leaks and the fact that GC does not prevent semantic memory leaks.

My browser crashes are not due to memory leaks so your stupid smart-arse stuff is just proven to be wrong.

You've proven nothing. Do I see any proof? Most browser crashes that are attributable to JavaScript (since that was the point we were discussing) are due to memory leaks. Do some research.

I don't need to - as unlike you I know how to "debug" my .js.

Cheesy

(thought you said you were a "coder")

Perhaps you don't know how to use terminology correctly. CPU hogging or infinite loop is not a "crash" and both can be written in any language. A crash is when there is an exception and the program can't continue executing. Since JS is memory safe, the only way to accomplish that is to exhaust resources.

Now that you've been spanked by an expert, go cry to moma.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 09:40:13 AM
#27
Since you've entirely derailed this thread with your ego, I will remind you that your browser crashing is most often due to memory leaks and the fact that GC does not prevent semantic memory leaks.

My browser crashes are not due to memory leaks so your stupid smart-arse stuff is just proven to be wrong.

You've proven nothing. Do I see any proof? Most browser crashes that are attributable to JavaScript (since that was the point we were discussing) are due to memory leaks. Do some research.

I don't need to - as unlike you I know how to "debug" my .js.

Cheesy

(thought you said you were a "coder")
sr. member
Activity: 336
Merit: 265
June 17, 2016, 09:39:19 AM
#26
Since you've entirely derailed this thread with your ego, I will remind you that your browser crashing is most often due to memory leaks and the fact that GC does not prevent semantic memory leaks.

My browser crashes are not due to memory leaks so your stupid smart-arse stuff is just proven to be wrong.

You've proven nothing. Do I see any proof? Most browser crashes that are attributable to JavaScript (since that was the point we were discussing) are due to memory leaks. Do some research.

If you are pointing out that your browser crashes not due to JavaScript, then that is irrelevant to the entire conversation about ASM.js.

legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
June 17, 2016, 09:37:26 AM
#25
Since you've entirely derailed this thread with your ego, I will remind you that your browser crashing is most often due to memory leaks and the fact that GC does not prevent semantic memory leaks.

My browser crashes are not due to memory leaks so your stupid smart-arse stuff is just proven to be wrong.

(only an idiot would "assume" that GC is the cause of all browser crashes)

Cheesy

So in fact it is your stupid ego that has derailed this thread because you just can't resist trying to attack me.

Fuck off troll!
Pages:
Jump to: