Closed herrehesse closed 1 year ago
I was in the call where this was discussed, and liked it a lot. I don't anticipate there being any problems: folks can always re-apply for datacap from closed applications, and I'm happy (with my notary hat on) to work to get any false positives back on track if there are any.
I think it's worth noting that I'm sure anyone misusing this datacap is watching these discussions carefully. While I suppose that the market for datacap will be immediately impacted (and I can't think right now of any obvious mitigation), it seems like it's something that benefits from rapid action.
Happy to support and help,
d.
I was in the call where this was discussed, and I endorse this. In the unexpected case of false positives we are ready to help.
Just one remark; This proposal is needed b/c upstream there are still notary's who are signing on requests where they should not. The workload this proposal causes should be temporary and not permanent b/c upstream things are broken.
I am in favor of this proactive solution to safeguard the integrity of the Filecoin network. Removing DataCap from closed LDNs after 7 days can certainly help prevent potential abuse and maintain trust within the community. This proposal demonstrates a commitment to maintaining the network's reliability and security
Yep this makes sense to me. Would support moving quickly to implement if technically no concerns by people.
I do NOT support this proposal, unless the current closed ones get a chance to reopen without need to reapply.
All my LDNs are closed right after last trenche was approved. There are balances on them and actively onboarding.
You cannot assume all of such instances are all abusive. There was no prior communication about when a issue should be closed.
I will be very affected by this implementation.
@kernelogic, if this proposal passes, we plan to do it in phases starting with the oldest ones (Sept - Dec 2022). Are you still actively onboarding those LDNs?
@raghavrmadya Yes I am still onboarding LDNs from that timeframe. BUT,
In fact it's not even about whether I am still onboarding or not, it's about the being called abusive by simply onboarding slower. It damages the reputation of affected clients and the integrity of the program.
Removing DC is the highest level of punishment and Fil+ guidelines do not say how quickly or slowly DC should be used. Are all clients who don't confine to the weekly onboarding plan abusive?
My suggestions are:
@raghavrmadya I think @kernelogic's argument is more moderate, less extreme.
kernelogic has a point!
Thanks @kernelogic for your reply. It is important to note that the proposal does not outright call all closed LDNs abusive and merely states that they poses a serious risk to the Filecoin network from a DC abuse standpoint.
DC abuse from closed apps falls broadly in two categories -
Client/Applicant transferring the keys to ledger in an open market
SP who applied either on behalf of the client or in disguise sealing garbage using that allocated DC
Today, we have no way to address 1. without removing DC from client wallets that are sitting on unused DC.
As the proposal outlines, this potential step is a preventive measure aimed at curbing imminent misuse and mitigating risk.
As this would be a mass action, no particular client or LDN is being or will be singled out and I do not see how it would damage the reputation of affected clients. Those clients would be welcome to apply again as the proposal does not prevent them from doing so.
As far as the program integrity goes, IMO taking necessary steps to address DC abuse is within the bound of program integrity and we everything is being done publicly.
Replying specifically to your suggestions:
"Dispute problematic LDNs individually through dispute channel, provide evidence, even if it's closed. Do not assume they are all being sold and misused and do mass destruction against them."
This isn't possible for category 1 abuse as described above. For category 2 abuse, we would need retroactive retrieval sampling, maybe randomized, and the lift from notaries is very high. I only see very few notaries being able to conduct retrieval sampling today.
Do you have any suggestions on this?
Allow closed LDNs to reopen if still onboarding.
Reopening wouldn't make sense if DC is removed from an LDN is removed IMO. Client should apply again.
Notify clients when a LDN should be closed.
The current guidline based on #818 is 14 days.
Amend the FIL+ rules regarding how long a LDN can exist, when a LDN should be closed and what are actions going to be performed on the closed LDNs. Note that there are many aspects can affect onboarding speed, gas being the top one.
I agree that onboarding rates depend on a range of factors including gas, finding SPs, etc. but 1 year to onboard seems unusually high to me.
Regardless, I see this proposal and a risk mitigation effort to address the two categories of abuse and not a stab at client reputation of closed LDNs
Client/Applicant transferring the keys to ledger in an open market SP who applied either on behalf of the client or in disguise sealing garbage using that allocated DC
Both of these issues are not specific to closed apps. Where are the evidence that closed ones are more likely to be sold/abused than the active ones?
Reopening wouldn't make sense if DC is removed from an LDN is removed IMO. Client should apply again.
I mean allow active client to reopen before the action is taken place so that it won't be included in the mass removal. Because clients were not informed LDN should not be closed until onboarding fully completed. Many clients including me thought LDN should be closed as soon as last tranche is approved to help clean up the issue list.
The current guideline based on https://github.com/filecoin-project/notary-governance/issues/818 is 14 days.
Again this is unclear, after the last tranche is approved, client has 14 days to use it up otherwise subject immediate balance removal? Right now the auto close bot is very buggy, just today it closed more than a dozen of my LDNs despite I left comments asking to remain open. If auto DC removal are based on a buggy bot, it will bring more trouble than help.
I agree that onboarding rates depend on a range of factors including gas, finding SPs, etc. but 1 year to onboard seems unusually high to me.
Need amend rules on how long is too long (and how short is too short), from governance perspective.
Overall, this issue is crafted with a sense of urgency but there is no list, no number, no vote, no consensus, just a couple folks show up in a quick meeting and it's considered "no significant community pushback". I am not a fan of how casual things are decided with mass destructive outcome.
Agree with @kernelogic. We oppose this proposal because it blurs the distinction between closed LDNs and abusive LDNs.
Regardless, I see this proposal and a risk mitigation effort to address the two categories of abuse and not a stab at client reputation of closed LDNs
Not support! It's necessary to define whether the low onboarding rate is abusive before discussing this proposal. Otherwise, it will only increase community friction and worsen the already poor onboarding rate.
4. Amend the FIL+ rules regarding how long a LDN can exist, when a LDN should be closed
I agree with @kernelogic on this. I support removing outstanding DC in LDNs closed due to disputes or other usual reasons. However, those LDNs that were closed after the last tranche of allocation should be exempt from this action.
With this, I think it might be good to keep the LDN open even if the last tranche has been allocated (may put a tag on it, so that notaries can filter and ignore them) and close them after all DC being used up.
Removal of DataCap from Closed LDNs is the correct subject but "Prevent Misuse" means gaslighting to the community. Don't be politically correctness all the time.
If this proposal is to be implemented, the following criteria must be met first:
Hello @kernelogic,
Thank you for your invaluable input regarding the modification proposal. We're keen to understand how this will differentiate between honest and abusive clients.
It's vital to recognize that genuine clients might be adversely impacted. Their LDN applications, 14 days after the initial bot message and seven days after closure, will result in the deduction of their remaining datacap. This would challenge their continuous efforts to introduce valuable data to the network, as they'd have to navigate the process of reapplying for a new LDN and undergo KYC & #922.
A few honest questions:
I'd like to invite everyone who believes their closed application still holds potential for network onboarding to share their application numbers below. Request the reopening of your LDN, engage with the KYC application and the proposal #922, and transparently list your minerID's, business names, and regions. By doing so, we can maintain the LDN's active status and facilitate your onboarding endeavors. If this isn't feasible, then our concerns are validated.
If an LDN doesn't align with the #922 standards or can't undergo the necessary due diligence, its closure will be upheld and the associated datacap will be withdrawn.
Regarding potential abusers, the community has noticed an increase in improper datacap sealing to bolster individual mining operations or for illicit resale. This proposal is a significant step to curb such activities and thus seeks the endorsement of the upright members of our community.
KYC on SPs would stop soon.
Fundamentally, much of the abuse originates from closed LDNs that failed to comply with #922 criteria, are entirely non-retrievable, misrepresent their storage contents, or are involved in self-dealing. If your closed LDN adheres to the guidelines of Filecoin+, you're welcome to continue. Otherwise, the associated datacap should be revoked.
The argument that legitimate clients might be affected shouldn't hinder this proposal. Such clients can easily reapply. This initiative aims to eliminate a substantial amount of datacap that could be exploited abusively.
The majority of genuine clients we're aware of maintain their LDN as active. Therefore, this issue isn't of concern to them, and they support the initiative to curb abuse completely.
Unfortunately, the fact is that there is DataCap abuse and because of this: new, enforceable rules will need to be continually added at the cost of adding burden to users.
I think there is good discussion and feedback in the comments above and we should continue to refine the proposal and set some agreed upon standards that allow active applicants with good intentions to continue to utilize the program, while shutting down a clear pathway toward abuse that was identified.
Two areas I see that we set standards include:
1) We can set better definitions of closure
2) We can set better boundaries on usage
Outcome we can agree on:
Next Steps:
Fully agree with the above proposal(s).
Client/Applicant transferring the keys to ledger in an open market SP who applied either on behalf of the client or in disguise sealing garbage using that allocated DC
Both of these issues are not specific to closed apps. Where are the evidence that closed ones are more likely to be sold/abused than the active ones?
Reopening wouldn't make sense if DC is removed from an LDN is removed IMO. Client should apply again.
I mean allow active client to reopen before the action is taken place so that it won't be included in the mass removal. Because clients were not informed LDN should not be closed until onboarding fully completed. Many clients including me thought LDN should be closed as soon as last tranche is approved to help clean up the issue list.
The current guideline based on #818 is 14 days.
Again this is unclear, after the last tranche is approved, client has 14 days to use it up otherwise subject immediate balance removal? Right now the auto close bot is very buggy, just today it closed more than a dozen of my LDNs despite I left comments asking to remain open. If auto DC removal are based on a buggy bot, it will bring more trouble than help.
I agree that onboarding rates depend on a range of factors including gas, finding SPs, etc. but 1 year to onboard seems unusually high to me.
Need amend rules on how long is too long (and how short is too short), from governance perspective.
Overall, this issue is crafted with a sense of urgency but there is no list, no number, no vote, no consensus, just a couple folks show up in a quick meeting and it's considered "no significant community pushback". I am not a fan of how casual things are decided with mass destructive outcome.
Agree with @kernelogic , not support this proposal.
Happy to support this proposal of removal. Better to need a formal vote as it involves unused rights of the clients.
Rights? I remember someone said datacap is a given, not a right.😂
Also, the bot bug needs to be fixed and pray to god there won't be more bugs auto close issues where it shouldn't close.
Imagine one day all of your LDNs are closed and DC removed due to unexpected bugs. I don't think DC can be recovered as simple as reopening a GitHub issue.
https://github.com/keyko-io/filecoin-verifier-frontend/issues/851
Overall, this issue is crafted with a sense of urgency but there is no list, no number, no vote, no consensus, just a couple folks show up in a quick meeting and it's considered "no significant community pushback". I am not a fan of how casual things are decided with mass destructive outcome.
Agreed! If there is a vote, i'd be against it too.
New refined version of the DataCap removal bot for stale LDN applications. Please take a look and provide feedback. Thank you!
https://github.com/filecoin-project/notary-governance/issues/974
Background
Closed LDNs have been identified as a potential source of DataCap abuse within the Filecoin network. When LDNs are closed, often by requesters, excess DataCap may remain outstanding. This excess DataCap has been found to be sold and being misused on purpose, leading to a breach of trust and integrity within the network. To address this, I propose removal of DataCap from LDNs that have been closed for 7 days or longer.
Problem Statement
The presence of outstanding DataCap in closed LDNs poses a serious risk to the Filecoin network. This excess DataCap can be exploited and sold illicitly and is nearly invisible for governance to detect, undermining the network's fairness and transparency. The current governance mechanism does not provide a way to promptly deal with this issue, allowing the potential for continued abuse.
Proposal
Advantages
Next Steps
Gather feedback from the community on this proposal. Refine the proposal based on feedback and insights. Implement the changes in the governance mechanism and communicate the same to the community.
Feedback
I invite all community members, notaries, and stakeholders to share their thoughts, concerns, and suggestions on this proposal. Your feedback is essential in ensuring that we create a robust and fair system for all.
Timeline
Considering the significance of this proposal, I recommend that the governance team begin taking action starting the week of August 21st, provided there aren't significant disagreements from within the Filecoin+ community.