>The IOTA source code is written in JAVA instead of C++ like most professional cryptocurrencies are. That did not instill me with confidence.
This made me lose any confidence in a person's capabilities in evaluating the coin. If anything, Java is way more (or any language with modern memory management) robust choice than C++ where security is concerned.
In any case, I am highly skeptical of the IOTA as well.
Before I read the blog post, I thought that this was a nit-picky complaint, but it speaks to the entire structure of what's he's written. The lede is horribly buried, and the road to it is paved with mild but somewhat aggrieved snark. It has the virtue of being a chronological account, but his preliminary comments are not very informative and do not sound particularly well informed. (i.e., "…something called a directed acyclic graph." Indeed.)
This is unfortunate, because the factual reporting he can offer, located towards the bottom of the page, describes a situation wildly contrary to the claims made on IOTA's behalf, and is suggestive of a code base that is unready, fragile, and teetering (at best) on the edge of fraud.
Me too. He may well have valid points but, as someone who has written mission critical software systems in Java, this destroys the credibility of the article for me.
On top of that, all of his technical issues with IOTA turned out, by his own admission, to be using the network wrong. Not understanding that buying 1,000s worth of an obscure cryptocurrency is going to come with a heafty dose of RTFM is a fool's errand. Instead of realizing this, the denial in him turns this into "victim blaming."
that said - he's right about IOTA. If that type of use is what it takes to make everything work, it has a long way to go.
Using it wrong...would you not try using it exactly as described with $28,000 depending on it? He raised extremely valid points about labeling this 'user error' but the 'correct' use case seems pretty kludge to me and highlights the crypto's shortfalls.
I was just researching currencies with fastest transfer time and verified that Ripple works fast and with low fee. Curious if you've taken a look at it for your use case? I bought a small amount recently but am mostly just curious about which of these thousands of coins are actually useful for practical purposes.
Have you looked into any other DAG tech, besides IOTA? ByteBall and Raiblocks are excellent, functional and mature examples in my opinion that lack IOTA's downsides (likely because they are intended primarily for p2p payments, not IOTA's intended use case as m2m first, p2p second).
In full disclosure, I own a little bit of both. I first stumbled upon them after being disappointed with IOTA, and they deliver on a lot of what my initial expectations of IOTA were. I just want to be able to buy coffee with my crypto and not wait an hour for confirmation times!
Different tools have different advantages and Java is as suitable as many others. IOTA needs to prove that protocol is sound, so it doesn't matter if it's in Java, Rust, Go, Python... This point makes the author much less credible in my eyes.
That said, I steer clear of IOTA too. Relevant search terms for me are "IOTA roll your own crypto", "IOTA ternary logic" and "IOTA hash collision". And their whitepaper is indecipherable. Red flags all over the place, IMHO it's a scam.
What I don't get about Cardano is that it has almost NO use at all. The number of transactions per MINUTE can be counted using only your hands (every so often you may need to include your toes):
Cardano is a cryptocurrency written in Haskell with the goal of conforming to "high assurance" standards. Looks pretty promising, but like all 3rd gen cryptocurrencies, it is still early days (seems more functional than IOTA though.. no pun intended)
I wonder if something like OCaml would be a good choice. It's a safe language with good performance plus it gives you an easier route to formally verify the important parts of it. Cross platform is going to be trickier though.
Hmm, interesting. I wasn't sure if they were only name dropping that formal verification was possible but they say their developers have backgrounds in it. People mention about making Ethereum more secure using formal verification for example but it's not something you can just do as an afterthought.
I read your comment before reading the article. I expected the article to be a technical overview of IOTA.
Instead, it's a story of all the ways IOTA simply does not work.
Java vs C++ is irrelevant. Maybe the author is wrong, maybe not. Either way, it's probably a bad idea to take two sentences out of context and claim the author loses all credibility for an offhand opinion.
I don't agree with your "way more robust" argument per se, but I also didn't buy that point in the original article. It's unclear to me why the choice of programming language -- unless it was a very obscure and rarely used one, or one that's specifically used in one (unrelated) domain -- should be of any significance.
> It's unclear to me why the choice of programming language -- unless it was a very obscure and rarely used one, or one that's specifically used in one (unrelated) domain -- should be of any significance.
I'd rather use a language where e.g. a buffer overflow couldn't be turned into a remote exploit that would let you steal coins from every client on the network. Mistakes in cryptocurrency code has the potential to be very costly so you'd think minimising mistakes at all costs would be worth it.
Most likely it's that the majority of experienced crypto devs (aka people who have been around since it was "fork bitcoin and change PoW algo + logo") will be familiar with C++, so a Java implementation is an odd choice that strongly hints that it was written by a lowest-cost contractor - or at least someone unfamiliar with cryptos. Since there is an awful lot of trust in devs to provide future support/improvement, both are bad.
(Lot of "write my dumbass cryptocurrency" requests on Upwork, so I assume this is very common.)
As for technical superiority, maintaining consensus is critically important. If one set of users (miners) requires a high-performance implementation, it makes a lot of sense to use that implementation everywhere.
> Most likely it's that the majority of experienced crypto devs (aka people who have been around since it was "fork bitcoin and change PoW algo + logo") will be familiar with C++, so a Java implementation is an odd choice that strongly hints that it was written by a lowest-cost contractor
If you're an experienced developer writing a new cryptocurrency that's radically different from Bitcoin, why would you want to fork from Bitcoin and why would you find Java code harder to make safer than C++ code?
It's an explanation of why a Java client would be suspect as an "investor" - experienced dev teams don't release them. Most of these projects are primarily marketing ventures ("look, we're the next Ethereum!"), a lot of code is outsourced, and the average "investor" expects a handwavy explanation of how it's The Future with lots of big words that that they trust is correct. Making odd/different choices (DIY crypto, Java reference implementation) hurts that idea.
The article doesn't make much sense. It starts with the author saying the IOTA whitepaper was indecipherable, that the language choice was a bad idea, the code is undocumented etc. and then (ignoring massive red flags like the IOTA devs creating their own hash function) the author bought into and sold out of IOTA multiple times while experience major issues.
Personally I think C++ is a bad choice. A safer language that is easier to verify is preferable when small bugs have the potential to wipe out a cryptocurrency. Imagine Bitcoin got hit with a bug that allowed wallets to be emptied or took down the network such that a hard fork was required to fix it; it would wipe out confidence if this happened enough times. Maybe I'm missing something beyond the developers being very disciplined but I'm impressed this hasn't happened yet.
Single implementation is important for consensus systems. Look at e.g. the spurious dragon hardfork.
The problem with multiple implementations is that if there is a tiny difference in behavior between them, you can only find out after damage has been done to the network via a split/fork.
I think the idea is that the protocol is resilient to differences in implementation. A bad actor, could for all intents and purposes, manipulate the implementation to their advantage. An implementation, reference or not, is merely a convenience for users who do not want to write their own clients (which is essential for adoption).
In fact, last year an attacker launched a denial of service on the main Ethereum implementation, and the network barely hiccuped because people just switched over to one of the others.
When you do a transaction, you must "mine" two others. This is WebGL for some reason and puts my workstation with only an Intel graphics card to its knees.
Not saying this is the case but to me Java looks like the choice of someone who's fresh out of school. Nobody would start a new project in Java if he had the choice.
This made me lose any confidence in a person's capabilities in evaluating the coin. If anything, Java is way more (or any language with modern memory management) robust choice than C++ where security is concerned.
In any case, I am highly skeptical of the IOTA as well.