[DataCap Removal Proposal]Abusive Behaviour Detected on 2008 #935
Comments
|
#930 (comment) |
|
|
To provide transparency, I want to reiterate that your previous accusations have been addressed and answered more than seven times in the past six months. I am more than willing to provide you with links to these responses, as it seems you may have been unable to find them yourself:
I hope these resources will help clarify any misconceptions and promote a better understanding of the situation. |
|
Really, don't do this. |
|
According to the current statement, problematic LDNs and controversial LDNs cannot be signed by a notary unless the dispute is resolved. In the face of CID, I think that the controversy can never be resolved, because people have to face the facts! And not a lie! |
|
|
@Kevin-FF-USA @raghavrmadya The explanation is invalid, if there is a problem, it is a problem. Also ask the community to audit this person @herrehesse |
|
@0xXPunkX Thank you for asking the same question again, if you would have scrolled up a little bit you would have found the answer: filecoin-project/filecoin-plus-large-datasets#2008 (comment) |
|
According to the CID inspection report, the LDN has signed 5 rounds, not the 1st and 2nd The difference should not be so large in the stage of the uncontrollable data of a small amount of data, so the reason cannot be accepted.
|
|
@0xXPunkX What you are saying is so far from the truth. This application was signed already for over 40 times on different LDN requests due to its size. Here you can take a look: https://github.com/filecoin-project/filecoin-plus-large-datasets/issues?q=is%3Aissue+speedium+nih "The difference should not be so large in the stage of the uncontrollable data of a small amount of data" what does this even mean?
|
|
Make Filecoin Permissionless Again! FIL+ is a con |
|
Hello @dikemm - this proposal was reviewed. It seems the client has explained every instance under scrutiny clearly and transparently. There were some errors early on, as many clients have learning the processes to onboard data. There has been nothing since that we can tell. Additionally, this client has undergone all KYC and KYB standards of E-Fil+ to comply with requirements of the program. This is a completely transparent client working with transparent SP entities who are onboarding data in a distributed manner that meets the guidelines of the Fil+ program. There are no major abuse flags here. |
|
Like @Filplus-govteam has already mentioned in their comment, all of the highlighted issues above have already been explained by the client here
Extra note, retrievability of the dataset has been increasing between datacap report summaries proving the client has been actively working on this as well. |
|
I agree with you @Filplus-govteam , but there is another problem with Dcent, which is the concatenation of notary signatures, in 2008, fildrive signed three times in a row, which is already against the regulations.RG once pointed out that fildrive's LDN has major problems, a large number of CID sharing, but because fildrive actively helps Dcent to sign, fildrive's LDN can see a lot of problems at a glance, but Dcent never post dispute. |
|
The LDN of the fildrive series, 1623-1627, has a lot of abuse and cid sharing. As for whether VPN is used, I will investigate if necessary, but 1623-1627DCENT are all signed, and fildrive is also actively helping DCENT sign 2008. |
|
Everyone has the right to inquire or challenge entities, but let's focus on cutting through the clutter. Speedium and Cryptowhizzard have been active members of this community since its inception, consistently displaying openness and transparency. They have addressed all the questions raised in this thread in great detail. However, it appears that certain newly created throwaway accounts are not genuinely seeking answers, but merely attempting to undermine our credibility by creating noise. The Fil+ T&T team, PIKNIK, and HOLON have all provided their responses as well, yet the noise persists. In essence, it all boils down to noise. If you are actually interested in answers on your questions, I would suggest you to take a proper look inside their LDN issues. |
|
I don't intend to attack you, but from the point of view of signatures, you have helped every LDN of fildrive to sign, and they are actively helping you to sign. You still have many LDNs who can see their signatures, especially in 2008. The signatures are too frequent, which has violated the rules. In addition, RG has indeed questioned the LDN of fildrive. And I believe it is easy to find evidence of your signatures with PIKNIK. |
|
Hello I can add my notes about this situation as this is an E-Fil project. This client has done all they can to make their application meet the Fil+ requirements.
Regarding notary signing trends. It looks like seven different notaries have signed this application. That seems like a solid distribution to me. Yes, I see Laurapanda has signed 3 times and it was made clear that she will not sign any more subsequent allocations in a row. Please note: Currently in the E-Fil multisig we only have around 8-10 active notaries of the 35 which means notaries will have to sign multiple times to support applications. And these notaries are not always active recently. The client has reached out to all notaries and is currently stuck looking for additional support see here. We should not have situations where this occurs and I am in the process of adding additional notaries to the multisig in the next few weeks to allow for more to be available since the current majority are inactive and will be soon removed. Regarding Filedrive. I too had questions about their CID reports. They responded and had community support for their answers. filecoin-project/filecoin-plus-large-datasets#1626 (comment) Regarding @cryptowhizzard signing for Filedrive. I reviewed and it looks like he signed initially on several of Filedrive application. But, it also it looks like he was active on over 200 LDN applications and has awarded over 1PiB of DataCap as a notary. Remember, the majority of active notaries sign on many applications, so of course there will be repeat signings, it has to for the system to work and applications to receive DataCap. But it still takes 4-20 signatures to get substantial DataCap, he signed once on each applications, still requiring many notaries to support and to be involved. So to say by signing once on a specific application while he also signs on 75+ other applications also means he is in collusion with one SP is a bit of a stretch don't you think? After review, I see no major flags, communication is active and completely transparent. I think there are many claims here that are completely unrelated to this specific application. I'd ask @raghavrmadya and T&T WG to review and look to close this so the client can move on. |
@ Laurapanda does not sign the follow-up, but he has violated the notary signature rules. As you can see, the signatures were concentrated on three of the eight people. |
|
A team that has made multiple glaring errors in its LDN also bills itself as "the judge of the world enforcing the law everywhere." Isn't this a big joke? |
|
@lyjmry, it's quite evident that you're determined to bring everyone else down with you. However, I must admit, I appreciate the fact that you're not hiding behind a throwaway account like most others do. I'm genuinely curious if you fully comprehend what @kevzak has written here or if you're simply asking questions with no possible answers in mind. |
I'm not trying to drag anyone down. It's not in any of my interests. I just think your team goes around picking on other LDNS. And to others pointing out your violations described as noise. It's not in keeping with the fairness of the community. |
|
And, obviously. Your LDN did have multiple violations. |
We don't randomly select disputes. Instead, we meticulously provide transparent and concrete on-chain evidence for each of our cases. |
The key distinction lies in our transparency – we back our claims with solid evidence, offer clear explanations, and refrain from engaging in actions like extensive self-dealing with hundreds of PiB's while falsely distributing them through VPN services, which seems to be the practice of about 95% of the LDN's currently. Go out there and take a look for yourself. Labeling us as similar to those is a result of your perspective, not mine, as our approach and actions speak for themselves. As for your suggestion, would active PL members and large public companies be willing to defend us if we were genuinely the abusive entity here? It seems highly unlikely to me. |
NO NO NO! It's not as noble as you say! I've been watching for a while. Every time your team started a fight, it was after you were no longer able to sell data profitably on Bigdata. |
|
Because after the community shuts down because of the tools you make, you profit for a long time. But after the community implements your standards, you will upgrade them again. |
|
Your intent seems to be not to better the community, but to prevent others from taking your share of the market pie on Datacap. |
Why don't you just buzz off with your blackmailing tactics and shit. You won't get me to approve your LDN, Period.
|
|
If you want to prove that you really do care about community development, you can stop distributing LDN. One heart to guide the community to do compliance things! That's beautiful. |
Buzz off. Go away. |
|
Which “pie” are you referring too? There is over 1EiB of datacap out there we barely hold 0.2% per accepted trench for our single application. |
|
@lyjmry why are you blackmailing @cryptowhizzard ? This is extremely illegal. |
I was just testing his principles |
That's not my focus.Because I know that technical errors can lead to such mistakes. This is understandable. |
|
@raghavrmadya @kevzak @dkkapur Asking for dispute closure. |
|
hello, as you are a notary, we need an explanation why do you sent so many deals of data to only one/two/three SPs? |
Client Application URL or Application Number
filecoin-project/filecoin-plus-large-datasets#2008
Client Name
Dcent
Client Address
f1mgnwoczfj25foxn4555wvwyak6rsynzy7z73azy
Amount of DataCap to be removed
105PiB
The text was updated successfully, but these errors were encountered: