Official IOTA Foundation Response to the Digital Currency Initiative at the MIT Media Lab — Part 4 / 4
The IOTA Foundation no longer supports or endorses this article. We have however kept it available for transparency purposes.
Editor’s Note:
All of the information and links contained in this multi-part document were publicly available prior to publication. None of the information contained herein is new or revelatory.
This is a collective effort by many members of the IOTA Foundation and IOTA Core team. The purpose of this aggregation is to add color and context to these complicated and multi-faceted issues, so that the entire Distributed Ledger Technology (DLT) community can decide the relevance of this information for themselves.
In what follows, quotes from Joichi Ito’s criticism of IOTA are shown at the start of each section, followed by the response of The IOTA Foundation.
DCI’s claim:
“Orcutt’s claim that IOTA is free of fees is misleading. Though perhaps not immediately obvious, IOTA transactions are “zero fee” in exactly the same way that Bitcoin transactions are. An important difference is that Bitcoin has miners who can perform the proof of work for you, while IOTA users do the proof of work on their own devices, per transaction. However, a Bitcoin user can also mine their own block to get their transactions accepted into the blockchain without paying fees. To put it another way, most people wouldn’t be interested in buying a refrigerator operated by a hand crank, even if the advertisement said “No electricity required!”
It’s true that transactions with Bitcoin and other digital currencies, even when amortized over a block with thousands of other transactions, require much more work than transactions in IOTA. However, the claim is not that IOTA transactions are easier — the claim appears to be that IOTA transactions are free.
Semantics aside, this claim, which appears in IOTA marketing materials, is deceptive; the work required is a fee, whether or not it requires a monetary payment. Restricting the ways in which the fee can be paid — requiring that the work be done on a user’s own device — doesn’t make it go away.”
Semantics aside, this claim, which appears in IOTA marketing materials, is deceptive; the work required is a fee, whether or not it requires a monetary payment. Restricting the ways in which the fee can be paid — requiring that the work be done on a user’s own device — doesn’t make it go away.”
The explanation and analogy provided in the DCI post is fundamentally incorrect. We disagree with the definition of afee, as no third party receives payment specifically for an IOTA transaction. We also question the premise that “a Bitcoin user can also mine their own block to get their transactions accepted into the blockchain without paying fees” in any realistic manner.
In IOTA there are no miners or other network operators of any kind which need to be incentivized — therefore when Bob sends exactly 1 IOTA to Alice, Alice receives exactly 1 IOTA from Bob. We feel that because of the fact that the value sent is the value received, and also because of the triviality of the energy costs involved, it is not at all incorrect or misleading to say that IOTA transactions are as a matter of fact “fee-free.”
IOTA transactions do indeed incur some expenditure of energy required to do a computation, but the computations are small enough to be performed in a few seconds on a user’s own PC, mobile phone or another low-energy device. Contrast this with the mining farms that are synonymous with Bitcoin and Ethereum.
The DCI post states that “most people wouldn’t be interested in buying a refrigerator operated by a hand crank, even if the advertisement said ‘No electricity required!’”We feel that a better analogy might be that of opening the refrigerator door yourself, versus paying a “miner” to open it for you. Indeed, you expend some small amount of calories to open the door, but most people would not consider that a “fee” in any traditional sense.
The reason for this is clearly explained in the IOTA white paper. For IOTA, proof of work serves only as a preventative measure against network spam or sybil attacks, similar to HashCash.
Conversely for Bitcoin and other PoW-based coins, the proof of work acts as a fair, distributed and decentralized lottery deciding which miner can add the next block to the chain and rewarding this miner in newly minted coins. The cumulative hashing power from all the miners, secures the network against potential attacks. However, as Bitcoin’s price rises, this becomes a proof of work “arms race” as miners add more and more computational effort in order to win the increasingly lucrative Bitcoin rewards. Since there is a limited amount of space in each block and only one new block added to the chain approximately every ten minutes, the limited block real estate becomes more valuable as the number of transactions on the network grows. This is why a transaction fee market develops.
The claim that a Bitcoin user can simply, “mine their own block to get their transactions accepted into the blockchain without paying fees” is patently absurd. Today, bitcoin mining computations use over a billion US Dollars worth of energy per year by producing, at the time of this writing, roughly 15 million trillion hashes per second (that number is 15 followed by 18 zeros). For a user to simply “mine their own block” to avoid paying any fees, they would either need to assemble an enormous amount of computational power using an inordinate amount of energy, wait an extremely long time or be extremely lucky.
Using a standard PC computer, and holding the current hashrate constant, a user could expect to wait hundreds of thousands of years to successfully mine one of their own Bitcoin blocks.
The security model used in IOTA is fundamentally different, reliant instead on a complex Markov Chain Monte Carlo tip selection algorithm explained in the white paper, and further examined in a follow-up paper as well as technical simulations. In addition, there are other more nuanced factors not mentioned in the white paper such as network topology, bandwidth saturation in the IoT environment, and other unique features of the design — all of which are beyond the scope of this article. However, let’s entertain for a moment the notion that IOTA transactions are not free due to the anti-spam/sybil proof of work required. To pin a number on it, quoting from the white paper on page 26:
“[In] IOTA the number of nonces that one needs to check in order to find a suitable hash for issuing a transaction is not unreasonably large. On average, it is around 3⁸.”
“[In] IOTA the number of nonces that one needs to check in order to find a suitable hash for issuing a transaction is not unreasonably large. On average, it is around 3⁸.”
In practical terms, this means that IOTA transactions currently cost the amount of electricity required to operate an average home PC for about 20 seconds, or somewhere in the ballpark of $0.000001. This is due to the laws of thermodynamics, and not a “fee” in its definition as remuneration for services provided. In the future, as DLT becomes a standard, hardware will include ASICs in chips that can bring the time and cost down 1000-fold. IOTA has been explicit about this being a requirement for DLT to facilitate IoT since day 1, in fact it was the whole reason IOTA was initiated.
Bitcoin transactions, in contrast, cost over $30 at the time of writing. This fee is taken out of the transaction itself and paid to miners as an incentive to include the transaction in the next block. Moreover, the energy expenditure for a single Bitcoin transaction could power over 10 US households for 1 day.
DCI’s claim:
“Once the Digital Currency Initiative published the break in IOTA’s curl hash function, its author, Sergey Ivancheglo, offered two conflicting explanations for the vulnerability. The first explanation was that the flaw was intentional — that it was meant to serve as a form of “copy protection.” If anyone used this code in their own work, he said, the IOTA developers would be able to exploit the flaw and damage other systems that were using the hash function. However, later, he offered a conflicting explanation that he didn’t write the curl at all, but that an AI wrote it.
We do not find either of these explanations convincing, even in isolation. That they contradict each other makes them even less so.”
We do not find either of these explanations convincing, even in isolation. That they contradict each other makes them even less so.”
The original cryptographic vulnerability report was authored by (as presented on the report) Ethan Heilman (Boston University, Paragon Foundation, Commonwealth Crypto), Neha Narula (MIT Media Lab), Thaddeus Dryja (MIT Media Lab, Lightning Network Dev), and Madars Virza (MIT Media Lab, Zcash). There was an accompanyingblog postposted by Neha on Medium entitled, “Cryptographic Vulnerabilities in IOTA.” In the report, DCI revealed practicalcollisionsin the Curl-P hashing function. However, what their team failed to either understand, or deliberately did not disclose, even after being informed of this fact many times, is that the Curl-P function is not a cryptographic function nor was it intended to be. The Curl-P hashing function distributed in the open-source IOTA protocol intentionally included practical collisions where two different inputs result in the same hash outputs, which by cryptography standards would indeed be a very serious flaw.
For many months leading up to the publication of the report, Ethan and Neha were in direct contact with Sergey Ivancheglo (a.k.a., Come-from-beyond), IOTA co-founder, core developer and chief architect of the Curl-P function. These emails werereleasedwith the DCI side of the conversation redacted (we again invite Ethan and Neha to publicize the unredacted email exchange). As can be inferred from Sergey’s side of the exchange, he was allowed the opportunity to make corrections to the report prior to release. As is shown by the email below, Sergey requests that the function he designed be referred to as ‘Curl-P’, and requests that it not be referred to as ‘cryptographic’ because it was intentionally designed to allow practical collisions:
From: Sergey Ivancheglo, September 6th, 2017
“Curl” should be replaced with “Curl-P”. “Cryptographic” should be removed because Curl-P was designed to allow practical collisions.
“Curl” should be replaced with “Curl-P”. “Cryptographic” should be removed because Curl-P was designed to allow practical collisions.
DCI decided to ignore both of these corrections in the report they published, and of course the accompanying blog post published by Neha, was entitled, “Cryptographic Vulnerabilities in IOTA.” The report published by DCI does at least correctly note what the supposed attacks were not (emphasis added):
One can posit a stronger goal for the attacker: produce signatures on msg2, without seeing Alice’s signature on msg1. Our attacks do not achieve this much stronger goal.
…
As we said in Section 3, we did not test any of these attacks on the IOTA network. We therefore cannot predict what kind of role the IOTA coordinator would have in impacting this attack.
One can posit a stronger goal for the attacker: produce signatures on msg2, without seeing Alice’s signature on msg1. Our attacks do not achieve this much stronger goal.
…
As we said in Section 3, we did not test any of these attacks on the IOTA network. We therefore cannot predict what kind of role the IOTA coordinator would have in impacting this attack.
What this means is that, as we explained in our initial response, these attacks were both in fact extremely unrealistic to occur in practice. To be successful, an attacker would need to simultaneously:
- Find a user proficient enough in programming to sign bundles manually, but naive enough to sign a bundle created by somebody else;
- Know which addresses belonged to the user which, due to the way addresses are generated in IOTA, are unknowable unless the user shares them intentionally;
- Prevent the user from connecting to the network (eclipse attack), or connect to the network significantly faster than the user — both exceedingly difficult due to the mesh-net characteristics of the IOTA network.
But regardless of the feasibility of such an attack, we would like to take this opportunity to more thoroughly address the reasons behind the decision to introduce the Curl-P hashing function with practical collisions. We take full responsibility for the poor state of current documentation, and the fact that this explanation has (until now) been scattered rather haphazardly across various posts and platforms.
As the report correctly concedes, because the Coordinator is closed source, the DCI team could not predict what kind of role the IOTA Coordinator would have in impacting a collision attack. The answer is that the Coordinator was specifically designed, in addition to other purposes, to prevent precisely such an attack. Sergey explained his rationale for this design decision on Reddit here. The most relevant portion is copied below:
IOTA is open-source software. In the world controlled by the state, open-source software is protected with licenses, someone doing things not allowed by the license can be sued. Cryptocoin industry demonstrated to be very resistant to state regulations, this led to majority of the projects run in this industry to be oriented on scamming ordinary people. IOTA team welcomes attempts to use technology IOTA is based on. This helps IOTA because increases awareness and shows that Tangle is indeed a viable technology. Unfortunately, odds that copies of IOTA codebase will be used for good are very low. We can’t just watch an IOTA clone scamming people and ruining people’s lives and Tangle’s reputation. This is why a copy-protection mechanism [in the form of the Curl-P hashing function with practical collisions] was added from the very beginning.
To explain how the copy-protection works we should recall about existence of Coordinator. Coordinator acts as an ultimate oracle if any uncertainty about the current state of things in IOTA arise. Digital signatures are verified by every computer in IOTA network, if a signature passes the verification routine then it’s, PROBABLY, valid. To make sure that the signature is indeed valid the computer waits for the transaction containing the signature to be referenced by a milestone. This is a perfect place for placing the copy-protection mechanism. While everyone looks at signature verification routine the real verification happens in the routine updating milestones. This trick resembles a focus trick done by magicians on TV. It worked so perfectly, that Neha Narula’s team was fooled despite of me explaining the essence of the trick numerous times.
Now, when we know that all signatures must be endorsed by Coordinator before being accepted as valid, we can move to that part about Curl-P hashing function. Necessity to develop the function was justified. Trinary numeral system is getting off the ground now, today it’s mainly Artificial Neural Networks which already have specialized processing units in development. No doubt, that later we’ll see CPUs doing trinary computations. To avoid derailing my response I won’t be expanding this topic, IOTA blogposts contain all relevant information. Being the creator of Curl-P I knew its properties very well. I changed the number of rounds to allow practical collisions. With Coordinator IOTA’s security depends on one-wayness of Curl-P, without Coordinator the security depends on collision resistance. This is a very important part, it means that your phrase “the Iota development team deliberately introduced faults into the Iota codebase” is WRONG. IOTA is unaffected by collisions in Curl-P, scam-driven clones are.
Now, when we know that all signatures must be endorsed by Coordinator before being accepted as valid, we can move to that part about Curl-P hashing function. Necessity to develop the function was justified. Trinary numeral system is getting off the ground now, today it’s mainly Artificial Neural Networks which already have specialized processing units in development. No doubt, that later we’ll see CPUs doing trinary computations. To avoid derailing my response I won’t be expanding this topic, IOTA blogposts contain all relevant information. Being the creator of Curl-P I knew its properties very well. I changed the number of rounds to allow practical collisions. With Coordinator IOTA’s security depends on one-wayness of Curl-P, without Coordinator the security depends on collision resistance. This is a very important part, it means that your phrase “the Iota development team deliberately introduced faults into the Iota codebase” is WRONG. IOTA is unaffected by collisions in Curl-P, scam-driven clones are.
In summary, Curl-P was indeed deployed in the open-source IOTA protocol code as a copy-protection mechanism to prevent bad actors cloning the protocol and using it for nefarious purposes. Once the practical collisions were uncovered, its purpose as a copy-protection mechanism was of course rendered obsolete (it only works for as long as it remains unknown) and IOTA reverted to the industry standard KECCAK-384 cryptographic function. It is not clear why DCI finds this explanation unconvincing. It is even less clear why DCI finds the two explanations Sergey provided on the genesis of Curl-P to be contradictory. Curl-P was in fact created through a particular AI technique called an ‘Evolutionary Algorithm’, and its purpose was to allow practical collisions as a copy-protection mechanism. We do not understand what is contradictory about these two statements or why neither is convincing, even in isolation.
Putting aside technical debates about cryptography, hashing functions, AI, and practical collisions, there is a much more important question here. Interestingly, Ethan, in a presentation he gave on their report which can be seen here, touched on this more important question in his conclusion. In it, he asks the following:
- Did we discover a copy-protection backdoor in IOTA?
- Is it ethical to design backdoors/vulnerabilities in a free and open source code as a copy protection mechanism? IOTA is GPL’d
The answer to the first question is of course, yes, as we have explained above. The latter of these two questions, by contrast, is indeed an important one to ask and is much more complicated to answer. One might pose that if Ethan appreciated the importance of this question, it is curious why it was never mentioned in the sensationally headlined blog post: “Cryptographic Vulnerabilities in IOTA”. Regardless of his intent, however, the discussion around the ethics of open-source software in the DLT context is an extremely important one for the community to have.
As Sergey mentions in his post on reddit, the open-source GNU Public License (GPL) does not mean that code can be copied and used for any purpose or in any way. Those using code for purposes outside of the GNU Public License can be held liable in court. However, in the DLT arena, where code is decentralized and distributed by potentially impossible to identify, anonymous online actors, these legal protections are mostly ineffective. So how, under these circumstances, can honest open-source software contributors ensure that their work is not re-purposed to nefarious aims?
Sergey, before co-founding IOTA, was the Founder of Nxt under the pseudonymous online identity BCNext, and had experienced exactly the type of scenario mentioned above. Nxt was the world’s first full Proof-of-Stake DLT protocol and integrated asset exchange. During this time, various scams using Nxt’s open-source software defrauded countless innocent people. Sergey and the other IOTA co-founders were determined to not let this happen again with IOTA.
The IOTA team made a design decision early on to prevent this possibility by purposefully introducing the Curl-P hashing function with known practical collisions. This had the express purpose of rendering fraudulent clones of the protocol useless in their application as a DLT protocol, while at the same time guaranteeing the security of the IOTA protocol and network as a whole. Any legitimate open-source software (OSS) developer who would consider using the IOTA code in a business critical application would undoubtedly review and test the code extensively prior to deploying it to production. 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 Curl-P hashing function was in fact a very cleverly designed mechanism to allow legitimate OSS developers, and consequently the world, to benefit from the IOTA code while protecting it against misuse (at least until the practical collisions were revealed by DCI’s report). This can be thought of like as mart gun— it only works in the hands of an authorized user. Unlike a smart gun though, for the safety mechanism to be effective it is important that it is not publicly announced or made readily apparent.
We would ask if Neha, Ethan and their team are unhappy with the number of frauds and scams being perpetrated in this space. Given the absence of viable remedies to regulate these digital assets, and given that there is no clear way to reliably identify the people behind these crimes, what can honest contributors in the space do to protect innocent people from being defrauded by malicious software? We believe that honest contributors should take special precautions when possible, and this necessarily sometimes means that complete transparency and measures to protect innocent people are at odds with one another. Scientists also face this dilemma between transparency and secrecy (for example, related to the discovery of a dangerous new chemical compound). The IOTA team values transparency and the ideals of the open-source software movement tremendously, but we also do not want to see innocent people hurt as a result of our work. These are difficult questions with no easy answers, but in the end we know it is the integrity, sincerity and character of our actions which matter most, not how they may be perceived by others.
It is a shame that rather than discussing these very real and very serious issues facing the DLT community with Neha, Ethan and their colleagues, the IOTA team had to work overtime to calm the fear, uncertainty and doubt in the IOTA community generated by their sensationalist blog post about a “vulnerability” and a number of other non-issues that had no impact on the security of the IOTA protocol, user funds, or the Tangle whatsoever. If and when the DCI team release their vulnerability code, we would be happy to formally review its impact.
Hopefully, now that we have clearly laid out the reasons behind our decision, the entire DLT community can instead have the much more important discussion surrounding ethics and open-source software, and the potential for DLTs to be used for both noble and nefarious purposes. We welcome and look forward to this discussion.
In the fast-paced and competitive Distributed Ledger Technology space, the IOTA Foundation has been working around the clock to build out the IOTA protocol and to help position IOTA as the backbone of the future Internet of Things industry.
We regret the confusion in the media related to the IOTA Data Marketplace and will take care to ensure such an incident does not transpire again in the future. Additionally, with this and prior documents referenced throughout, we feel that we have now adequately responded to concerns raised by DCI: what actually constitutes a “feeless” transaction, the intentional design decisions behind the Curl-P hashing function, the IOTA network’s reliability, and the user experience difficulties resulting from the mathematics behind IOTA’s key reuse issue. IOTA is a novel and complex protocol and all of these issues are growing pains which should be expected of a nascent technology still in beta phase. The IOTA Foundation continues to work towards improved security, protecting IOTA token holders, maintaining accurate and honest communications with our community, and fulfilling our overall organizational mission.
At the same time, we are deeply concerned by what appears to be a concerted effort to initiate controversy about the IOTA protocol and damage the reputation of the IOTA Foundation. Rather than engaging in thoughtful and respectful debate or collaborating together to improve upon the work IOTA has already laid out, the team at DCI has instead chosen to write articles with sensationalist headlines and misleading content which has sown confusion and created further division in the DLT space.
With this new year marking the ten year anniversary of the original Bitcoin white paper, our wish for 2018 is that this year can mark a turning point for the entire DLT space to mature into a collaborative, innovative and pioneering technology industry. For our part, we are committed to improving both IOTA as a technology and ourselves as people, and to doing everything in our power to bring to light our shared vision for a distributed and decentralized future.
Sincerely,
The IOTA Foundation
P.S. We thank you for taking the time to read all the way to the end of this lengthy multi-part post. Aside from the comment section below, we invite you to keep the discussion going on our StackExchange, Forum, Slack, and Subreddit. IOTA developers, researchers, and community members of all stripes frequent these various platforms and are happy to answer any questions you may have, respond to any concerns, or simply engage in a thoughtful discussion about the issues which were raised here. We look forward to hearing from you.
This is a multi-part post. Links to the other parts can be found below:
Part 1
Part 2
Part 3
Part 4 (this article)