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