Potential abuse by notaries - asking for Governance and community review #1101
Comments
|
Addresses: |
|
More found: |
|
|
|
|
|
Pangod: f1d4yb3wags3mtddzesxoo63jv7dmlec3bq4yteni |
|
Looks like the fil+ rules are not being strictly enforced anymore, more than half of the notaries are breaking the rules now. Where is RG? |
|
filecoin-project/filecoin-plus-large-datasets#1995
It's just only one bad case, shouldn't we stop the fil+ program? |
|
Almost all SPs think fil+ is a joke. Why do these people continue? Solana's snapshot project is all about fake data stored into filecoin, and too many notaries are abusive on this case. We think the fil+ team should be laid off a long time ago. filecoin-project/filecoin-plus-large-datasets#923
|
|
"DC allocation involves subjective human decisions, opening the door to favoritism and discrimination, driving miners away to chains with normal consensus algorithms." |
|
Also more found:
Addresses |
|
Addresses |
|
Addresses |
|
Addresses |
|
Addresses |
|
With so many similar phenomena, the rules of Fil+ need to be clarified again. |
|
This issue is in regards to signatures that do not have supporting client or GitHub diligence issues. Specifically, we are seeing "first" allocations for large tranches that do not have client application records. We are scoping this GitHub issue to that specific dispute type, so other claims or disputes are off topic for this thread. If there are other disputes, we would like to track those in specific forums. We are working with the root key holders to remove the signers flagged above for large allocations with no supporting diligence. |
@MegaFil as I stated initially, the flag in this proposal is regarding a specific group of notaries signing off with no client name or address on the first allocation at 2PiBs. Your examples highlighted are all applications with client names, addresses, github links, and a variety of different signers on different allocation amounts and allocation stages. Not sure the correlation. |
@TrueBlood1 What rules are you asking to be clarified? Perhaps I can help. The general Fil+ guidelines haven't changed and have always been listed here: (https://github.com/filecoin-project/filecoin-plus-large-datasets?tab=readme-ov-file#current-scope) This proposal is to address a very specific example of notaries signing without client address or name. Let me know if you have found something else. |
@TrueBlood1 This signature was for LDN application # 975 which exists. No issue here. The link to GitHub didn't make it but you can search by using the client address. |
@TrueBlood1 thanks for flagging these but all of your examples do have client addresses listed so we can track the application. Sometimes a client name might not be listed on this view in datacapstats.io, but you should be able to search for the application in LDN github repo using the client address. Let me know if that helps. |
|
More found:
Addresses |
|
Addresses |
|
Addresses |
|
Addresses |
|
Addresses |
|
Addresses |
That's weird, even though showing unknown I found this one using f address: #1101 (comment) |
found: https://github.com/filecoin-project/filecoin-plus-large-datasets/issues?q=is%3Aissue+f02519046 |
found https://github.com/filecoin-project/filecoin-plus-large-datasets/issues?q=is%3Aissue+f02223359 |
|
The two that do not exist are 5993 cc @galen-mcandrew |
That's because you're not familiar enough with the github platform, which often automatically deletes records and account information. You should be focusing on records that clearly store junk data (like solana snapshots, etc), this time you're mistaken about what the point is again. @kevzak |
Issue Description
In reviewing https://datacapstats.io/large-datasets?limit=25, it was noticed several instances in the past few days/weeks of specific notaries signing off on 2PiB allocations of DataCap with no client name or address. Specifically:
Smart Dong
Bobbi Choi
Joy Lee
Tokencan
Impact
Potential clear sign of abuse of power
Proposed Solution(s)
Immediate removal from multisig and potential removal of DataCap
The text was updated successfully, but these errors were encountered: