Live data from Hacker News

Lisk: Blockchain development in JavaScript

blog.lisk.io

11–20 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#12
post #5
post #4

File under: terrible ideas made possible by buzzwords.

Would you please stop posting unsubstantive comments to HN?

I see what I'd consider "unsubstantive" comments left alone on HN in pretty much every thread, so if you could, please define "unsubstantive".

Re: Lisk: Blockchain development in JavaScript

#13
> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its speed and security across a wide range of devices.

I don't mean to be rude, but that's the worst possible answer you could have given. Security should be your first priority, not an afterthought to popularity. That it isn't tells me everything I need to know about the seriousness of your project.

Re: Lisk: Blockchain development in JavaScript

#14
post #9

> Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place. Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and cr…

Not just that. One thing that worries me a lot about JS in this context is numbers: JS was designed to make it easy to use numbers and convert to/from strings without caring about the precision and exact internal representation. Which is perfectly fine for UI code and the like, but a terrible idea when you're transacting money.

Well, there are plenty of number libraries like BN.js that univocally convert from/to buffers and have unlimited precision. Numbers are the least of my worries with JS security code.

Re: Lisk: Blockchain development in JavaScript

#15
post #13

> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its s…

The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is that the Javascript is delivered to the user's browser from the server on every view. If someone makes a web app for doing end-to-end encrypted messages between users, it can't be secure from the web server operator: the server operator can update the javascript one day to leak users' private keys to the server. The server operator could even serve that malicious change to a subset of users so that it's even less likely to be noticed.

In systems where the Javascript isn't loaded on demand from a server on every use (like a server written in node.js, or an application built with electron), then that issue doesn't apply.

Re: Lisk: Blockchain development in JavaScript

#16
post #15
post #13

> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its s…

The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is that the Javascript is delivered to the user's browser from the server on every view. If someone makes a web app for doing end-to-end encrypted messages between users, it can't be secure from the web server operator: the server operator can update the javascript one day to leak users' private…

I guess your parent meant security problems due to bugs that could have been prevented using a language that has a stricter type system.

This does not mean you don't have to deal with security (your case still applies), but at least you get rid of some known bugs in advance.

Re: Lisk: Blockchain development in JavaScript

#17
post #12
post #5

Earlier quoted context omitted.

Would you please stop posting unsubstantive comments to HN?

I see what I'd consider "unsubstantive" comments left alone on HN in pretty much every thread, so if you could, please define "unsubstantive".

In this specific case you call Lisk a terrible idea without substantiating why, other than the fact that's its related to a nascent technology (buzzword as you say).

Re: Lisk: Blockchain development in JavaScript

#19
post #10

Earlier quoted context omitted.

There was a time when common internet protocols we take for granted today were a buzzword, too. Buzzwords are buzzwords until implementation is (or isn't) proven useful. Lisk is making an attempt. Let's judge the attempt and the fruits or lack thereof. Disclaimer: I am not an investor, stakeholder, or employee in Lisk.

I'm not calling blockchains a buzzword as a derogatory term towards blockchains. I'm more using the term to point out the way blockchains are being used right now (e.g. marketing bad ideas and non-ideas as groundbreaking tech). That's not to say there aren't plenty of promising projects out there. There absolutely are.

Which blockchain projects do you see as promising?

Re: Lisk: Blockchain development in JavaScript

#20

> Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place. Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and cr…

I'm one of probably the larger JS fans, and even love working with NodeJS (don't shoot me please) -- but I totally agree with you. I would certainly not trust myself, I really wouldn't trust somebody else trying the same.

I don't see a huge problem using some JS blockchain library for some non-critical application if it somehow added to the end product, but something so highly critical... no thanks.

Except for the part about Tezos. I haven't looked into it.

Post reply on HN