Modification: Recommendation for removal of notaries for abusing Filecoin Plus

[raghavrmadya]

Issue Description

Certain notaries have been found to have abused the Filecoin plus program by awarding DataCap without conducting thorough due diligence and raising flags for collusion

Impact

Proposed Solution(s)

Remove the following notaries from the Filecoin Plus program:

1. ND Labs
2. Newwebgroup
3. Gate.io
4. ipfscan
5. STCloud
6. Tom - Origin storage

Timeline

1. Proposal discussed in Jan 17th, 2023 Governance calls.
2. All notaries in question will pause signing completely
3. Community Discussion until Jan 20th 2023 at 12 noon PST
4. Action taken by RKH based on community consensus

Technical dependencies

RKH singing to remove notaries from multisig

End of POC checkpoint (if applicable)

Risks and mitigations

Related Issues

[raghavrmadya]

Applications in question -
filecoin-project/filecoin-plus-large-datasets#852
filecoin-project/filecoin-plus-large-datasets#908
filecoin-project/filecoin-plus-large-datasets#931
filecoin-project/filecoin-plus-large-datasets#947
filecoin-project/filecoin-plus-large-datasets#956
filecoin-project/filecoin-plus-large-datasets#1085
filecoin-project/filecoin-plus-large-datasets#1111
filecoin-project/filecoin-plus-large-datasets#1195
filecoin-project/filecoin-plus-large-datasets#1205
filecoin-project/filecoin-plus-large-datasets#1440

[raghavrmadya]

Further evidence received from community in relation to this proposal -

"Based on the recent analysis over the past few weeks, it has come to light that many of the notaries involved in these applications have been suspended for not adhering to the guidelines of the Filecoin+ program. This further strengthens the suspicion that the miners we are investigating are likely fraudulent.

MinerID's of potential fraud:
f01852325
f01852023
f01851482
f01852664
f01852677
f01966534
f01969202
f01964073
f01965334
f01964002
f01938721
f01938718
f01938717
f01938665
f01938714
Here is some information about the interfaces on the locations in question.
All of these miners ( f0196***) are located at Zenlayer, but in different geographical locations. However, if you check the IP addresses of these miners, you'll find they all lead to a MikroTik login page. This could just be a firewall for the miner, it's nothing unusual. However, the graphics page is not shielded, so if you visit the IP address 129.227.221.202 (f01965334) at the URL http://129.227.221.202/graphs/, you will find a list of all the interfaces on the Mikrotik router. Additionally, in your browser's tab, you will notice the hostname of the device, which is "hk-ros1."
Additionally, if we take a look at a different IP, such as 98.98.147.210 (f01969202) by visiting the URL http://98.98.147.210/graphs/, we see the same hostname in the browser tab and the same interface names.
The interface names are:
2818-法兰克福
2819-伦敦
2820-吉隆坡
2821-雅加达
2822-孟买
2823-曼谷
If we translate these we get;
2818-Frankfurt
2819-London
2820-Kuala Lumpur
2821-Jakarta
2822-Mumbai
2823-Bangkok
Furthermore, if we examine the locations mentioned in the CID reports of these LDN applications and put the pieces together, it raises some heavy suspicions. It appears that we are not looking at multiple locations, but rather one physical location with multiple VPNs being used to conceal the true location and comply with FIL+ regulations."

[NDLABS-Leo]

Hello RG. @raghavrmadya
ND has been actively active in the community as a notary. I often receive signature applications from SLACK through DM me. Besides the LDNs you listed, ND has also left comments for many LDNs, some of which are supported and some are not able to sign for them.
Following is the fact and why I was signed for those LDNs:
852: Sign twice. The second time I left a comment and checked the onboarding situation for the client. Before that, the chock bot has not been enabled, so I cannot see more information without any technical tools.
908: No Signature
931: Signed once, and signed in the second round, because the client has done the authentication, the data onboarding situation was compliant before signing, and the chock bot has not been activated at this time.
947: Signed once, for the first round. because RG has asked the questions and the official released the quota, at this time the chock bot has not been activated, we can only review the basic information of the client.
956: No Signature
1085: Signed once, for the first round. because the chock bot is enabled at this time, the chock bot shows the client's onboarding status and all three items meet the standard before signing.
1111: Signed once: In the third round of signing, the chock bot was not enabled at that time, and the user's node ratio is compliant.
1195: No Signature
1205: Signed once: in the second round of signing, because the chock bot is enabled at this time, and the chock bot shows the client's status and all three items meet the standard before signing
1440: No Signature
When ND is currently reviewing LDN, it will mainly based on the following rules:

1. In the absence of a check bot, ND mainly reviews the basic information of users (user KYC, subject authenticity, data samples), and the encapsulation ratio of nodes does not exceed 25%
2. In the case of check bot, ND will mainly refer to the information of check bot.

Regarding the fact that these LDNs have a common IP forgery, ND is not aware of it. It is difficult for us to know that these LDNs are all IP forgery without investing a lot of technical inspections. And, if only one notary signs more LDNs, it will be deleted by the Filecoin Plus program,
Whether this decision is too arbitrary. Because active notaries are bound to have a higher risk of being deleted.

Also, of all the LDNs you listed, there are many other notaries who did more signatures but weren't affected, and gate.io we don't seem to see its signatures yet are listed (if anyone can sort it out in full It would be great to come out with all the signatures),
Please tell us the detailed logic of making this list.

Once again, RKH is requested to carefully consider this situation.

[newwebgroup]

Hi RG, @raghavrmadya
First of all, we are surprised and saddened to be on the above list. We don't know what the specific reasons are in this list of violations?

I reviewed and organized the LDN mentioned above and documented the time period and reasons for my signature.
The document is as follows:
https://docs.google.com/spreadsheets/d/1esT0hHy7RmHFQhflFOvn1IWyCt0GfSAvqFgnD7I0zt8/edit?usp=sharing

We signed on to five of the 10 issue LDNS raised by the community. The total number of signatures is 10. We signed many of these LDNS in the first round, and after doing the basic KYC, we were willing to support them going forward.
I have carefully reviewed each of these signatures again, and we think we did the right thing under the circumstances. If we were to go back in time again, we would still be in favor. I believe the vast majority of other notary public would have made the same decision.

Notary public is a public welfare post, there has been no incentive system. So even though we have about 50 notary public in V3, only about 20 are actually active. There are more than 1,000 applications for LDN.
As an active notary public, in addition to signing the above LDNS, we also check and sign many LDNS from the Slack #fil-plus-application-review channel. We've always been active notaries, and we think we've helped a lot of clients move forward.

Since the entry of V3 notary, we have made progress step by step.
In the earliest days, the notary public team did almost no KYC work.
With the introduction of T&T, notaries are obligated to do KYC work, but most notaries can only do simple KYC verification through the Filplus website checking SP allocation ratio and email verification.
With the CID Checker, the granularity of KYC goes even further. We can check with the CID Checker if there is CID sharing, if SP locations are evenly distributed, and so on.
But CW practices and mentioned more difficult KYC checks are difficult for most notary public. (For example: CID test whether the SP search channel is normal, whether the SP uses VPN, etc.) This includes me.
Since the entry of V3, we have been constantly learning. A few days ago, Cw pointed out our mistake in signing #1085, and we corrected it immediately. At that time, we flagged it to RG and tried to contact Cw through Slcak, hoping to learn more skills about KYC from him.

All in all, our notary may not do a very good job, but we have paid a lot of energy to work here, and have been learning and making progress, and have been active in the community to help more people.

If we judge whether a notary cheats only by the number and time interval of signing a certain LDN, this is not agreed by us.
Looking at all the LDNS, there are many cases where one notary has signed multiple times, or two notary have signed within a short period of time, which does not mean cheating.
We think the key question is "What is KYC? How?"

How to do a good job of KYC? Further help notary public without too many concerns about the work
We believe that T&T needs to set up a standard of inspection when the LDN meets certain conditions before the notary can sign for support.
If there is no inspection standard, it is a very dangerous thing for these active notary public.
Because everyone uses KYC differently, everyone has different KYC abilities.
If Notary public A considers the LDN compliant and signs it, Notary Public B may consider it inadmissible after checking it.
If notary A signs a lot of fraudulent LDN when he thinks the KYC work has been completed, and eventually leads to the cancellation of his notary.
This, for the vast majority of notary public like Notary A, will only be more inactive.

We hope the T&T team will think again

[stcloudlisa]

Hey, I am Lisa, I am from the STCould, STCould focus and layout Filecoin in 2017, in the first test, second test, space race and the main network have good results, we also have been concerned about the development of the community, took out 10 million to set up the IPFS investment fund.

Among the 10 LDNs you mentioned, 3 of them we did not sign, 5 were signed only once and 2 were signed twice, 80% of which were signed before the bot was developed. Only 2 LDNs were signed even after bot was developed because bot showed everything was fine, no CID sharing, reasonable SP allocation, almost no duplicate data, and reasonable backups.

Here are our statistics.

852: signed 1 time, signed before bot came out

908: No signature

956: Signed twice, both times before the bot was developed

1085: signed once, before the bot came out

1111: signed once, chock bot not enabled

1195: not signed

1205: signed once, bot showed normal before signing

1440：No signature

931：Signed twice, respectively the first and fourth round of signatures, the bot was not yet out when signing

947：Signed once, bot check no problem before signing

RG, here, I want to say sorry, I am a copywriter, I am not technical. I am in charge of ledger because I joined STCould in 2019, I started writing articles for IPFS and Filecoin, it was still in development testing, first, many people don't understand what is the decentralized storage ? Second, more people wanted to know about the development progress of Filecoin, including the content of the network upgrade, when the main web will be online, etc. Third, in order to get faster content about IPFS and Filecoin, I joined slack, read community discussions, read github proposals, and then write articles. Since I wrote the content of the company's notary application, I have been responsible for ledger from my side.

Here are some links to my articles.
https://mp.weixin.qq.com/s/jA0sDjP2FxFPvCaJr3LqFw
https://mp.weixin.qq.com/s/hso4uTZFG0VRV_ZqvLkz1Q
https://mp.weixin.qq.com/s/5zv7T-pWgwxavD7NRWRqkg
https://mp.weixin.qq.com/s/26YCBV0EzHdxlRfda7cNxw
https://mp.weixin.qq.com/s/hYqMtNK6EbbDDVOIk_Ye_w
https://mp.weixin.qq.com/s/URqLTz2dbtSV-7xYLFuPAQ

I am sorry that I did not identify the VPN. In order to prevent similar things from happening again, stcould set up a 3-5 person notary team, all signatures need to be discussed by the team and approved by multiple levels before they can be signed, at the same time, I will actively study and improve my ability, I hope you can carry out relevant training work.

[ipfscn]

Hello RG. @raghavrmadya
Founded in 2017, IPFSCN is an IPFS-based metaverse community. We focus on IPFS and Filecoin. We have sponsored hackathons before. We hold various events, AMAs, and output articles and videos almost every quarter around the world.

We have carefully checked the LDN you have listed, among them, we have only signed for three LDNs, and only once,

1085: In the first round of signing, I asked the customer to send a domain name email to confirm the identity, and at the same time, asked the customer about the SP situation.

947: In the second round of signing, I checked the distribution of sp. Before I signed, the bot was not activated.

852: The third round of signing, the bot is not enabled, I checked the sp and its allocation, I think it is reasonable, so I helped the customer.

Our team's signature has very strict restrictions and is reviewed by multiple people. The ledger manager and the github manager are not the same person. Therefore, the signature must reach a consensus of at least 2 people.

Generally speaking, we are more supportive of helping customers in the first round, just like you choose to pass the application for customers, this is the first step of trust, but we will pay close attention to the distribution of customers for all signatures, once there is a problem, We will stop distribution immediately.

[Tom-OriginStorage]

Hi RG, @raghavrmadya
OriginStorage is a dedicated participant of the Filecoin project, having played an active role in both the testing phase and the space race. Our team made significant contributions to the project, including a sector detection tool program, which greatly assisted others in performing sector detection. We successfully applied for and were approved as a notary in the third round of applications, and have remained a dedicated member of the notary community, committed to supporting the continued development of the Filecoin ecosystem. We have maintained open lines of communication with various departments and have been regular attendees at meetings, offering internal presentations to keep our team informed and engaged.

The following is our official merged PR
filecoin-project/lotus/pull/7844
filecoin-project/lotus/pull/6635

Regarding our signing cases:
852: Signed five times, this LDN time is relatively early, before the check bot was enabled. Each time the signature was also communicated with the applicant and then signed.
908: No signature was made.
931: Signed three times, all before the check bot was enabled.
947: Signed three times, the first two signatures were before the check bot was enabled, and the third signature was after the check bot was enabled. According to the results of the check bot inspection, it met the rules and there was no duplicate CID.
956: Signed three times, all before the check bot was enabled.
1085: Signed once, which was in the first round, and the rest of the notaries had asked questions and completed KYC.
1111: Signed four times, all before the check bot was enabled.
1195: Signed once, which was in the first round, and the rest of the notaries had asked questions and completed KYC.
1205: Signed once, which was in the first round, and the rest of the notaries had asked questions and completed KYC.
1440: Signed once, which was in the first round, and let the applicant send a KYC email to assist in KYC.

We have been putting in a lot of effort for the Filecoin community and were more active before the check bot was enabled. However, after its implementation, we found that some LDN packages did not comply with the rules, so we set a standard for our own signatures and rejected many signatures afterwards.

Regarding the VPN problem in the project, we do not think it is appropriate for the notary to take responsibility for this and conduct inspections in this area, as it requires a lot of resources and most notaries do not have this ability. We believe that the rules of the check bot need to be gradually improved, similar to a firewall. We suggest holding similar hackathons in the future to search for problems and improve the rules, and we will also improve our signature rules in the future.

Lastly, many of the above nodes are located in the United States, Singapore, Korea, and Hong Kong and are not listed in the VPN proxy list. We are committed to investigating and rectifying these cases by first halting the signing of these LDNs, in addition to continuing to provide the utmost assistance to the Trust & Transparency team in investigating the service providers involved.

[cryptowhizzard]

Hi RG, @raghavrmadya
First of all, we are surprised and saddened to be on the above list. We don't know what the specific reasons are in this list of violations?

