61–70 of 85 posts
Earlier quoted context omitted.
The security history of the JVM suggests that one shouldn't be optimistic there either.
counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)
Earlier quoted context omitted.
In Bitcoin, almost all the people use the same script, so it's enough to review it. (I think the only problem is a small malleability.) And when a big problem is discovered almost all the people will change in a short time. In Ethereum is more encourage to write smart weird custom contracts, so many people write a custom contract with only one pair of eyes to review it, so it's more probable to find errors.
For sure, but I think there's opportunity/vulnerability in bitcoin too. From the top of my mind I recall reading about people grabbing coins quickly from: bad random number generators in at least android, brainwallets/rainbow-tabley private keys, non-standard script for fun or error to the tune of having to solve "2+2" A little similar to how bad guys hook onto github feeds and instantly exploit leaked aws keys etc
Earlier quoted context omitted.
counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)
JavaScript doesn't run on the JVM.
Earlier quoted context omitted.
counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)
JavaScript has several mature, thoroughly scrutinized implementations. Ethereum has one brand new implementation. To put it mildly: There will be blood.
Earlier quoted context omitted.
counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)
JavaScript has several mature, thoroughly scrutinized implementations. Ethereum has one brand new implementation. To put it mildly: There will be blood.
Earlier quoted context omitted.
JavaScript doesn't run on the JVM.
thanks for saying this, sometimes I'm like "wow" on hackernews comments, because you kind of assume people know what they're talking about but then its like not really.
the JVM is a bit special because there are a large amount of escape hatches, native code and a complex trust model, which has caused a lot of the exploits you end up seeing.
Earlier quoted context omitted.
I had the same difficulty looking at the code. Do we count import lines and variable defs? Seems sort of lame. J of course has a different problem; only a handful of people can even parse it, much less opine on correctness.
Handful is a bit extreme ;) But seriously, it is easy to troubleshoot due to the interative nature of development in the REPL, the similiarity with mathematical formula and their layout. A PhD student wrote his thesis in 2008 about parallelization, FPGAs, ASICS and arrays, and was fully intending to write it in J, but his advisor suggested something more known, so he wrote it in Haskell. I'll put in the reference whe…
Earlier quoted context omitted.
The security history of the JVM suggests that one shouldn't be optimistic there either.
counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)