Modification: Removal of DataCap from Closed LDNs to Prevent Misuse

[herrehesse]

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

1. Datacap Removal: As soon as 7 days after an LDN is closed, all outstanding DataCap should be removed. This action does not require an investigation into abuse, as the closure of an LDN itself is a valid reason for removal.
2. Monitoring and Reporting: Implement a system to monitor LDNs and report closures in real-time. This will enable swift action to remove DataCap.
3. Transparency Report: Publish a regular report detailing the closed LDNs and the DataCap removed. This ensures community awareness and trust in the process.
4. Reapplication Process: Should an LDN require reopening, the client must submit a new DataCap application, which will undergo regular review along with enhanced KYC procedures and considerations from #922.

Advantages

1. Curbing Imminent Misuse: Initiating with the closure of all current closed LDN's who are older than 7 days, the community can prevent imminent datacap misuse.
2. Mitigating Misuse Risks: Eliminating DataCap a week post-closure cuts down the chances of unauthorized sales or misappropriation.
3. Building Confidence: Prompt and clear-cut measures will reinforce and boost the community's faith in the Filecoin network and Fil+ program.
4. Equitable Allocation: Guaranteeing DataCap is assigned solely to active LDNs ensures a just distribution among genuine participants and miners.

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.

[dannyob]

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.

[cryptowhizzard]

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.

[C00kies77]

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

[mjroddy]

Yep this makes sense to me. Would support moving quickly to implement if technically no concerns by people.

[kernelogic]

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.

[raghavrmadya]

@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?

[kernelogic]

@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:

1. Dispute problematic LDNs individually through dispute channel, provide evidence, even it's closed. Do not assume they are all being sold and misused and do mass destruction against them.
2. Allow closed LDNs to reopen if still onboarding.
3. Notify clients when a LDN should be closed.
4. Amend the FIL+ rules regarding how long a LDN can exist, when a LDN should be closed and what are the actions going to be performed on the closed LDNs. Note that there are many aspects can affect onboarding speed, gas being the top one.

[hcgun]

@raghavrmadya I think @kernelogic's argument is more moderate, less extreme.

[spaceT9]

kernelogic has a point!

[raghavrmadya]

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 -

1. Client/Applicant transferring the keys to ledger in an open market

2. 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

[kernelogic]

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.

[1475Notary]

Agree with @kernelogic. We oppose this proposal because it blurs the distinction between closed LDNs and abusive LDNs.

[MegaFil]

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.

[joshua-ne]

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.

[Destore2023]

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:

1. The bot must not be buggy like this.
2. The client must be informed and agree to the closure of the LDN and removal of the DC (based on the new requirement that clients must provide contact information to the FIL+ governance team).
3. A clear and automatic way to re-open the LDN if it has been closed in error.

[herrehesse]

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:

• Why close an application that is still active and being worked upon with clients?
• Should the LDN not remain open until the dataset is fully stored, ensuring all necessary due diligence?
• Is there a particular reason these clients couldn't initiate a new LDN, while supporting the anti-abuse measures presented in this proposal?

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.

[Dave-lgtm]

KYC on SPs would stop soon.

[herrehesse]

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.

[kevzak]

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

• For example, if an applicant chooses to 'self-close' an application, then we can agree that means they no longer need the application or DataCap. Therefore, a bot can be set to automatically remove any unused DataCap when self-closed.
• If the application was accidentally closed in error, perhaps there is a secondary pop-up question we can add: "do you confirm you want to close this?" before it automatically closes. If they click to close twice, this is considered a choice not an error.

2) We can set better boundaries on usage

• For example, let's set expiration dates on allocated DataCap usage. What would be a realistic, standard period we could agree on? 4 weeks? 8 weeks?
• If a DataCap allocation is received, and an application is auto closed after 14 days, and DataCap is still not used after 2 additional weeks (4 weeks total), then the bot automatically revokes DataCap.
• If a DataCap allocation is received, and an applicant continues to keep application open, by commenting, but DataCap has not been used after 8 weeks, then the bot automatically closed and revokes DataCap.

Outcome we can agree on:

• This will force applicants to keep active allocations open (only up to 8 weeks) and if they do not like that, they can always apply again
• These new standards will build a new habit for applicants to wait to apply until they actually are ready and need DataCap.

Next Steps:

• Any current applicant who has self-closed or has an auto-closed application has a chance to reopen the application in a set period, let's say the next two weeks (until September 1st). At that point, allocation then is on the clock for 8 weeks.
• If applicant does not do anything by Sept 1st, then any unused DataCap is automatically revoked on all closed applications that meet 1 and 2 above

[herrehesse]

Fully agree with the above proposal(s).

[MarshLin88]

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.

[Chris00618]

Happy to support this proposal of removal. Better to need a formal vote as it involves unused rights of the clients.

[kernelogic]

Rights? I remember someone said datacap is a given, not a right.😂

[kernelogic]

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

[WisseHeyne]

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.

[simonkim0515]

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