I reviewed and organized the LDN mentioned above and documented the time period and reasons for my signature.
The document is as follows:
https://docs.google.com/spreadsheets/d/1esT0hHy7RmHFQhflFOvn1IWyCt0GfSAvqFgnD7I0zt8/edit?usp=sharing

We signed on to five of the 10 issue LDNS raised by the community. The total number of signatures is 10. We signed many of these LDNS in the first round, and after doing the basic KYC, we were willing to support them going forward.
I have carefully reviewed each of these signatures again, and we think we did the right thing under the circumstances. If we were to go back in time again, we would still be in favor. I believe the vast majority of other notary public would have made the same decision.

Notary public is a public welfare post, there has been no incentive system. So even though we have about 50 notary public in V3, only about 20 are actually active. There are more than 1,000 applications for LDN.
As an active notary public, in addition to signing the above LDNS, we also check and sign many LDNS from the Slack #fil-plus-application-review channel. We've always been active notaries, and we think we've helped a lot of clients move forward.

Since the entry of V3 notary, we have made progress step by step.
In the earliest days, the notary public team did almost no KYC work.
With the introduction of T&T, notaries are obligated to do KYC work, but most notaries can only do simple KYC verification through the Filplus website checking SP allocation ratio and email verification.
With the CID Checker, the granularity of KYC goes even further. We can check with the CID Checker if there is CID sharing, if SP locations are evenly distributed, and so on.
But CW practices and mentioned more difficult KYC checks are difficult for most notary public. (For example: CID test whether the SP search channel is normal, whether the SP uses VPN, etc.) This includes me.
Since the entry of V3, we have been constantly learning. A few days ago, Cw pointed out our mistake in signing #1085, and we corrected it immediately. At that time, we flagged it to RG and tried to contact Cw through Slcak, hoping to learn more skills about KYC from him.

All in all, our notary may not do a very good job, but we have paid a lot of energy to work here, and have been learning and making progress, and have been active in the community to help more people.

If we judge whether a notary cheats only by the number and time interval of signing a certain LDN, this is not agreed by us.
Looking at all the LDNS, there are many cases where one notary has signed multiple times, or two notary have signed within a short period of time, which does not mean cheating.
We think the key question is "What is KYC? How?"

How to do a good job of KYC? Further help notary public without too many concerns about the work
We believe that T&T needs to set up a standard of inspection when the LDN meets certain conditions before the notary can sign for support.
If there is no inspection standard, it is a very dangerous thing for these active notary public.
Because everyone uses KYC differently, everyone has different KYC abilities.
If Notary public A considers the LDN compliant and signs it, Notary Public B may consider it inadmissible after checking it.
If notary A signs a lot of fraudulent LDN when he thinks the KYC work has been completed, and eventually leads to the cancellation of his notary.
This, for the vast majority of notary public like Notary A, will only be more inactive.

We hope the T&T team will think again

Hello,

I have given this some time and thought before writing my response here. Last week a lot of turbulence was on the community and the FIL+ program.

Reading the answer it comes down to "We did not know/We were not aware". However this is not totally true. There are a few critical things i want to highlight here.

For example: filecoin-project/filecoin-plus-large-datasets#960
For example: filecoin-project/filecoin-plus-large-datasets#1028
For example: filecoin-project/filecoin-plus-large-datasets#793

This application (and some others) show that ND Labs has been involved in CID sharing and has been involved in the group of people who had wrong intentions when they applied for the datacap and as notary. This alone should be enough to remove a notary if the evidence support this.* A notary has to uphold the reputation of the community. It has been said multiple times when you applied as notary-> In case of any doubt, be restrictive.
As notary the room to make errors is very limited, let alone involvement in CID sharing. If we allow this as community I can call a dozen of people for elections round 5, get them onboarded and sign on any of the applications we want.... And we all know that this is not the way to go and we all know the red lines have been passed.

Besides the LDNs you listed, ND has also left comments for many LDNs, some of which are supported and some are not able to sign for them.

I have not read other comments then "We are supportive" , "Everything looks beautifull", "Willing to support" but not once a comment of doubt and that you were withholding on signing.

Now, i have repeated this a few times but i will repeat it again.
https://filecoinproject.slack.com/archives/C01DLAPKDGX/p1654626559136159

It has been repeated that everything is ok there and that this was all a mistake. NDlabs , Ipollo, NFTstar, Bitrise etc. All these notary's would not be signing on their own applications and would be "good" for the community but looking at #960 / #1028 Now the evidence tells us he situation is just different.

Edit: I made a* for evidence. CID sharing ( using someone else his data while you say that your are going to store different data in your LDN ) is offcourse wrong. However there is a small chance that this data can be legit if the the dataCID was the first one to appear on chain and was on / in the original LDN.

[lamborghiniandy]

Hi, I have invested in mining filecoin. I think I need to speak something from the perspective of a common filecoin mining investor.

