IOTA: What the DCI emails reveal

20 min readFeb 26, 2018

IOTA has received a lot of bad press so far because of the DCI allegations — if you are not familiar with this topic, you may read the summary here (see point 1).

With Tangleblog’s disclosure of their email correspondence between IOTA devs and the DCI team we have a source now to get a closer look at what really happened (and what not). I want to point out here that Tangleblog is not part of the IOTA Foundation but just a community member; the same is true for me.

The IOTA Foundation did not make these emails public:

Edit: Here is the official answer by the IOTA Foundation regarding the leak.

However, now that there is a lot of wrong information spread in the internet, I decided to show to the interested readers, what these emails are about.

Since I am writing for the non-techies (who will understand the content without further elaboration), I will provide an overview in an ELI5 (= Explain me like I’m 5 years old) version. For the sake of readability I have shortened my original article.

The people involved

There were basically two main correspondences:

Ethan Heilman, who allegedly found the weaknesses and led the conversation on the DCI side // Come from Beyond (CfB) on the IOTA dev side (CfB is addressed in the emails by his real name Sergey)
Neha Nerula, who jumped in after Ethan did not write anymore // David Sonstebo, Co-founder of IOTA.

The issue

The DCI team apparently had found a way to make use of alleged security flaws in the IOTA’s cryptography. This itself is not a problem, to the contrary: The IOTA devs wanted to know where the problem came from in order to fix it (which is what peer reviewing is all about, of course).

The problem arises if you look at the way things were carried out:

The dialogue

I shall address the respective letters/emails by refering to their #number in the tangleblog’s pdf-file.

15th of July — 20th of July: random stuff

