The Nyzo (v1) protocol has failed

[MyAltcoins]

It has come to light that a single operator is controlling a majority of the Nyzo cycle. With majority vote they can use cycle funds as they want, block and kick other verifiers out of cycle, etc. As a result, Nyzo and it's novel Proof Of Diversity model has failed and is no longer secure.

Proof is available here: https://github.com/Open-Nyzo/Nyzo-clusters

And here are additional explanations courtesy of NyZoSy:

• The largest cluster consist of 2,638 addresses.
• Among them, 1,526 are currently in-cycle verifiers. 55.33% of the cycle
• Total sent to qtrade by this cluster from currently in cycle verifiers: 4,408,062 Nyzos
• Total sent to qtrade by this cluster: 8,861,490 Nyzos
• That's close to half of all that was ever deposited to qTrade (20,409,262 Nyzos)

Other strangities have been recorded over time, like spamming of other messages, invalid blocks, and recently selective, targeted blacklisting. Now another strange thing is going on, with verifiers and sentinels not being able to restart unless the blocks are cleared, every time (means not productive until several cycles)

The CE version was not a miracle cure, did not fix all. Just a helper, if enough users ran it and reported the logs and issues.

But all this is nothing with regard to the current situation. These are just mosquitos bites, distracting everyone from the fact that 55% of the cycle is controlled by a single entity. Don't trust me, verify. Data is on github, see pinned message, run your own analysis.

55% of the cycle means for instance the cycle funds are theirs. Means 55% of the mined nyzo are theirs. Means they can mess with the protocol, not answer to certain verifiers, freeze who they want. Also means they can greatly influence what new verifier enters the queue.

Nyzo narrative being diversity, decentralization, and relying only on the cycle and cycle rules to enforce that diversity, the current situation is a complete nonsense. It's a proof the current protocol, the current cycle have failed. No one from that 55% of the cycle showed up yet. Not a single user, coming out and offering help to deal with the connectivity issues related to their nodes, or asking how to mitigate the issue, how to help Nyzo long term. Only explanation I can see is that this is a hostile and coordinated takeover, over years, while milking everyone else.

Comment from core devs would be greatly appreciated to help guide the Nyzo community and open doors to Nyzo v2 through the use of Nyzo "sustainability feature" as described in the last pages of the original whitepaper: https://relay0.nyzo.co/staticWeb/nyzo.pdf

[n-y-z-o]

We appreciate your analysis, and we do hope that others run the analysis and really dig into the data. This is what Nyzo is all about. This is a community-driven effort, and that effort requires an understanding of the core technology in order to succeed.

While we have stepped back from the community to allow the community to make its own way, we have remained committed to monitoring the core technology of the Nyzo blockchain and ensuring that the blockchain runs smoothly and the proof of diversity remains intact.

We constantly run detailed monitoring, and we run frequent cluster analysis based on the transmissions of in-cycle and out-of-cycle verifiers. While clustering among cloud computing providers is high, this does not necessarily indicate clustering of key ownership.

We urge everyone to really dig into the data, run the scripts that are available, and modify those scripts to explore the data on an even deeper level. We think that you will find, as you dig deeper and deeper, that Nyzo is one of the most diverse blockchains in existence.

[EggPool]

The only thing we needed here is a simple thing, the qTrade deposits. In the Github, I provided the CSV that is a direct export from the chain, all deposits to qTrade. This is for convenience, and I urge you to check as well this data is correct.

I purposely did not share the small python code to id the clusters, as I wanted others to analyze by themselves, with different means. This is not rocket science, I'm pretty sure you can do the thing in excel even if you're not a dev.

As n-y-z-o said, you need to dig deeper and deeper. A superficial analysis of the qTrade deposits only shows small clusters. But you can renew your deposit id as you want on qTrade, so one account is not one fixed id.

There, the large cluster followed the following method in order to obfuscate their tracks:

• generate a new deposit id on qTrade
• pick a few random verifiers from their list
• deposit with that id All by small batch, all by changing the deposit id for every new batch. Just, as they did random, there are overlaps and with time, all end up connected.

Like basically at one point they have A and B connected with an id the next batch C and D with another ID and 20 batches later, they connect A and D with yet another id. If you only take a superficial look, you think there are only small clusters. You need multiple rounds to stick all of them together since in practice, it's more intricate than the simple example above.

So far, two fully independent analysis, dcct and mine, concluded to the same thing. Each one from its own data gathering and its own analysis. I redid it fully alone, not trusting data nor code from dcct, redid all in-house.

55% of the cycle sent to the same qTrade account. Is there another explanation than a single entity owning these?

[reb0rn21]

The node join spam with the red queue was something that was ongoing for a long time, ppl seen it, community refused to take hash actions, devs also did not want to flag excessive node join spam (more then original code do) as DDOS attack and exploit to nyzo Now we have that abuser and criminal (to me excessive node join spam is DDOS attack) owning 55% of the cycle I monitored alone more then few node join spam that sometimes where even targeted to stall verifier and drop it out of cycle that not just to make his own queue verifier be voted to enter CE edition was not inserted in main repo and never gained majority to stop the abuse

This is just part someone did to gain majority, few verifiers where also dropped without any reason and I can only guess that is was someone who then had more then of 40% of the cycle

[jadefalke]

I guess in current state nyzo is a dead horse, everything you do to the dead horse is a lost cause. We need a clean new start and an imporved POD with more security measures. Either a cycle reset or this one is done.

[n-y-z-o]

There are a lot of frustrations here. I get that. You lose verifiers and don't know why, and we choose not to include certain code modifications into our repository, even though you think they are necessary.

If we don't include something in our repository, it is because we don't feel it is necessary in the core repository, not because we feel it is unnecessary overall. The community owns this project, and the "red-node" issue is a great study in the exercise of that ownership. You can run whatever code you choose, and it is the nature of the democracy that you need to convince others to use your code.