First of all, mayber you don't know, mining cc sector is no longer profitable, given the coin price and output every year right now, mining cc sectors will be a loss for investors. Can you imagine the influence of 100 million collateral filecoin being released from cc sectors and being dumped? That is also the reason why the QAP gradually decrease in these days, and it will continuously decrease if miners cannot survive. My machine was forced to leave outside of China, which also means high migration fee and higher hosting fee. Miner ecosystem is the basic ecosystem of the entire filecoin network, if no miners can survive how do you expect filecoin can survice in the bear market? Idealistic is good but operating such a big project cannot only count on idealistic. Without 10 times QAP, all investors of mining will be dead.

Secondly, PL should make an executable standard to make miners and notaries can work with the same criterion to guarantee maximum fairness. If there is no standard or the standard is vague, there must be weakness of entire notory system. Right now the standard is far from perfect. And in my sense, it is always difficult to tell whether a LDN is real or not essentially, all of the current rules can be avoided. In the real world, Amazon does not care whether your data is real or not, he only cares whether do you pay for the storage. So how can filecoin storage can attract users pay for their data is the point. But now many people even buy data from otc market, I know the situation also happen in Europe and North America and all over the world. Because no people want to pay for the storage right now. In this sense, 99% of the current LDN does not make sense. The right definition of real data should be paid storage, but now 99% of the data is the opposite. So if PL want the ecosystem be fair, you should perfect your definition of "real data" and make it executable by everyone, rather than punish the notaries for the misunderstaning of the vague rules. Since you are the rule maker, you need to guarantee procedure fairness rather than substantive fairness just like how federal constitution rule the United States. Otherwise in the future, 200 notaries will have 200 criterions, and how will you justify which one is correct or real? In one word, as long as you make a rule, even if the ldn is shit, it should be "real data" in the system. Then what you need to do is to continuously perfect the executable rules rather than punish who find the loophole of the rules. Right?

So we can draw an easy conclusion that the if filecoin network lack a clear rule of real data for notaries, the quarrel will not be ceased forever. At the same time, cc sectors is no longer profitable, meaning that if investors can not turn to dc mining, all of the investors will turn to other projects, like eth, aleo or some more attractive projects. If you cannot retain the existing investor, how can you attract outside potential investor?

[kernelogic]

Agree with lambo-boy above regarding the price point, if CC is profitable, there won't be much FIL+ demand (to abuse) to begin with. That's probably why we are seeing a spike of LDN applications in recent months even though the program already exists for 1.5 years.

[herrehesse]

https://filecoinproject.slack.com/archives/C01DLAPKDGX/p1674206285725749

[herrehesse]

@lamborghiniandy " Without 10 times QAP, all investors of mining will be dead."

Let them, this is how a fair protocol should work. My background is mining since 2013, you do not think I haven't seen my fair share of bankruptcies and miners struggling? This is how it game works. Trying to cheat the system to survive, and allowing that to happen is the destruction of everyone, the whole community.

Letting the miners who did not take a price drop or their operational costs into account go bankrupt, is actually healthy for the ecosystem in the long run. Keeping them alive, by accepting bad behavior, hurts every single one inside the ecosystem.

[cryptowhizzard]

@lamborghiniandy " Without 10 times QAP, all investors of mining will be dead."

The reason our investors here believed in Filecoin is that this coin could actually make a difference because of the use case. Instead of having to fight against ASIC's and Cheap polluting energy that is bad for our environment, there is a use case for real data. This is where we (As Europeans) can be competitive with fast internet connections and with storage that is real and compliant.

What happens now is that we (Europeans) have to pay up ( FIP-36 fe. ) for those who maximized their profits with CC mining ( Doing custom source code and other things got get that done as fast as possible ) and cheating the FIL+ system. The choice of words you use is tale telling (I do appreciate your honesty!!!)

Datacap mining is happening where people store data without actual content (fake). Thus this means that the good players who actually do download real data, pack it and distribute it, where costs are involved, get scrutinized by the DC-Miners and will go bankrupt with them. And this is where the notary's come in. They should check LDN's and be the safeguard for FIL+ to stop this from happening. And this is what #811 is about. Because on all LDN's the above notary's did not hit the breaks on one single application.

For my 2 cents.... i am in favor of getting real data on the network (where-ever that is in this world / planet) and i am going to continue keep doing my due diligence for as long as it takes for the benefit of the community and a healthy Filecoin ecosystem.

[cryptowhizzard]

Hello,

I have commented here on NDlabs yesterday
Doing further due dilligence today i stumbled on #377 and #356.

Same thing, same response.

[Dominic92]

Hello,

I have commented here on NDlabs yesterday Doing further due dilligence today i stumbled on #377 and #356.

Same thing, same response.

First of all, thanks @cryptowhizzard for doing so much real work and spending so much time cleaning up the community and the Filecoin network.

