Live data from Hacker News

IOTA: A tangled mess

codesuppository.blogspot.com

51–60 of 253 posts

Re: IOTA: A tangled mess

#51
post #30

The new UCL wallet is even worse. It’s supposed to be launched within the next few weeks. It made me lose $2000 worth of iota because of a loop in the code that resent transactions if you put the app in a background state. You know, a violation of the one canonical rule of using iota, I.e reusing an address. The iota foundation is a nefarious and bad intentioned bunch of crooks.

You lost $2000 with the UCL wallet? How did you do that if the wallet hasn't even been launched yet?

Were you dumb enough to put $2000 into a beta wallet? Then I'd say you deserved it.

Re: IOTA: A tangled mess

#52

I can just totally agree with the author. I had more or less the same experience. IOTA is totally immature in terms of development, technology and PR (see fake partnerships and absence of public statement for the network status). Apart from this it just look like a nice and interesting white paper but that does not actually work in reality yet

I'm loving all you people's overblown emotional reactios to the "fake partnerships". Please keep selling your IOTA so I can buy them ever cheaper. I guarantee you'll be kicking yourself in 5 years time.

Re: IOTA: A tangled mess

#53
post #19

>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.

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.

Re: IOTA: A tangled mess

#54
> as if this was a JavaScript some 12 year old was writing for his homebrew website.

Who can tell the difference?

> Look, let's be very clear. IOTA is a live cryptocurrency with a market cap in the billions of dollars. Real people have large amounts of value tied up on that network. It is hosted on several exchanges.

This is a naive misconception, and one of the most dangerous aspects of cryptocurrencies right now - these are NOT FINANCIAL ENTITIES, there are no bank guarantees or fiduciary rules, no technical standards or oversight, no clear liability (especially when authors/network owners may just be virtual characters). There is 100% risk involved and nobody to blame but yourself.

Re: IOTA: A tangled mess

#55
post #19

Earlier quoted context omitted.

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 b…

Yet, the original author finds it fishy that IOTA is not implemented in C++.

Re: IOTA: A tangled mess

#56
post #10

As I understand it, the problem with IOTA is that — in order to execute an attack — attackers just need to verify more transactions than all honest participants combined. So, in other words, honest participants have no incentive to verify more transactions than required (because they don’t profit from it) while attackers have an incentive to verify more transactions, in order to successfully double spend.

And to deal with this problem, they have "trusted supernodes", with a promise to turn them off when the network is self sustaining. It introduces a high degree of centralisation - and we don't know the how network shapes up as a consequence. And the second problem is obviously the unaudited,"quantum resistant" function.

> And the second problem is obviously the unaudited,"quantum resistant" function.

Don't forget the ternary SHA-3.

Re: IOTA: A tangled mess

#57

>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.

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.

He may be biased, but you may be too. Are you a Java developer (or android)?

That said, I know some great software can be produced in Java, ElasticSearch been one on top of my mind.

If Security is the goal, nor CPP nor Java is great. Proven Haskell or Rust might be more of a valid option.

Re: IOTA: A tangled mess

#58
post #39

While I agree with the majority of the criticisms of this post (I also posted a criticism here[1]), one has to recognise that it's perfectly possible that a cryptocurrency requires no-address-reuse. This may not be a bug but a limitation which is a consequence of its design. I know other cryptocurrency that suffers this problem: Mimblewimble. But I sincerely hope the wallet developers of mimblewimble are smarter enou…

Mimblewimble doesn't have addresses [1]

[1] https://github.com/ignopeverell/grin/blob/master/doc/grin4bi...

Re: IOTA: A tangled mess

#59
post #55

Earlier quoted context omitted.

> 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 b…

Yet, the original author finds it fishy that IOTA is not implemented in C++.

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.

Re: IOTA: A tangled mess

#60

>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.

Ethereum has a Go implementation. The Java argument is BS obivously. The protocol needs to be valid, not a single implementation.
Post reply on HN