Ethan’s claim: The DCI found 3 attack vectors which render IOTA’s code insecure
advice to not “roll your own crypto”
suggestion to talk via slack instead of emails => denied by DCI team (#9, after that no mention anymore)

22nd of July (#11): The core of Ethan’s findings

We can now create collisions of messages of the same size (examples follow at the end of this email). This appears to break the standard definition of security for signature schemes called EU-CMA (Existential Unforgeability under a Chosen Message Attack) [0]. Can you confirm that IOTA’s signature scheme is indeed not EU-CMA secure?

What follows is a very brief theoretical overview of how it was done plus some sample collisions anteceded by this:

23rd of July —25th of July: Back and forth

CfB answered in #13:

Yesterday David promised to provide a thorough response. Unfortunately, I still haven’t got an answer to my question from the very first letter, without that the leap of faith is required to follow your recommendations. The question was:
How many transform() function invocations do you need to “break 24 of 27 rounds of curl”?

CfB went on to explain the backgrounds after Ethan’s mail #14. In #15, he told Ethan about the shortcomings of his argumentation — bear in mind, this is a normal process and what was not meant (and also not perceived) in a offensive way whatsoever!

So far you have broken them for Curl-P-1, Curl-P-2, …, Curl-P-26, Curl-P-27 functions, I’d like to know your assessment on the min number of rounds which makes your attack infeasible. […] Not entirely sure what you mean, maybe you omitted “cryptographic” in front of “hash function”? In this case you are right, second-preimage resistance is an anti-feature, collision resistance threat is nullified by Coordinator while allows us to easily attack scam-driven copycats.[…] Your attack is based on a wrong assumption about IOTA signing scheme. As you know, some signing schemes counteract your scenario by higher level protocols (e.g. RSA),IOTA follows the same route. Let’s apply your findings on the actual scheme, do you have time for that? If yes, then IOTA team will prioritize the documentation.

Already here it becomes obvious that fundamental flaws found their way into the works of Ethan. However, this is NOT a problem: You could easily find solutions and this is what both parties were striving for for over the following emails.

At the same time CfB stressed that the IOTA devs were very happy about the feedback and were working together with professionals to be on the safe side:

Your recommendation makes perfect sense, but before that we need to get a 3rd-party confirmation, this will take some time. I also want to highlight here that we are working with multiple security researchers, cryptographers, mathematicians, students and universities with supercomputers (Imperial College London and St. Petersburg Polytechnic University) to verify our assumptions both in IOTA consensus as well as Curl cryptography. […] I want to reassure you that we very much appreciate your input and that we take it seriously, this is why we reached out to you in the first place 3 months ago as well. We are already checking this now with two 3rd parties, including our own inhouse cryptographers and mathematicians. We appreciate your understanding that this will take some time, but your response to this mail will be very helpful in gauging the exact issue and provide ETA, then we can coordinate on the next steps (implementation change, publication etc.)

Very professional, purpose-driven behavior. In #17, CfB met Ethan’s demands for the further organisation of work.

25th of July: The Higher Level Protocol

As requested by Neha in#18, CfB replied in #19 about the protocol which ensures that the alleged weaknesses found in the code are not serious because they are tackled by a higher level protocol: All of the respective links were provided:

https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/TransactionValidator.java#L72
Here the collision would invalidate a transaction if it adjusted “timestamp” to an invalid value. https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/TransactionValidator.java#L77
Here the collision would invalidate a transaction if it adjusted “value” to an invalid value.
https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/BundleValidator.java#L35
Here the collision would invalidate a bundle if it broke “currentIndex” sequence or “lastIndex” didn’t match the real number of the transactions in the bundle. https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/BundleValidator.java#L43
Here the collision would invalidate the bundle if it changed the transferred value.
https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/BundleValidator.java#L73
Here the collision would invalidate the bundle if it changed “address” field of a multi-sig address (there are no single-sig addresses in official wallet, all addresses are 2-of-2 ones, but custom software might generate single-sig addresses). https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/BundleValidator.java#L79
Here the collision would invalidate the bundle if it changed the spending address.

In the next emails, the conversation went on about the publication of DCI’s findings (agreed on the 12th of August, #22) and about IOTA’s address generation.

30th of July: The second preimage resistance issue

In #24, CfB explained to Ethan his concerns about his argument regarding the second preimage model (hashing a second message to the same value as the first and thus breaking security):

In IOTA an attacker doesn’t choose the signed message, the chance to guess it correctly is negligible. […] All the above makes me wonder if we can use any excuse for the transition other than necessity to use a well-studied and vetted cryptographic primitive.

Ethan went on to give a link to three formal definitions of what such a preimage attack is. In #26 CfB asked which of these definitions DCI used (and by which of these IOTA’s resistance was broken. He also pointed out:

Ethan: We presented an EU-CMA (Existential Unforgability - Chosen Message Attack) which is viewed as a basic security requirement of a signature scheme
CfB: I’m pretty sure it’s only for a spherical signature scheme in vacuum. Quick googling returns https://en.wikipedia.org/wiki/Digital_signature_forgery#Existential_forgery_.28exi stential_unforgeability.2C_EUF.29 where we can see that “Nevertheless, many state-of- art signature algorithms allow existential forgery.” Unless you claim that those words are wrong, I think we are in agreement that your phrase should be read as “which is viewed as a basic security requirement of SOME signature schemes”.

31st of July — 5th of August: Approaching the climax

Then 20 bulletpoints follow which were taken from the DCI’s findings which Ethan was to judge if they were still actual. Moreover, CfB highlighted on of the main problems in the whole discussion (keep in mind that IOTA came up with groundbreaking novelties in the crypto sphere):

I have a feeling that you refuse to accept existence of cryptographic protocols not mentioned in the textbooks read by you. I can imagine an EU-CMA insecure scheme which is broken only after second-preimage is broken.

The problem was, that DCI didn’t write back over the next days which led David to tell them (#31):

We are already teamed up with world leading sponge construction hash function experts who are awaiting Ethan's discovery, but for almost a week now there has been no communication...

The same day (5th of August) Ethan replied briefly but didn’t go through all of the 20 bulletpoints. CfB’s answer (#33) concludes (I left out the rest because it will be summarized below):

You haven’t supplied us with the details we requested so therefore they are very confused as well because your finding was a single internal collision while you were mistakenly claiming that it broke second-preimage resistance of Curl-P-27. Your summary of the findings shows that you finally saw that too. We hesitate to inform them about your claim of breaking EU-CMA security of IOTA signatures because we haven’t seen your proof yet and are pretty sure that you are wrong again. Could we see the draft of the paper you are planning to publish?

This is important to recognize here: Ethan has never provided detail of how his collision broke the second-preimage resistance. This is also why David wrote (#31):

We are still awaiting a full response to this mail before we can go public. As you know we already prepared a migration due to upgrading to Curl 2 for months, but your claimed attack accelerated our priorities, but your sudden reluctance/absence in verifying the claims make us a bit weary. We have prepared everything and are currently writing up our update/migration blog post/newsletter to the community, but beyond what we have already communicated for months we were expecting a thorough breakdown of Curl, which has not happened yet…

Because Ethan did not go into detail about their statements about IOTA and if they were still actual, CfB sent him his own list. Since these points are rather important, I will paste them here (#35, S= DCI’s statement, below is CfB’s answer):

S01: We have found serious cryptographic weaknesses in the cryptographic hash function curl used by IOTA, curl.
Only a single internal collision was demonstrated for a weakened version of Curl-P. It was expectable, especially after a collision on a Keccak equivalent was found (http://keccak.noekeon.org/crunchy_mails/coll-r6-w1600-20170226.txt).
S02: These weaknesses threaten the security of signatures and PoW in IOTA as PoW and Signatures rely on curl to be pseudo-random and collision resistant.
Awaiting a proof.
S03: This allows the creation of an unlimited number of collisions and second- preimages.
Incorrect usage of Curl.
S04: Since the state is the same regardless of the number of prefixed zero input blocks we can create more complex collisions and second-preimages.
Incorrect usage of Curl.
S05: As message padding is not used in curl, we can construct messages of different lengths that result in the same sponge state.
Incorrect usage of Curl.
S06: We have also found another form of non-randomness. Namely two similar messages result in states that are different only by a positional shift.
Incorrect usage of Curl.
S07: Note also the substring 99999 should a occur very infrequently, but we can anecdotally observed values of the initial state bleed into the final hash message.
The same can be observed for SHA-256: SHA256(*999999*2d224a9a45e7c8eb185971e53574024801252322d93550f4f5987addf8) = 567be78f9537b18990e32b6164fe06*999999*19b50c7a23556cc6aeb85dbe4778SHA256(*999999*16e09f623d0cc86cf5eba24e9e1d14f86f12a6a1ea46a4fc984b46c85d ) =699ec27b2b9e4a800841bccd6a4bdd*999999*2a03cceefa6b014dc3d2edd35f60SHA256(*999999*74d828d6d9d420acd5f1fcf44bff94b45cb6a3fe539fb20e245cbcdcea)=6b16590e1583885741dbd77bb4d3dd*999999*33d03cb2c20d13ac7cf134e9da76
S08: Furthermore we have observed clear difference patterns in the hash output when each third trit is different between two messages.
An example wasn’t provided.
S09: This paper [https://eprint.iacr.org/2011/191.pdf] reduces the Winternitz one-time signature scheme to the PRF property of a function not onewayness.
The abstract states: “We show that the Winternitz one-time signature scheme is existentially unforgeable under adaptive chosen message attacks when instantiated with a family of pseudo random functions. Compared to previous results, which require a collision resistant hash function, our result provides significantly smaller signatures at the same security level.” Which shows that we can reduce WOTS to different properties. One can reduce WOTS to one-wayness by using the technique from https://pdfs.semanticscholar.org/aaf3/602cdcd40276d2239f22f2eeaf5c2d45446f.pdf.
S10: [W]e will be able to create collisions with high probability for random states by ensuring that all differences that exist only occur with state[0:243] at the end of a transform. It should work for any number of transform invocations greater than 1.
Awaiting for an example of such collision.
S11: Curl’s collision and second preimage resistance are broken when used as a hash function.
A single internal collision for a weakened version was demonstrated. No second- preimage attack was demonstrated.
S12: IOTA isn’t using curl as a hash function but instead using it as a function which maps fixed length tryte strings to fixed length tryte strings.
According to Wikipedia “A hash function is any function that can be used to map data of arbitrary size to data of fixed size”. Unclear if the difference between “arbitrary size” and “fixed length” is really significant. Confused what this statement could mean.
S13: Even when used in this setting Curl is not pseudo-random.
Awaiting a proof with correct usages of Curl.
S14: It is unclear if this breaks the signature scheme used by IOTA because the signature scheme used by IOTA is not well documented and does not have security arguments.
Some information was provided, no requests for more information were received.
S15: As far as I can tell most hash-based WOTS schemes can be reduced to the PRF property of the hash function.
See S09.
S16: We can’t attack the signature scheme until we understand it, and understanding a signature scheme from source code alone is a time intensive process.
An attack was provided later which implies that the signature scheme had been understood. Should, probably, be grouped together with S14.
S17. This appears to break the standard definition of security for signature schemes called EU-CMA (Existential Unforgeability under a Chosen Message Attack) [http://www.cs.tau.ac.il/~canetti/f08-materials/scribe8.pdf].
Awaiting for a proof.
S18: We note these collisions result from the exceptionally poor performance of curl’s transform function when attacked by textbook differential cryptanalysis attack.
This is a design choice because making attacks simple allows to pick the min number of rounds for a required security level without worrying that the attacks will become more complex in the future (the evolution of slide attacks is a good example of how this happens).
S19: We base this on the following description of the signature scheme used in IOTA.
The described attack can’t be applied to IOTA because it doesn’t take into account higher level protocols.
S20: We used the lyrics to the 80’s hit single “push it to the limit” in the colliding messages to demonstrate that we fully collide the internal state of curl and thus have arbitrary control over most of the message. We note that this internal state collision enables us to instantly create millions of other colliding messages.
These “millions of other colliding messages” cover less than 3^(-333) part of all possible messages hence they can appear with negligible probability even if we generate transactions with 1 billion TPS during 1 billion years.
S21: Can you explain your signature scheme then? When generating a signature do you or do you not hash the message? We have looked in multiple implementations and it appears that you do. If you do then our attack holds and your signing scheme EU- CMA forgery depends on the collision resistance of curl.
It also depends on higher level protocols, as I have already described in previous correspondence and will elaborate on in the next points.
S22: These attacks we have developed will always get better. The current results are from roughly 20 hours of work.
Satoshi’s invention led to a paradigm shift in a lot of areas. Unfortunately, some cryptographers still didn’t fully embrace that and keep sticking to obsolete security assumptions. In our very case it means that window for an attack is very small (maximum — until a transaction is confirmed).
S23: For a non-negligible subset of the range, we can find second-preimages.
You use an unorthodox definition of “non-negligible” because odds to select a message which can be second-preimage attacked are below 1 of 8718964248596095820291107058586077169696407240473175008552521943799096 7093723439943475549906831683116791055225665627 for a single attempt. (Here I assume that you are planning to use a method based on an internal collision.)
S24: If this breaks second-preimage resistance of curl depends on how that is defined and is completely unimportant for our attack.
All the provided definitions show that second-preimage resistance of Curl hasn’t been broken. Awaiting for more definitions to check.
S25: The EU-CMA security of your signature scheme depends on the collision resistance of curl.
Awaiting the description of a reduction of higher level protocols to collision resistance of Curl.
S26: In any event our attack on the EU-CMA security does not depend on having second preimage attacks.
Awaiting the description of the attack.

To put it short: Ethan had not provided any details so far about his attacks, although he was asked to do so (why would the IOTA devs otherwise insist on this, of course?!). He also ignored the existence of IOTA’s higher level protocols and that’s why CfB sent him the same mail as Neha (see above). To be on the safe side what the IOTA devs really wanted from Ethan (although it had already been asked numerous times), CfB wrote again in the same mail (#35):

We’d like to see how you avoid generation of collisions which wouldn’t pass the verifications above. Also we’d like to know if the collisions can be generated in real-time to win the propagation race against legitimate transactions.

5th of August: Climax

David sent an email asking for more information on the DCI-cryptographers (#37) :

We asked you a week or so ago to disclose who these other cryptographers you had discussed this with was, you never replied to that, but now that you are offering to do so for a second opinion, I would absolutely welcome that.
(Ethan had written before that: As you don't seem to believe me on such issues I would ask that you reach out to a cryptographer, if one isn't available I would be willing to put you in touch with one to give you a second opinion. #36)

Ethan’s response to CfB was really short, he did not address any of the above-mentioned issues (#36). His only claims were directly tackled by CfB (#37):

Ethan: EU-CMA security does not require that the messages pass validation checks outside of the signature scheme.
CfB: You mean “...outside of a spherical signature scheme in vacuum”, don’t you? In our letters we are discussing a concrete signature scheme used in IOTA.

Which is obvious, of course.

The thing is: no email from Ethan can be found from here! He simply didn’t reply anymore and left the questions from CfB unanswered!

What happened? Well, round 2: Neha stepped in.

5th of August — 6th of August: Prelude

Maybe Ethan quit because he was angry about CfB’s sentence (#38):

Ethan: This is not intended as an insult but the list of questions asked here show a lack of understanding of the basics of how cryptographic primitives and schemes are assessed.
CfB: I can explain why these questions were asked, just need the absolution from you (in case if you are offended by my words, lack of English vocabulary makes me sound pretty blunt). Could I have it?

CfB addressed everything in detail whereas Ethan could not come up with any proof for what he apparently had found out.

However, to Neha (who kept on communitcating with him) CfB made clear that this was not about insulting, to the contrary (#40):

From our side this is only about facts and making sure we understand each other properly. By “absolution” I am simply attempting to ensure that we indeed stick to the civil discourse, like I mentioned English is my third language, and I was getting worried that my blunt wording might come off as offensive. I believe this entire chain of letters make it evident that we are focused on a civil professional relation. PS: I even unsure that putting “Hi, <name>” everywhere is suitable, I wish I took normal English classes instead of learning it by reading Java documentation )

Most of the following emails were written between David and Neha.

7th of August : David and Neha

David let Neha know about the new timeline (#42):

1) Tonight we will be announcing a new snapshot with the transition from Curl to Keccak
2) Tomorrow (8th of August) we will be doing a snapshot, requesting everyone to move their iotas. The wallets and the core clients are already ready and have been tested by the team & people from the community in the last week.
3) August 16th we will be doing a second snapshot as a security precaution.
In order to ensure that everyone involved comes out of this in a positive manner, we would like to review Ethan’s paper before the official publication.

At the same time David made clear that they wanted to protect Ethan’s renome from being harmed due to “incorrect information resulting from sheer misunderstandings”. However, because he had not provided anything so far, the devs couldn’t help him with that and so the hope lay on Neha.

Then some emails followed about how the fix (switching to Keccack for Curl) would be explained to the community and when. The blog post was put online on the 7th of August: click

8th of August — 12th of August: Neha’s questions

In letter #53 Neha pointed out that she had found two bundles which differ in one trit and which hash to the same value and, thus, the same signature: This would have been a serious security breach.

Cfb answered her by explaining the background (which I will skip for reasons of time and space) (#54):

The bundles fail in Java version because they don’t form the correct chain of the transactions. […] Some other issue we noticed: Only one of the bundles can be confirmed (because they share some transactions) but redoing PoW would allow to confirm the both if there was enough money on the spending address balance. In any case the original variant doesn’t allow to trigger a network consensus divergence because of Coordinator.

Over the next emails, Neha confused the bundles (both transactions were identical; #57, #59, #61, #63). Even though this is, of course, rather annoying, CfB replied to all of her mails and explained her what went wrong.

12th of August: CfB asks…

#67 then was CfB’s attempt to provide a lengthy explanation of the so far demostrated collisions (which were not those which the devs had been waiting for so long, of course):

Precisely speaking, the odds of second-preimage collisions are shown to be below one of a million.[…] The physical meaning of our analysis results is the following:
In a long run we need to process 1 million bundles (or more than 4 million transactions) to be able to conduct the attack successfully.

One day later, he wrote to Ethan (although the latter hadn’t responded in any way to his questions) and provided some explanation why Ethan was wrong with his estimation of IOTA’s EU-CMA security (the issue explained above plus the fact that there are people who cannot imagine that new technology might be better than the old one, i.e. thinking out of the box…):

If you remember, our team is not a big fan of “appeal to authority”, still the following words from “Constructing Cryptographic Definitions” by Phillip Rogaway (http://web.cs.ucdavis.edu/~rogaway/papers/iscisc.pdf) should be repeated:
“I would emphasize that definitions are not written in stone. They emerge, change, and die out far more often than people imagine. They are part of a dialectic within a community.”
[…]
It’s worth noting that the approach of relying on a public ledger for signature verification is not unique to IOTA. The idea was explored by several people, e.g. in “MAVE, NEW LIGHTWEIGHT DIGITAL SIGNATURE PROTOCOLS FOR MASSIVE VERIFICATIONS” by SERGIO DEMIAN LERNER (https://bitslog.files.wordpress.com/2012/04/mave1.pdf) and “Fawkescoin, A cryptocurrency without public-key cryptography” by Joseph Bonneau and Andrew Miller (http://www.jbonneau.com/doc/BM14-SPW-fawkescoin.pdf). We are sure you won’t be questioning the expertise of the mentioned persons, so we ask you to provide a definition of EU-CMA security that could be applied to MAVE and Fawkescoin, after that we’ll use it to verify your claim of IOTA’s EU-CMA security being broken.

9 days later there was still no answer, so David wrote (#69):

[…] is this still being worked out or should the statements and claims be publicly retracted? We have been working around the clock to ensure 100% best practices, but so far what we have received is inconclusive and no clarification on the very bold statements made by Ethan.

Neha’s brief answer was (#70):

We’ve had a few time-consuming things going on on our end. A response is forthcoming. Unfortunately it might not be on the time frame you’d like.

Another 10 days later she wrote that she did not know how to reply because she found it confusing — what had been in discussion and required by the IOTA devs for weeks was suddenly “confusing” (#71).

Instead of providing evidence for Ethan’s assertions, she sent another pack of bundles and asked if they validated. At this point you remember her confused mails where she confused bundles and CfB’s patient answers.

She confused it again and CfB answered politely (#72):

One of the bundles is not valid, but it shouldn’t be hard to fix it, just write the correct bundle hash into the corresponding field and redo the PoW.
We see you used tx4 to “decouple” probabilities of finding inner collisions for tx3 and tx5. Does this mean you will retract the claim of Curl-P not being pseudo-random?

On the 6th of September, Neha sent their report which did not take into account practically everything they had learned from CfB over the discourse of the last almost two months (!) (#73). CfB replied to this and his answer is practically the foreshadowing of how the IOTA Foundation later refuted all of the DCI claims.

So instead of taking into account what the IOTA devs had been trying to explain all the time, the DCI team refused to do so leading David to write (#76):

We are beyond baffled and frankly shocked at the moment. We were just reached out to by a CoinDesk journalist that Ethan contacted in an attempt to rush out this publication.

David summed it up well in one of his last mails (#78):

The repeated bugs in your code lead to weeks of postponements, and you still have not answered even half of our questions. This is the most unprofessional behavior I have ever witnessed by an ‘academic’.

On the 7th of September Neha replied:

We will take [CfB’s] comments under advisement. Tell us of any other factual issues you have with the report, and we will take those under advisement as well. We will be publishing tomorrow.

That’s what cooperation looks like then at DCI. CfB summarized the problem about it in one of his last sentences:

I think if your team fixes all issues in Ethan’s findings there will be nothing to publish left.

However, this story was published and caused the biggest FUD-wave to the IOTA project.

Food for thought

You might wonder, why people would act like this (delaying communication, not providing proof, refusing to talk about the details, rushing announcements/publication…). Moreover, the question remains why all these questions seem to cause so many problems if you take into account that it was the IOTA Foundation who had asked the MIT DCI Lab for a technical audit back in May 2017: all the information was on the table from the start.

Here is one hint: Read about the background of the persons involved, I shall quote the Foundation’s article here:

Neha Narula
Neha Narula, DCI Director, is playing an active role supporting Bitcoin’s development of the Lightning Network [emphasis added], a proposed / experimental solution for fast and inexpensive off-chain transactions to solve Bitcoin’s problem of slow and costly on-chain transactions.
Ethan Heilman
Ethan Heilman, Partner at DCI and lead author of the IOTA vulnerability report, is also part of the leadership at DAGLabs, a for-profit company based in California that is working to build their own DAG-based protocol based on the SPECTRE white paper. As IOTA is the current de facto leader in DAG-based DLT protocols, comparisons are often drawn between the two protocol designs because SPECTRE also claims to enable unlimited transaction scalability. Around the time when this vulnerability report was published, DAGLabs was in the middle of a Series-A financing round. At the very least, the vulnerability report was published at a very convenient time for DAGLabs.[emphasis added]
The IOTA team has been aware of Ethan’s expertise in the space for some time, and reached out to him personally as far back as May 2017 to ask for a technical audit of IOTA’s code. At that time he disclosed that he was undertaking similar research, which may result in a conflict of interest. From our point of view, this brings up a serious question. If there was a potential conflict of interest then, how is it possible that he could objectively review IOTA’s code soon after while being a member of the leadership team at a direct competitor going through a major round of fundraising? [emphasis added]

I have already written that the whole DCI attacks have been debunked in another article simply because the alleged attack had never been a real threat to any users’ funds (see point 1). To my knowledge, the DCI team has also never replied to the IOTA Foundation’s official response to all of this.

May the reader draw his or her own conclusions from all of this. Shamed be he who thinks evil of it

As always, I would be really happy about donations (you may also read my other articles):

KGOZYHJRYVDBSXTUSECYJVEBLDVYFKCAKAWTPTCKXMBNOWNVRDRHRVSJNIVOQUFRODFPXWYSGROKRWKRZWJZTJOHSX