Secondly, I have also done research on ND's applications. Unfortunately, as you said, a lot of fraud and duplicate CID are there. This can only show that ND Group is an SP, he/she is using different identities or the company grabs DC and makes profits from it.
filecoin-project/filecoin-plus-large-datasets#960
filecoin-project/filecoin-plus-large-datasets#1048

Last, don't forget the old friends of ND Groups, these are the upcoming V4 notaries, I don't think they can continue to be notaries. At the same time, I also hope that the T&T Team @raghavrmadya @Kevin-FF-USA can clean up the community through this time, and return the network to a healthy status in 2023

#765
#721
#693
#716

[Tom-OriginStorage]

Origin Storage last 15 signed LDN Cases.docx

@raghavrmadya

[cryptowhizzard]

Hello @Chris00618

It seems to still lack the technical knowledge for understanding what is going on. That is a bit unfortunate because this lack keeps you repeating the same faulty logic over and over again.

Anyway , i will explain in clear language:

It is simply because of the way things work.

If Piknik has finished dataset building they can distribute it through their own LDN wallet or / and they can distribute that same set through the FILSwan platform that is build especially for this. When you distribute the same data with FilSwan the logical outcome is that you have CID sharing between the 2 wallets.

[stcloudlisa]

15 LDNs recently signed by STCould：https://docs.qq.com/doc/DWHdidWVYUWF4bGZm

[NDLABS-Leo]

Hello @raghavrmadya appendix is ND LABS latest 15 signature record disclosures:
ND Signature Record.xlsx

[flyworker]

@herrehesse Please be quiet, if you don't want to explain carefully. In fact, I'm also curious.

A few days ago, I exposed the case of @ kernelogic illegally sharing CID (COVID-19, Fly brain, NASA, SS recovery, Unknown dataset) on Slack. The reason why Yanfei was exposed was that he is an active notary, a postive eco-builder and a famous LDN applicant, and he's also the close partner of Dcent (they had many cooperation nodes and multi-signed with each other). But my simple investigation showed that his application was clearly proved to be fraudulent. filecoin-project/filecoin-plus-large-datasets#457

In fact, there are more active members (including Filswan、Dcent、PikNik...) who have similar CID sharing and other multi-sign violation cases. They are all deliberately ignored by Dcent , but notaries from the East are repeatedly challenged and harassed by them. This is really worth our reflection. filecoin-project/filecoin-plus-large-datasets#278 filecoin-project/filecoin-plus-large-datasets#414 filecoin-project/filecoin-plus-large-datasets#432

Can these applicants with fraud experience be given a new opportunity to obtain more data caps? This is the topic of discussion that we will reach consensus. But at least, I believe that community members from the East should not be discriminated against, even though they may not have close relationship with Dcent.

In addition, I want to tell everyone clearly that sharing the public dataset CIDs of Covid-19 and NASA is essentially the same as sharing the public dataset of Tencent and Baidu. It is a kind of noncompliant fraud method that SP hopes to save the cost of data transmission. Don't think the former is tolerable, and the latter is unforgivable.
I don't know what you are talking about.
FilSwan get the dataset created in Oct 29, 2021, and our data server is running even before that.

FilSwan has been transferred more than 23,097,864.35 GiB in the past year through our communities network. We opened our data downloading servers with all the dataset we have for community use, and we did not charge for the bandwidth. We have spend over 100K USD on bandwidth last year to support the community.

Whatever your purpose it is to point at us, I don't give a shit. Opening a newly registered account and trying to cause confusion in the community is ugly.

We have more important stuff needs to do in the community, and I'm sorry I don't have time to join your ugly play.

[flyworker]

Issue Description

Certain notaries have been found to have abused the Filecoin plus program by awarding DataCap without conducting thorough due diligence and raising flags for collusion

Impact

Proposed Solution(s)

Remove the following notaries from the Filecoin Plus program:

1. ND Labs

2. Newwebgroup

3. Gate.io

4. ipfscan

5. STCloud

6. Tom - Origin storage

Timeline

1. Proposal discussed in Jan 17th, 2023 Governance calls.

2. All notaries in question will pause signing completely

3. Community Discussion until Jan 20th 2023 at 12 noon PST

4. Action taken by RKH based on community consensus

As I am tired of the argument, I support removing those notaries.

[herrehesse]

@flyworker full support.

[newwebgroup]

Hey RG@raghavrmadya
NewWebGroup's last 15 LDN signings

[cryptowhizzard]

15 LDNs recently signed by STCould：https://docs.qq.com/doc/DWHdidWVYUWF4bGZm

Hello,

Reading this explanation i have the following questions:

