I've read in a few articles that the Curl-P hashing function was designed with known practical collisions, intended as a "copy protection" feature.

I'm still having trouble wrapping my head around this, though. How does this copy protection work, and how does it impede clones without impacting IOTA itself?

In their official statement, the IOTA team stated:

"With Coordinator IOTA's security depends on one-wayness of Curl-P, without Coordinator the security depends on collision resistance."

However, before the collision nonresistance of Curl-P was identified and published by DCI, these Curl-P properties were kept secret. For this reason, in the beginning everyone would interpret Curl-P as normal hash function with the properties of one-wayness and collision resistance.

Impact of hash collisions with coordinator

For understanding this, it's important to understand how the Coordinator works. The Coordinator each minute issues special milestones transactions. Full Nodes (according to the current IRI implementation) only interpret transactions as valid if they are (directly or indirectly) referenced by a milestone transaction. Given this scheme, a Coordinator that is aware of potential Curl-P collisions (which CfB states he was) can prevent colliding transactions by publishing milestones transactions in a way such that transactions with colliding hashes are never interpreted as valid.

An example for two transaction with a colliding hash:

  • Transaction 1 from account A to account B has hash X
  • Transaction 2 from account A to account C has hash X

If an attacker can create collisions with Curl-P, he can look for a real transaction (Transaction 1) and create a fake transaction (Transaction 2) resulting in the same hash X, however, with a different recipient.

Having a global view on the Tangle, the coordinator can prevent such a collision attack if he actively looks for transactions with colliding hashes (the first transaction is always the real one) and takes care that the second transaction with the colliding hash is not confirmed by milestones.

Impact of hash collisions without coordinator

As the IOTA source code (except the Coordinator) just treats Curl-P as hash function with the two properties one-wayness and collision resistance, it is simply assumed that transactions with a colliding hash cannot occur. Hence, the network would simply accept transactions with a colliding hash. For this reason, in order to keep IOTA safe when shutting down the Coordinator, the hash function would have to be changed to a hash function that really is collision resistance. According to CfB, it was planned like this, however due to the disclousure of Curl-P's collision nonresistance, this was now done earlier.

CfB's idea of copy protection

I focus on technical aspects here and do not want to judge the overall proceeding. CfB's states that his motivation was to avoid scam coins from just copying IOTA's source code. According to him, people with serious intentions and investment of time would have recognized the Curl-P properties (one-way yes, collision-free no). However, people that are just blindly copying the source code for releasing another coin in hope that it in the end will be better than IOTA independently of the technology and just based on some better marketing, would fail.

In the official statement, it is stated like this:

"And because the mechanism by which transactions are signed is so critical to the functioning of any DLT protocol, an unfamiliar Curl-P function would get extra scrutiny in particular. It is absolutely inconceivable that any legitimate OSS developer would have either failed to fully investigate the properties of the Curl-P function as it relates to digital signatures, or failed to simply replace it with an industry standard cryptographic function with which they are already very comfortable. In a fraudulent clone of the code, in contrast, the exact opposite is true. It is very likely that the code would not undergo any review at all."

  • The IRI is licensed under GNU General Public License v3.0. Why is a copy protection mechanism necessary when it is open sourced? – Austin Powers Aug 9 at 4:30
  • @AustinPowers It's answered in section "CfB's idea of copy protection". What's missing? – Zauz Aug 9 at 12:38
  • @Zauz "just blindly copying the source code for releasing another coin in hope that it in the end will be better than IOTA independently of the technology and just based on some better marketing, would fail" Why is that an acceptable objective? It is open source. So you already gave permission to people to copy. So why booby-trap the code? Isn't that anathema to the Open Source licence objectives and the very ethos of Open Source projects and licensing? – Austin Powers Aug 9 at 13:54
  • @Zauz I'm afraid, you haven't answered the question "Why is a copy protection mechanism necessary when it is open sourced? This is not the same question as "Why is a copy protection mechanism necessary?". – Austin Powers Aug 9 at 13:55
  • Company A invests 90$ in development and 10$ in marketing, Company B invests 10$ in development (= copying and refactoring stolen code from Company A) and 90$ in marketing. Company B is more successful. Developers (CFB in particular, I think) didn't want this to happen to Iota. – Zauz Aug 9 at 14:59

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.