IOTA Surges Past Ripple

IOTA has an awful site, and their github isn't impressive (in terms of commits/contributors/pulse). I don't bother with coins/tokens that have sites that resemble scammy ICO sites, and if there's a github I can look at - I prefer to see lots of activity/commits/a pulse.

Maybe IOTA is great. But I can't bring myself to look further into it because of the site + github

There is no arbitrary time length requirement for security. There are standard tests (like avalanche) all of which Curl-P passed. They passed all the standard security requirements before deploying the prototype, and had a backup plan of deploying keccak should a hint of any possible exploit arise.

Curl-P is based on a well-studied sponge construction, so it’s not an especially risky move to deploy it in their system after it passed all initial security requirements.

Curl-P also has the advantage of being extremely simple. This makes it easier to vet as the analysis can be done more thoroughly, as it’s not obscured through complex internal mechanisms.

It does require new tools to study (as it’s ternary) so there is bound to be some delay to extremely thorough production readiness. However, saying it is not close to being ready is false (unless we must put an arbitrary year requirement on it as you seem to be keen on).

> This happens very rarely

Not true. Orphaned blocks happen all the time. https://blockchain.info/orphaned-blocks

> You are only uncertain in bitcoin when there are two equal (hash wise) blocks.

Not true. Its possible to see the longest chain and not know about another chain that is of equal length. Nodes won't propagate chains that are of equal length to their current chain, so this is actually probably a somewhat common scenario. There has also been a number of orphaned blocks of length 2, 3, and 4. That means its totally possible (not likely, but not outside the realm of possibilities) for a node to be working on a chain and have never seen the correct previous block. https://bitcoin.stackexchange.com/questions/3343/what-is-the...

This is all exactly why many nodes don't accept transactions until there are 6 confirmations -- statistically, we shouldn't ever get to an orphan chain of length 6 even though its technically possible (outside of bugs).

FWIW, I'm not arguing that IOTA is any more or less secure than Bitcoin.

Clearly a JS Dev "===" :D

> The thing is, I've heard of lots of new hashes in the past couple years but only heard about curl when the vulnerability was found. I'm not saying I was on the lookout for new hashes but didn't find any, but how do you except people to check it out when no one really knows about it? Even decades of time is worthless when you have no one looking at it.

Cryptographers have been looking at it. Initially the team reached out directly to a number of cryptographers, and they have an internal team as well. As a side note, it seems like a weird argument that since you haven't heard of it, no one really knows about it (especially given that you aren't a cryptographer). Additionally, as I said above, it's now being vetted by CYBERCRYPT: https://cybercrypt.dk/company/

Also, the article you cited is incorrect in it's assessment that a vulnerability was found. They assumed the ability to generate collisions was a vulnerability instead of a design choice. The security of Iota's current signature scheme relies on one-wayness of the hash function, which was not broken by the MIT team. In addition, the collisions would not result in compromised funds as they state, since forging a signature would require malicious software be downloaded by a user.

> Sure, sponge construction, while new has been studied due to Keccak. But you should've used keccak, instead of creating a new one(As they're doing now)

Keccak is not lightweight and therefore not a viable end solution. The network works much better with Curl-P. I will agree that it probably would've been better to just use Keccak initially till their hash function was vetted by a group like CYBERCRYPT if only to avoid the backlash from implementing a custom function. Hindsight is 20/20 though, and I imagine they were probably just keen on testing the tangle (which is much more unknown tech) in a state closer to it's end implementation.

You know what, I'm not a cryptographer, so I'll quote what a real cryptographer - Bruce Schneier has to say about that. “In 2017, leaving your crypto algorithm vulnerable to differential cryptanalysis is a rookie mistake. It says that no one of any calibre analyzed their system, and that the odds that their fix makes the system secure is low,” What do you have to say to this?

This is not a valid argument. It is an appeal to authority. Besides, Bruce is commenting based on the original incorrect analysis by MIT.

> Arbitrary year requirement seems frivolous, because you don't see the cryptographers who work hard quietly till they have an attack ready. It is to give time for them. Take a look at previous competitions, where attacks surface many years after first publication.

This is true. But it is also true for all hash functions including current well vetted ones. Better mathematical models are produced all the time. This kind of researched coupled with AI will likely make a lot of current hash functions vulnerable. What is the fix then? Most likely in the short term it will be quickly swapping to alternative hash functions, which the Iota team did quite easily (since they were prepared for the scenario). This seems like much better prep for the future to me than assuming Keccak or another hash function is forever golden.