30 november : Firstly, I signed 1 for #1155 for the reason that the project is under FIL-E and kevin-z has reviewed and indicated that the client has passed the detailed KYB certification.
Second, I signed once for each of Feiyan's 6 large datasets
#1507, ( 1 january )
#1508, ( 1 january )
#1351, ( 3 january )
#1352, ( 3 january )
#1105, ( 3 january )
#1108, ( 3 january )
for the following reasons: Feiyan is a respected community member, the official Filecoin blog has a special article about Feiyan's constructive comments on both slack and GitHub. The number of sp's they work with is basically 1- as well as more, with each sp accounting for basically no more than 15%.
I signed 1 for 1444 ( 9 january ) Venus is one of the core four protocols of FIlecoin, which started building a long time ago, and the amount of data is rich and respected community members, I gave my support.
Then, I have 4 LDNs that are signed for the first time. I believe that the first signature, first, is a reflection of the trust given to the client, and second, if after the first round of signatures, the client is non-compliant with the rules, then I will no longer sign for the client.

I signed for #963 because, the total amount of the client's application 1.5P is more reasonable, and the client sent the domain email to verify the identity.

This is lacking self reflection. A —> #963 shows no trace of signing by you. Second, at 22 december it was already know that the SP’s visible of this client were all involved in CID sharing.

For #1208, the customer was established in 2012, more than 10 years old, better qualification, sent domain email.

Signed on 14th of december, The client gave his SP’s. Some are not reachable at all everything is on one location with no geo spread, no questions asked.

#1308, the client provided 6 SPs and sent domain emails, provided more data cases, the client voluntarily gave more information to add after simon passed the application, I think it is a more sincere client.

All miners are unreachable. Most of them even don’t have an IP adres set. Not according to the FIL+ rules where miners should be reachable.

lotus net connect f0119336
f0119336 -> {12D3KooWCEQx7H6jv9WYw6zZJy2gr8JuXFBwxGp1Lv2YKLp27pgG: [/ip4/192.168.160.162/tcp/34567]}
ERROR: failed to parse multiaddr "f0119336": must begin with /
lotus net connect f01694564
f01694564 -> {12D3KooWNbLknJBaGFUCvgyqBvxSGvzhHY3ErEsaC11iKamEKMfp: []}
ERROR: failed to parse multiaddr "f01694564": must begin with /
lotus net connect f01482290
f01482290 -> {12D3KooWQH8nnW8jM6C5nd8ZGdscqJQSccmRyWpMtgnxysnpgufM: [/ip4/199.182.234.194/tcp/34907]}
ERROR: failed to parse multiaddr "f01482290": must begin with /
lotus net connect f0723722
f0723722 -> {12D3KooWLik7pXhAJLkkC97FUejj3aZmLPCk5XMzCmPukYfXFefV: [/ip4/71.167.152.39/tcp/24001]}
ERROR: failed to parse multiaddr "f0723722": must begin with /
telnet 71.167.152.39 24001
Trying 71.167.152.39...
^C
lotus net connect f0840770
f0840770 -> {12D3KooWMPy9jK8HrVsryuSTDmSyCpNdhkcyiaQ3T7FXkxq6ibyC: [/ip4/206.123.144.236/tcp/24002]}
ERROR: failed to parse multiaddr "f0840770": must begin with /
telnet 206.123.144.236 24002
Trying 206.123.144.236...
^C

#1220: cryptowhizzard did the due diligence and the client sent the domain email on Dec 22nd. Over the next 20 days, the client aitted many people on GitHub, but there was never a notary to sign for the client. So I left a message willing to support the client for the first time and said that I would never support him again if there was a violation.

The problem here is that you signed together with IPFS.CN. As you are both from one organisation ( You hold the same stake in miners according to your notary application ) this should not have been done.

Finally, for each of the following 4 LDNs, I signed once for the following reasons.
#1085: 1 time, bot check is normal, SP assignment is reasonable, and CID looks healthy.

Same as in 1220. The problem here is that you signed together with IPFS.CN. As you are both from one organisation ( You hold the same stake in miners according to your notary application ) this should not have been done.
Secondly there were enough flags visible by that time that things were not right.

#1205: 1 time, bot checks all right, 10 sp's contacted, which is decentralized enough, no CID sharing.

No, it was not decentralized. As it was clear most of these were SP ID's were on Zenlayer. There was no duedilligence done who these SP id’s belong to, because if it was done it would be clear that most belong to Tom ( Orgin storage - subsidy of Chainup ) who co-signed on this application.

#1002: 1 time, the client gave a very detailed explanation on GitHub and contacted me on slack

By this time the CID report was already in use. All the miners used by this client were involved in CID sharing. No actions were taken to get this LDN on the right path and ask the client to provide a new set of SP’s who were of good reputation.

#1214: 1 time, 1214 is a continuation of 541, 541 was scrutinized, the amount applied for was only 1.5P, but the customer provided almost 1T data cases, the number of data cases provided was excellent.

1214 has LDN sharing and so does 541. You state that the client has rectified that, but you don’t state how / where / when and why. CID sharing is no mistake if someone does not store the data as he promised in his LDN request.

[cryptowhizzard]