I would first like to note that DDoS cannot remove a properly protected verifier from the cycle without a sustained effort that causes its performance score to warrant removal. We have not yet seen a single case where this happened, and we monitor every removal. Version 612 (http://tech.nyzo.co/releaseNotes/v612) was released to help verifier operators spot tracking issues early so that they could be addressed before resulting in removal. Version 608 (http://tech.nyzo.co/releaseNotes/v608) was released to allow sentinels to use verifiers controlled by other operators as data sources. This provides further robustness against attack, as even DDoS'ing the entire cluster of verifiers protected by a sentinel does not allow the attacker to interrupt the sentinel's protection.

Version 547 (http://tech.nyzo.co/releaseNotes/v547) was released to allow sentinels to send blocks for joining the cycle to prevent DDoS'ing from affecting which verifiers are able to join. Combined with version 608, this provides a formidable guarantee that the cycle composition is honest and fair.

I would also like to note that the transparency of Nyzo allows @EggPool and dcct to perform their analyses. With many other coins, such analyses would not be possible. With Nyzo, anyone willing to spend enough time learning the system can examine, in fine detail, virtually all aspects of the system.

Finally, three questions: (1) If someone is smart enough to take control of 55% of the cycle and rotate accounts when sending to qTrade, do you truly think they would be naive enough to then use intersecting (overlapping) sets of accounts in a way that allows their control to be identified? (2) Why has the cycle fund not yet been drained? The threshold for cycle transactions has been 50% + 1 since v573 (http://tech.nyzo.co/releaseNotes/v573). (3) Since the peak cycle size of 2890 at block 15345949, a total of 273 verifiers have left the cycle. Of these, 197 (72.16%) are contained in the cluster_all file (https://github.com/Open-Nyzo/Nyzo-clusters/blob/main/cluster_all.json). Does it make sense that a nefarious actor who has worked so hard to gain control of the cycle would lose so many verifiers without exercising that control?

We're going to do an analysis of the qTrade transactions. This will probably take a few days, as we want to be conscientious and meticulous in this analysis.

In the meantime, I encourage everyone to take a deep breath, read some documentation, and write some code. To us, this always was a project to see if we could build a better blockchain: one that is truly democratic, truly decentralized, energy efficient, scalable, and as fair as possible. If we see evidence that the system has evolved to an unfair state, we will gladly admit it as a learning experience. But our understanding of the mathematical underpinnings of the system, the implementation of the system, and all behaviors we have observed so far all suggest that Nyzo is still a fair, democratic, and highly diverse system. And, quite honestly, we feel Nyzo is still one of the best damn blockchains in existence.

[reb0rn21]

While I was muted at nyzo discord few of my verifiers where dropped from cycle by working sentinels and verifiers, the abuser even then had to power to abuse but decided to be selective.... names of them: holo5 holo9 bolo4

And the node join spam was selective also and regulated by intensity, I had to implement CE version and node spam ban to manage some of my verifiers as node join spam was so huge no VPS top CPU (5900x level of 1 core was not good) could track mesh and keep it up with top

Also the time to implement node join ban code is passed for current situation, I blame community for not pushing the code in main repo (by any mean) when there was chance to stop abuser to use node join spam as mean of exploit and attack to gain huge lead over others

(2) Why has the cycle fund not yet been drained? LOL think why, if they do that their play is gone, there is no near price support on exchange for that kind of play

[lydiamodern]

1.About Nodejoin spam/attack There is no nodejoin spam/attack. When a node start/restart, the node sends a nodejoin message, which Cycle has to process and is fine for cycle. Don not think this a spam/attack. I think the red node(avalon barbora and other 256 IP) in queue is restarted in rotation, so nodejoin message will be sent each time it is restarted. If you still think there is nodejoin spam/attack, please provide proof. Welcome analysis here. In addition, the list provided in Discord does not contain nodes(red nodes (avalon barbora and other 256 IP), which are considered nodejoins spam/attack.

2.About kicked out by attack a. Nyzo Sentinel can protect your verifiers well, and you can setup multiple Sentinels to protect the verifiers. b. If the verifier is offline for a long period of time, the bad score will be high, reaching the threshold, and the cycle will get them out. This is the Nyzo Cycle mechanism.So when the verifier is offline for a long period of time, you can protect your verifier from ever leaving Cycle by maintaining nodes or migrating nodes.

3.About people have much nodes Everyone is fair in Nyzo. As Nyzo is known by more people, more nodes will join. Since Nyzo is not PoS, staking coins are not required. So anyone can set up multiple nodes. After the linear IP mechanism was released, the probability of cluster subnet users decreased, which is more favorable for the use of ordinary VPS. Some people are willing to set up multiple nodes and wait a long time to join, so can you.

The current mood in Nyzo Discord is not good, with some people emptying their wallets, insulting projects and inciting others to hurt the project. Nyzo's proposal is open and if you wish to use your contribution to promote Nyzo, then you are welcome. But this is not a good ways to insulting projects, demagoguery and FUD.

[EggPool]

I just had a practical example of a verifier of mine getting voted out, for bad metrics. What would be a "regular" drop, "system works fine" not "kicked by an attack". This verifier was migrated several times, was maintained, on powerful enough hardware. Ended up with a backup verifier (stalling as well) and a third backup (stalling also). Despite all my experience in maintaining verifiers, nothing I could do to save it, because large part of the cycle did not answer "blockwithvotes" requests. See discord for details.

But this is not the point here. There are several issues - ignored or waved until now - to be sorted out, but the point we need to sort out first of all is the 50%+ of the cycle owned by one entity. Once n-y-z-o will have fully analyzed the qTrade data, maybe we will be able to move forward, admit the mathematical model did not reflects reality, opt to trust the reality and listen to the operators rather than the abstract model, and have the model evolve for the better.

This does in no way lower my admiration for what the founders did, for the awesome concept, code, release notes, incremental upgrades. I'm still a die hard fan of Nyzo and want to have it succeed. Just I can't ignore the facts, and give them priority over the math model.

Eagerly waiting for more users to analyze the qTrade data.

[reb0rn21]

@lydiamodern Oh new account nice, the list of nodes that blocked communication for months was in discord, the list was huge, NO ONE ever come and said yeah some of them are mine and why they blocked themself from rest of cycle, do you own some from that list???? Why you did that, do you think all ppl there are idiots and moron

1. No usual node join do not produce xxx joins in 10min THE DDOS AND ATTACK DO!
2. The attack is always planed and targeted!
3. About kicked out we are not kids so you play dump card we are morons
4. mod in discord from day one ppl never wanted to hear issue and abuse (its common with shit coins all want moon and to drop bag with good price), do you even know how many ppl abused queue system from day one, MANY, the list was public later and still they abused it, only after weeks of me and few ppl voicing opinion dev was ready to come and "see the abuse"
5. It was same with random queue joins after some time so I just left and stopped pointing out to the attack and issue as again all are waiting for bloody moon so they can earn more and issue no one wants to hear

Ce version was "LATE" and even then with dev refusing to add node join ban limit for me NYZO was DONE, CE version never gained majority as ppl running where more attacked and droped out and some decided to revert!

And this is not the point NOW we have list of deposit which is public so everyone can check DOES SOMEONE OWN 55% or more? THATS IS THE POINT NOW

[n-y-z-o]

@EggPool Everything you describe in your kicked verifiers is designed behavior of the system. Basically, your behavior when trying to recover your verifiers caused them to be identified by some internal protections as malicious in-cycle verifiers. When this happens, you will just need to back off a little while to be cleared from the blacklists. To prevent your performance score from dropping during this point, consider implementing _fallback_vote_sourceidentifier. This was introduced in version 535: https://tech.nyzo.co/releaseNotes/v535.

Also, to avoid such problems in the future, consider reviewing the behavior of both BlacklistManager and NodeManager and see if you can identify something you did that might have inadvertently triggered the protections these classes provide. You are also welcome to use Argo 746, Argo 752, or Killr as data sources. We always run stock code on these, so if they blacklist you for some reason, you can be certain that the rest of the cycle will blacklist you.

We have seen no evidence of malicious node-join messaging. All logs and incidents we have reviewed indicate normal activity that should be handled easily by a correctly configured and provisioned verifier. If someone presents actionable evidence of malicious node-join activity, we will address it.

@EggPool Everything you describe in your kicked verifiers is designed behavior of the system. Basically, your behavior when trying to recover your verifiers caused them to be identified by some internal protections as malicious in-cycle verifiers. When this happens, you will just need to back off a little while to be cleared from the blacklists. To prevent your performance score from dropping during this point, consider implementing _fallback_vote_sourceidentifier. This was introduced in version 535: https://tech.nyzo.co/releaseNotes/v535.

Also, to avoid such problems in the future, consider reviewing the behavior of both BlacklistManager and NodeManager and see if you can identify something you did that might have inadvertently triggered the protections these classes provide. You are also welcome to use Argo 746, Argo 752, or Killr as data sources. We always run stock code on these, so if they blacklist you for some reason, you can be certain that the rest of the cycle will blacklist you.

We have seen no evidence of malicious node-join messaging. All logs and incidents we have reviewed indicate normal activity that should be handled easily by a correctly configured and provisioned verifier. If someone presents actionable evidence of malicious node-join activity, we will address it.

In reviewing your qTrade data and comparing this to data extracted by the blockchain, we noticed that the sender-data field of a large number of transactions in your file did not match the sender-data field of the same transactions in the blockchain. Whatever code you used to generate this file appeared to assume a fixed width of 32 bytes, even though Nyzo transactions use a variable-width sender data field. For instance, a lot of transactions sent to qTrade had empty sender data fields (e.g., https://nyzo.co/block/2032836, https://nyzo.co/block/2042411, https://nyzo.co/block/2027466) that were expanded to 0000000000000000-0000000000000000-0000000000000000-0000000000000000 in your file. These are obviously mistakes, and using those to connect clusters would result in incorrect connections being made.

To ensure that we answer your questions fully, we'd like to be able to identify any discrepancies between our analysis and yours as we complete our analysis. This is such a fundamental error that we feel we cannot move forward until it is corrected in your analysis.

So, could you do one of the following:

1. Confirm that you have some filtering that identifies all sender data fields less than 32 bytes and removes them from cluster analysis.
2. Modify your analysis to exclude these transactions. When you have corrected your analysis and posted your corrected results, we will proceed with our analysis.

Also, for anyone looking at perceived clusters, please consider how these clusters evolve over time. The proof of diversity is not a model reliant on any specific percentage of ownership, which is why anonymity is not actually a problem. The proof is reliant on an openness that drives diversity to increase over time and ensures that the cycle follows its own rules. Everything we have seen, including our preliminary analysis of the qTrade data, indicates that all clustering is due to early adoption, not malicious behavior, and the power of all clusters will decrease over time due to the system behaving exactly as it was designed to behave.

In reviewing your qTrade data and comparing this to data extracted by the blockchain, we noticed that the sender-data field of a large number of transactions in your file did not match the sender-data field of the same transactions in the blockchain. Whatever code you used to generate this file appeared to assume a fixed width of 32 bytes, even though Nyzo transactions use a variable-width sender data field. For instance, a lot of transactions sent to qTrade had empty sender data fields (e.g., https://nyzo.co/block/2032836, https://nyzo.co/block/2042411, https://nyzo.co/block/2027466) that were expanded to 0000000000000000-0000000000000000-0000000000000000-0000000000000000 in your file. These are obviously mistakes, and using those to connect clusters would result in incorrect connections being made.

To ensure that we answer your questions fully, we'd like to be able to identify any discrepancies between our analysis and yours as we complete our analysis. This is such a fundamental error that we feel we cannot move forward until it is corrected in your analysis.

So, could you do one of the following:

1. Confirm that you have some filtering that identifies all sender data fields less than 32 bytes and removes them from cluster analysis.
2. Modify your analysis to exclude these transactions. When you have corrected your analysis and posted your corrected results, we will proceed with our analysis.

Also, for anyone looking at perceived clusters, please consider how these clusters evolve over time. The proof of diversity is not a model reliant on any specific percentage of ownership, which is why anonymity is not actually a problem. The proof is reliant on an openness that drives diversity to increase over time and ensures that the cycle follows its own rules. Everything we have seen, including our preliminary analysis of the qTrade data, indicates that all clustering is due to early adoption, not malicious behavior, and the power of all clusters will decrease over time due to the system behaving exactly as it was designed to behave.

Also, in the future, we hope that the community will be more responsible in the claims they make. If you have concerns, raise them within the community and try to fix them yourselves. If you feel that the community cannot fix an issue, present it to us. If you are frustrated that we're not agreeing with your concerns, collect better data and present it to convince us. Don't just shout louder. Every time we get involved, it's a loss for community autonomy, and we expect you to be more thoughtful when you insist on our involvement.

Nyzo is working exceptionally well. While much of the community obviously understands this, we are disappointed that so many of you don't seem to understand or appreciate the amazing system we have all built together.

[EggPool]

Sticking to the main point: fixed data with some context https://github.com/Open-Nyzo/Nyzo-clusters/tree/main/V2

[n-y-z-o]

@EggPool Thank you for the corrected data. I see that the original estimate (2,638) was inflated by more than 50% over the revised estimate (1,758).

Also thank you for confirming with qTrade that deposit IDs are globally unique and never reused.

With this knowledge of qTrade deposit IDs, let us say that we have two deposit IDs. We will call these QT_0 and QT_1 for convenience. Let us imagine that we find these IDs used in transactions as follows in the blockchain:

block 100: QT_0 block 150: QT_1

At this point, it is possible that QT_0 and QT_1 represent the same account on qTrade. However, imagine that we then see the following.

block 200: QT_0

This establishes one of two possibilities:

1. QT_0 and QT_1 represent different accounts.
2. The person sending the funds made a mistake and sent to an ID that is no longer valid. Even if qTrade is able to fix this mistake (and I assume they would, because they are awesome), it is still a mistake.

Do you agree that one of these possibilities must be true? Can you offer another explanation?

[EggPool]

I see that the original estimate (2,638) was inflated by more than 50% over the revised estimate (1,758).

The original estimate, from DCCT, that was first sent to you privately by mail, did not have this error.
This error was mine, willing to give a quick independant confirmation. DCCT estimate was > 50% in-cycle, my erroneous one 55%, my corrected one 51% of in-cycle.

The error I made should not make the data nor dcct analysis less credible. I'm the messenger, voicing the repeated concerns of a part of the cycle (less and less since the recent drops)

[EggPool]

Let us imagine that we find these IDs used in transactions as follows

I suppose you mean these transactions, block 100, 150 and 200 would have been sent from the same verifier?

[ccaoc]

@EggPool I have another question. because I have nodes in the nyzo queue, and I'm more concerned about whether it's fair for nodes to join: Are these nodes in the list joined in an un-normal way?

• If so, please provide proof so that we can read. Post the actual proof(logs,way,) not speculation.
• If not. Then I think Nyzo is still an interesting project. Similar Accusations have been made during the development of consensus mechanisms, But that doesn't stop later people from participating in.

Last thing: You add the issue, the purpose is in the hope that the team can fix it? or just to prove to others that you think Nyzo failed?

[MyAltcoins]

The case is clear here, there is a succint data that Nyzo is currently centralized and that one entity is controlling majority of the cycle. Confirmations have come from multiple sources including the one that cannot be named publicly.

The data proving the above was sent to the core devs privately via email which they chose to ignore and didn't respond after more than a week. Hence the data has now been posted publicly. It is up to the core devs to verify the data and confirm or deny the conclusions by posting corrected data or solid proof proving the opposite. But all we see so far is ego battle and putting head in the sand refusing to face with consencenses of centralization.

This is all done as an desperate attempt to try and save Nyzo even though we all failed together as a community since after almost 4 years Nyzo hasn't found a single meaningful usecase that is used in practice. Quite the contrary, as the data suggests, Nyzo has become abusers playground and cashcow hence the endless decline in price.

If Nyzo is to move forward, technical pitfalls that allowed one entity to control majority of the cycle and abuse other verifiers need to be fixed and community needs new leaders that will steer it in the right direction. Also DDoS and SPAM are a real issue that hasn't even been put to a proper test due to Nyzo failing to reach any adoption. Instead it was limited to the abuser using it as a secret weapon to additionally increase its control over the cycle. Human greed has no limits unfortunatelly.

Last thing: We can also speculate that the entity controlling the cycle is posting in this thread and discord via dummy accounts.

P.S. it saddens me to write all this as we all put countless hours into Nyzo over the years but we must face the reality and try to move forward.

[n-y-z-o]

@EggPool Like you, I was just trying to stick to the main point and get to the analysis of apparent clusters of ownership in the qTrade transactions. The point here is that even a small number of erroneous connections can significantly inflate the size of perceived clusters.

I suppose you mean these transactions, block 100, 150 and 200 would have been sent from the same verifier?

I'm trying to establish a basic rule to be used in analyzing the file. You confirmed with qTrade that deposit IDs are globally unique and never reused. This allows us to know that, if the same qTrade ID is used twice, we know that it represents the same account.

However, by looking at how qTrade IDs are used over time, we should also be able to establish which identifiers represent different accounts. This is a fundamental early step in analysis, and I want to be sure there is agreement on how to interpret this data before moving forward.

[EggPool]

I have another question. because I have nodes in the nyzo queue, and I'm more concerned about whether it's fair for nodes to join:

Like you said, it's another question. If you want to report an issue, you can open a new github one (you did it in the past, you know how that works). If you have concerns about joins and want to discuss them with the others, you can use the discord, that's where most of the community (as in number of users) is.

You add the issue, the purpose is in the hope that the team can fix it? or just to prove to others that you think Nyzo failed?

I don't feel this place is appropriate for insinuations or personal attacks. Have a look here, just as an example: https://github.com/n-y-z-o/nyzoVerifier/pull/39 Is that from someone trying to help or kill Nyzo?

I will keep the Github for dev and data, not for trolling. There is much noise and frustrations around the main issues, this doesn't help solve anything.

[EggPool]

However, by looking at how qTrade IDs are used over time, we should also be able to establish which identifiers represent different accounts.

We need to be precise as you pointed out earlier. Identifiers can refer to qTrade id or verifiers identifiers. When formalizing your example, you didn't tell whether the 3 transactions were sent by the same verifier or not. I understand you meant they were, but it's worth telling because if they are sent from the same verifier, this means it's the same user/entity sending these transactions.

A more complex analysis could indeed hint at a minimum number of different qTrade accounts involved, but has no reason to impact the cluster analysis itself.

As I understand it, the relationship goes two ways: Let say Verifier V1 sends to qTrade account Q1 then sends to Q2, then sends to Q1 again. No mistake, two different valid qTrade ids, two different qTrade accounts. This means both qTrade accounts are linked to V1. That V1 deposited to one single account or to two (or 5) of them has no incidence on the relationship. We all know there is no Nyzo powered marketplace, there is no service paid in Nyzo. When someone sends Nyzo to qTrade, it's for him (or a relative) to sell or obfuscate, it's not to pay for something.

When referring to the large cluster, I say controlled by "one entity". Not one user, not necessarily one single qtrade account. Imagine a team of a few users: one dev, one owning a hosting company... They can co-operate a large network and split the benefits between several qTrade accounts. Would look just as this. But even a single person, using several qTrade accounts so he can withdraw more, would look the same as well.

So yes, we could have an idea of how many different qTrade accounts are involved. But this is rather an internal qTrade concern, this does not imply these accounts are not connected. They are by the deposit itself.

The link is not weaker with
V1 -> Q1
V1 -> Q2
V1 -> Q1
(heavy suspicion of 2 qTrade accounts)

than it is with
V1 -> Q1
V1 -> Q2
(can be one or 2 qTrade accounts, can't tell)

same with V1 -> Q1 V2 -> Q1 linking V1 and V2

[EggPool]

One last thing, about the validity of the assumptions used for the clustering:

Apart from the large cluster, other smaller clusters have been identified just the same way. They have been recognized as belonging to known users, and are either the real clusters, either just a subset of the users clusters, but for what it's worth, there was no occurrence of inadvertently merged clusters.

For all identified and known clusters, the analysis gave a low estimate of the real clusters. Same or less elements, not more. The large cluster is composed of verifiers no one among the active community recognizes as his, which makes it even more suspicious.

Then the uncertainty goes both ways. Recent joins did not deposit to qTrade yet, some may have used a temporary address and not be visible as easily aso... We can expect the tracks to be more difficult to read now that it has been exposed.

[reb0rn21]

We had a list at discord with same large cluster blocking other, list was posted and with the question is there some issue or why would anyone do it, none in only nyzo community come forward in 2+ months to say he own ONE of the verifiers NONE nor to produce explanation

Nyzo is under attack and so far I can only see Nyzo dev play stupid card, I would like to know why?

[n-y-z-o]

@EggPool I am simply trying to focus on the analysis. It's easy to get distracted with everything going on in this thread, and precision of language is important for maintaining focus.

This is an analysis that is based on the concept of accounts in qTrade. We want to be able to articulate what we know know with certainty.

I did not mention Nyzo accounts in my question because I was trying to get down to the core irreducible concept.

So yes, we could have an idea of how many different qTrade accounts are involved.

I'd actually like a more precise answer than this to make sure we're talking on the same terms. Do you agree, based purely on the ordering of qTrade sender data that I presented in the blockchain _[QT_0, QT_1, QT0], that QT_0 is a different account in qTrade than QT_1?

If you disagree, please provide an alternative explanation, but please stay as focused as possible on the concept of what we can know about qTrade accounts based on ordering of qTrade sender data in the blockchain.

[EggPool]

From a general point of view - outside of the context of the cluster issue - and not taking into account the verifiers themselves:

The ordering of qTrade data [QT_0, QT_1, QT_0] alone can mean

• QT_0 and QT_1 are two different accounts
• whoever sent the tx made a mistake (alike the empty data txs you pointed out), used an old id instead of the new one (and all it takes may be a support ticket to fix them all in one go.).
• qTrade reminds the old, globally unique QT ids and routes them properly anyway.

Now, in the context of this precise issue we really don't care, don't try to know how many qTrade accounts are involved. Cutting the question into too small pieces, forgetting the reality of the link created by the transaction, and considering each side independently can't give a meaningful result.

What makes sense to me is analyzing the transactions, that are links between verifiers ids and qTrade ids (not accounts). There is no need for smaller independent, uncertain abstractions like qTrade accounts. The data we have access to is the transactions, not the qTrade accounts. Even having the qTrade accounts data would not give more info (can be one account or 100, does not change the cluster)

Do you agree that

1) V1 -> Q1 V2 -> Q1 Means V1 and V2 are linked

2) V1 -> Q1 V1 -> Q2 Means Q1 and Q2 are linked?

If not, why would that be wrong?

[n-y-z-o]

@EggPool I am simply trying to focus on the analysis. It's easy to get distracted with everything going on in this thread, and precision of language is important for maintaining focus.

This is an analysis that is based on the concept of accounts in qTrade. We want to be able to articulate what we know know with certainty.

Also...

If we see evidence that the system has evolved to an unfair state, we will gladly admit it as a learning experience.

I'm just trying to nail down some basics for an objective analysis that is deeper than the initial clustering based on unlimited bidirectional connection.

If you would like a more detailed analysis, let me know. If you would like to stop here, that's fine, too. At this point, I can confirm that, based on unlimited bidirectional connection of all qTrade receipts with 32-byte-wide sender data fields, the largest cluster is 1,758 addresses. This is trivial to verify based on publicly available blockchain data and a naïve connection algorithm.

[BunnyBigKick]

@n-y-z-o

Did you sleep well last night?

First, I don't like the tone you are using while addressing us, the community.

"Also, in the future, we hope that the community will be more responsible in the claims they make. If you have concerns, raise them within the community and try to fix them yourselves. If you feel that the community cannot fix an issue, present it to us. If you are frustrated that we're not agreeing with your concerns, collect better data and present it to convince us. Don't just shout louder. Every time we get involved, it's a loss for community autonomy, and we expect you to be more thoughtful when you insist on our involvement."

We did probably all we could, we presented the issues many times, we always collected data needed, we offered our solutions which were good but convincing someone who do not want to hear and accept this is very hard, it's actually impossible.

Yes, you had the reason to act like this, it's quite simple, you were aware what's going on from the start. This started just after you "left" discord and community in the name of democracy, autonomy and better development, we believed you. This happened on 04/02/2020. You are still on Nyzo Discord and you are carefully watching what's going on all the time. One month after you "left" your precious and beloved community, the serious problems with red node joins started, we were all in panic mode for some time, except you. After long discussion about this issue we tried to signal you that problems are real, again no response from your side. We, the community (NyZoSy) made well working CE verifier which prevents red node joins, you have been informed about this too, no response, zero.

There is only one conclusion and you know what's that. You underestimated our abilities and this is your biggest failure.

Good luck K.! ;)