Origin Storage last 15 signed LDN Cases.docx

@raghavrmadya

Hello Tom,

Apart from what you provide there is still an issue with origin storage / chainup.

I provided the community (and you) a Google spreadsheet. In this spreadsheet we have a lot of VPN's documented and on a lot of them most of the miners / SPid's belong to chainup and you are tight to that organization as origin storage is a subsidy of chainup.

It is clear that you signed on most on them. Are you going to give an explanation for that? Why did you choose not to disclose?

[cryptowhizzard]

Hello @raghavrmadya appendix is ND LABS latest 15 signature record disclosures: ND Signature Record.xlsx

Apart from the outstanding issues not answered:

1085 -> Signed while questions were outstanding by @herrehesse. Also the SP's were provided and it was clear that they were involved in CID sharing by that time.

1220 -> Signed without proper duedilligence. The sampledata was not visible anymore at the time of signing for first signature.

1205 -> Signed while questions were outstanding by @herrehesse. It was clear that these miners (SPid's) were on VPN already and mostly owned by Chain-Up ( Tom )

1002 -> Signed without geo spread. No due diligence done.

1214 -> Total cluster of ###########

1341 -> No retrievability checks done at all. Nothing retrievable / reachable.

951 -> 100% self dealing. Could have been checked in the dashboard of fil+ ( https://filplus.d.interplanetary.one/clients )

Any answers on this ? -> #811 (comment)

[Tom-OriginStorage]

Origin Storage last 15 signed LDN Cases.docx
@raghavrmadya

Hello Tom,

Apart from what you provide there is still an issue with origin storage / chainup.

I provided the community (and you) a Google spreadsheet. In this spreadsheet we have a lot of VPN's documented and on a lot of them most of the miners / SPid's belong to chainup and you are tight to that organization as origin storage is a subsidy of chainup.

It is clear that you signed on most on them. Are you going to give an explanation for that? Why did you choose not to disclose?

Thank you for your attention to my question @cryptowhizzard

1: I have publicly explained the LDN listed in this proposal at the beginning;

2: RG is to let us explain the 15 LDNs we recently signed. You can go https://filplus.d.interplanetary.one/large-datasets Check whether my export is correct;

3, your so-called VPN has no conclusive evidence up to now;
---This problem has been discussed above. You can check the historical information

4: We also have many strategies and methods to identify LDNs that do not conform to the rules. We just caught up with the Chinese New Year holiday a while ago, and we did not systematically do it. Next, we will also check all LDNs according to the rules, and try to find more problematic LDNs, so that FIL+ can develop in a healthier direction

[herrehesse]

@Tom-OriginStorage Could you respond on the 7 LDN applications @cryptowhizzard stated in the above message?

[Tom-OriginStorage]

I can respond to all the LDNs I signed, although I can't guarantee that all the LDNs comply with the packaging rules, because many of them can't be checked before the robot goes online. Now, after the robot goes online, it gives us a lot of basis. Next, we will also try our best to check the packaging of all LDN regularly and find out the defective LDN and give feedback.

[herrehesse]

And the self-dealing? Any explanation?

[fillove]

我发现了很多共享CID的LDN，让我们总而言之，不知道为什么表格跳过了那些LDN，我会继续寻找
filecoin-project/filecoin-plus-large-datasets#77
filecoin-project/filecoin-plus-large-datasets#339

filecoin-project/filecoin-plus-large-datasets#403

@raghavrmadya 我的天，他们为什么@herrehesse @cryptowhizzard 不在被撤销的公证人名单上？

就因为他们解释了吗？ 为什么他们的解释一定要合理？ 别人的解释就一定是不合理的？ 这不是完全违背了去中心化的精神吗？

The meeting of notaries will be held soon, please explain your CID sharing, your non-retrievable.

[herrehesse]

@fillove I see, the gaslighting does not stop from your side. We explained ourselves multiple times but you keep asking. Very unprofessional. You are discrediting yourself with every single response.

[fillove]

Don't always focus on other people's problems and ignore your own problems.

Don't always "step back" when it comes to your own problems.

When it comes to other people's problems, don't bite the bullet forever.

[Tom-OriginStorage]

First, you can check whether all LDN items are related to origin storage,

Secondly, what evidence do you have to prove this? Can everyone in the community freely accuse slander?

Third: I can see the historical news. Some people have also raised many LDNs that are much more serious than these problems. Why are they not found

Fourth: origin storage doesn't want to attack anyone, but it doesn't mean we are bullied.

[fillove]

Can you please explain, please, thank you @herrehesse

[herrehesse]

For people guessing what is going on --> https://en.wikipedia.org/wiki/Gaslighting

[raghavrmadya]

Hi everyone, as the issue creator I believe the discussion here is not productive anymore and I'm going to close this issue ahead of the governance call today.

[coldjoke1]

#824 #Modification: [Remove Fogmeta & FilSwan from R4 notary] #824