FIP Discussion: Add a sector dormancy/revival method to facilitate the migration of Chinese storage providers overseas

[IPFSUnion]

Motivation

With full confidence in the future development of Filecoin, Chinese storage providers are actively providing storage power, which accounts for a large proportion of the entire Filecoin network. However, The new policy issued by Chinese government on September 24th proposes a comprehensive rectification and removal of Chinese domestic virtual currency “mining” projects. If the Filecoin project is to be removed, according to the current protocol, not only will it cause huge economic losses to Chinese storage providers, but the overall stability of the Filecoin network will also be battered.

Proposal

Given the above, we hereby propose to add a sector dormancy/revival method to the actor：

• Dormant Period Dormant period can be selected between 10 to 180 days. Bottom limit is longer than 10 days to prevent storage providers from using dormant period to evade windowpost penalty and a 180-day dormant period is enough for a large storage provider to move the storage device overseas and restart the service.
• About power During dormant period, the sector's storage power will be removed from the storage provider and the entire power of the network.
• Sector state During dormant period, move the sector out of deadline and put it in the dormant queue so that it does not participate in the windowpost, and can be reset to the original state (normal, expired, fault, recovery, etc.) when it revives and restarts to work.
• About wallet The storage provider’s pledged FIL will not be deducted during sector dormancy.
  The unlocked balance should also be frozen during this period and stop linear release.
  The balance can still be withdrawn normally.
• Deal sector The sector where the real data is stored is vital，we have several options to discuss.
  • Only allow cc sector to be dormant.
  • Send deal to other miner, and make clients unaware.
  • Create a multisig to let clients confirm whether to agree to dormancy, and add extra collateral for deal seator before dormancy.
• The sector dormancy operation can only be conducted once in a node.
• Due to the urgent situation, it is highly recommended to pass the FIP proposal as soon as possible by voting.

[Jasonwu123]

非常非常support

[jamesxuzm]

 support

[LanmpPython]

支持

[ypool-xiaoyaozi]

绝对支持

[rjan90]

Given the situation I can support this to help storage providers move business elsewhere. But a few considerations comes to mind:

• I think the suggestion that locked-up balance will be released normally and linearly. opens this proposal to up to potential exploits, where a storage-provider can announce dormancy for the longest duration, vest as much as possible, and then just leave.

Declaring dormancy should only be executed if the storage-provider really plans to move and start the node up again. So I think that there should be some kind of pledge or penalty to the network that they will come back online, and as such, releasing locked up tokens is not in that spirit.

It should also be considered to have a time-limit on this FIP, as the reason that Filecoin has windowPoSt and penalties for not proving your sectors, is to have the incentives aligned between clients and providers, and that providers can't just delete/remove data without getting a penalty.

[f8-ptrk]

we shouldn't do this at all. if sectors aren't proven storage providers have to pay a penalty. after 14 days sectors get terminated. if we allow providers to selectively go on holidays - what are we doing this for?

as said before, if we allow something like this the price needs to be higher than 14 days penalties and sector termination fees.

[jennijuju]

Given the situation I can see where this proposal is coming from and I agree with @rjan90 above. I personally think such dormant period shouldn’t be applied to deals sectors unless client is in agreement (this would need extra implementation), otherwise it is hard to make sure storage provider is honouring the deal and have the data available if the clients wants to retrieve the data.

A few questions:

During dormant period, the sector's storage power will be removed from the storage provider and the entire power of the network.

Is there a risk of creating an attack factor if the network experiences a sudden power drop?

the locked-up balance will be released normally and linearly.

AFAIK, a portion of block rewards is vested to prevent SPs from not fulfilling their sector lifetime promise and dropping sectors early, this applies to the committed capacity as well. If the rewards is still being vested without sectors being proved, how to ensure that the storage provider will keeping promised lifetime of the sectors after the dormant period?

[f8-ptrk]

committed capacity that is not proven is no committed capacity anymore and therefore it shouldn't be preserved. for deals i agree that a FIP like this makes maybe sense - if the deal clients agree.

AFAIK, a portion of block rewards is vested to prevent SPs from not fulfilling their sector lifetime promise and dropping sectors early, this applies to the committed capacity as well. If the rewards is still being vested without sectors being proved, how to ensure that the storage provider will keeping promised lifetime of the sectors after the dormant period?

exactly - a storage providers payout should be suspended to 100% as soon as a single sector goes on holiday.

[wisky3148]

必须支持

[likhita-8091]

I personally think such dormant period shouldn’t be applied to deals sectors unless client is in agreement (this would need extra implementation), otherwise it is hard to make sure storage provider is honouring the deal and have the data available if the clients wants to retrieve the data.

@jennijuju ，Actually, there are very few users who actually store data now, right now, it’s time to go to sea, otherwise it will be more difficult to migrate in the future. 🐶

[IPFSUnion]

Given the situation I can see where this proposal is coming from and I agree with @rjan90 above. Is there a risk of creating an attack factor if the network experiences a sudden power drop?

the locked-up balance will be released normally and linearly.

AFAIK, a portion of block rewards is vested to prevent SPs from not fulfilling their sector lifetime promise and dropping sectors early, this applies to the committed capacity as well. If the rewards is still being vested without sectors being proved, how to ensure that the storage provider will keeping promised lifetime of the sectors after the dormant period?

@jennijuju

1. More than 60%(not sure yet) power, including real data in it, maybe loss suddenly if no measures are taken to deal with this Chinese policy adjustment.
2. About deal sector and unlocked balance, I agree with it and have made some adjustments.

[f8-ptrk]

i do not see any risk for the network if a few incapable storage providers fail. as someone mentioned here there is close to no client data involved. the danger for the network is this FIP and watering down rules that are the core of the network: if you do not prove your storage you pay penalties.

[cryptowhizzard]

We have an N+1 running storage here on different locations and invest much money to do this, to store data for humanity, securely It is easy to keep everything running while moving the redundant part out of the country. After such operation is done, it is easy to switch.

The people who have chosen not to do this strategy accepted their risks and were on the network just to pledge 0000' s and 1111' s. I don't see any benefit for the network to keep their pledged sectors alive, hence i see more damage to rewards that eventually should be ours b/c we are on the right path.

[herrehesse]

Completely agree with Cryptowhizzard and F8 here. Changing how we penitialize our current way of loosing stored data is an extremely wrong path to take.

If these providers would really want to store the data for future generations, why are they not N+1 redundant? Normal operations could move their mirror over seas and continue with providing proofs. If they choose to not operate like this, it is not the filecoin network rules that must change, but their own.

[benjaminh83]

This would really jeopardise the trust less backbone of filecoin, and there is no reason for solving the practical problem with this kind of proposal. No real clients should/would accept months of downtime on services because the underlying hardware was in transit. So I agree on the “build N+1 and move it out” approach - like anyone would do if handling real applications/data.

[arajasek]

I'm sympathetic to the real-world concerns motivating this discussion, but unfortunately I don't see a way to do this without some serious reconsideration of Filecoin's security model and SLAs with clients.

[Angelo-gh3990]

Same here I agree with Cryptowhizzard, Benjamin, Herrehesse and F8 , most of us are putting a lot off effort into maintaining an enterprise n+1 approach to data as a storage provider and not just a creation of empty sectors to mine block's. Changing the protocol this way shouldn't be the way to go. If this was an Enterprise environment then uptime of the clients deal data should be the main concern. And not maintaining status on the network.

[chiwanniuroufen]

This is a very nice issues, It's not IPFS that needs to change the rules，it's us. If you don't follow the rules, you have to accept the fine. @IPFSUnion

[likhita-8091]

Same here I agree with Cryptowhizzard, Benjamin, Herrehesse and F8 , most of us are putting a lot off effort into maintaining an enterprise n+1 approach to data as a storage provider and not just a creation of empty sectors to mine block's. Changing the protocol this way shouldn't be the way to go. If this was an Enterprise environment then uptime of the clients deal data should be the main concern. And not maintaining status on the network.

The Chinese region occupies 90% of fil's computing power. The rules are dead and people are alive. N+1 makes sense, but no one expected China to issue such a policy. If measures are taken improperly, China’s policy is slightly stricter:

1. This will cause a large number of miners' coins to be fined for no reason
2. Miners gradually lose confidence in fil,
3. It will also make most of the miners unable to survive,
4. It also brought a substantial drop in fil's computing power, and the currency price fell into scum.
5. In the end, no one wants to build storage for you and realize the great dream of fil.

Of course, if you do nothing:

1. Let some people who fight counterfeit, small-scale, and mine for the sake of mining know the difficulties and retreat. In other words, to make storage service providers more high-quality.
2. Maintain the original intention and image of fil, and exist as a god.

[whyrusleeping]

I'm generally supportive of this, but also want to ensure that the mechanism cannot be easily abused.

Some unstructured thoughts:

• I think we can work around some of the security conerns here by only allowing a miner to go dormant once. (maybe once ever, or once a year?)
• 180 days feels a bit long. I would push for this number to be shorter
• All deal profits should be forfeit and refunded.
• The gas costs involved here will be difficult to manage, especially if we do anything 'per deal' or 'per sector'
• Miners should have to pay a fee (burn funds) to do this, the fee can be fairly small proportionally, but I think it needs to be there
• Doing this should incur a 'penalty period' upon returning, where you cannot earn any funds from block rewards for some period of time after coming back, to ensure miners dont attempt to abuse the (potentially large) increase in power they cause by coming back online

[f8-ptrk]

Miners should have to pay a fee (burn funds) to do this, the fee can be fairly small proportionally, but I think it needs to be there

there is already a burnfee for not proving sectors!

we can just exempt sectors from the 14 deadline they would be terminated at if there are no deals in the sectors. then we do not have to change a lot. limit it to once ever and abuse will not occur i think

[whyrusleeping]

@f8-ptrk how much is the burnfee for not proving? I dont want the fee to be so high it financially wrecks people

[f8-ptrk]

2.14 worth of expected blockrewards per every 24h not proving a sector i think

https://spec.filecoin.io/#section-algorithms.cryptoecon.initial-parameter-recommendation

so in my eyes you will get a holiday period of 5 days back in within 10 days. that's not wrecking people - at. all. but we would have to check that again.

it would just be fair to have the same penalties occur as for people who do not choose to not prove but cannot prove.

[jbenet]

Some quick thoughts as well. First some background -- feel free to skip down to the last part ("some thoughts for this issue now").

network improvement principles

• It's important for the filecoin network & community to respond to major world events (natural disasters, policy changes, etc) in a resilient way -- lots of challenges will come that must be overcome together
• Improvements and upgrades to community processes, services, software, and protocol should serve the needs of the whole filecoin network, and all its participants
• Everything needs to be carefully balanced and incentive aligned, all participants should be doing better together. (aim for pareto improvements, and growing utility and value for all wherever possible)
• ("never waste a good crisis") Use problems to motivate solutions that leave things substantially better than they were before.

storage network principles

• Client data must be stored safely at all times (no loss).
• Client data must be available at all times (zero downtime).
• Client requests must be performant at all times (no or little degradation).
• Storage networks must keep many copies of data around the world to be resilient to problems.
• Storage providers must be able to relocate their operations (without it being cost prohibitive).
• Moving data is best done by transferring the bits live over the internet, verifying successful copy. This may not be possible or cost-efficient for too large amounts of data (many PiB or EiB).
• Moving physical drives is tricky. Cheap HDDs break easily. It may be best to transfer in SSDs, or with high replication factors (use erasure coding / RAID schemes).
• Moving hardware is expensive -- sometimes it may be cheaper to buy new hardware and sell old hardware than to move old hardware. This will vary per operation.
• Moving large operations is more resiliently done by parts / streaming (putting all hardware into one single storage container risks complete loss -- best to ship by parts).

migrations

• 1. Live migration. The way most computing systems operate in the world is to achieve live migrations, where service to clients is not interrupted (no loss, no downtime, high performance).
  • Services that have many copies/endpoints can live migrate by shutting down any copy, and resuming it elsewhere.
  • Individual services can be live-migrated by first replicating the service (ie copy and move the data) and then redirect traffic to the new service endpoint (switch). After the service has migrated, the old copies/resources can be reclaimed.
• 2. Suspended migration. Some services cannot (or are to expensive to) migrate live. In these cases, service is suspended gracefully, service for clients degrades for some pre announced time, and then resumes quality of operation.

Specifics in filecoin today

• Filecoin achieves network-level resilience by encouraging many copies across service providers, in different regions -- client data should have many copies and therefore tolerate failure of single storage providers.
• The DeclareFaults mechanism already takes into account a grace period for individual storage providers to suspend operations and resume them afterward.
• Migrating deal sectors can be done by moving the sealed sectors, or by retrieving copies of the data and re-sealing it (whichever is cheaper to the storage provider). But it is critical not to lose the data, and not to lose service uptime (can't have all the storage providers storing all the copies shutting down at the same time, or service uptime will be lost. Cant have all storage providers hoping to retrieve the data from each other, or data will be lost).
• Migrating committed capacity sectors can be done by moving the sealed sectors, or re-sealing from scratch (whichever is cheaper to the storage provider). Migrating committed capacity does not need high availability/uptime itself.
• Power in consensus (which committed capacity contributes to, and currently is the larger fraction) must not fluctuate wildly -- this is dangerous from a consensus standpoint. So committed capacity shouldn't shut down and resume in too large amounts (traditional consensus bounds apply). However, the network can indeed tolerate graceful decreases and re-increases in power (we've already seen many large amounts of power be faulted and resume without any problems.
• Incentives should always reward high uptimes and availability of all services, and penalize downtimes.
• Long downtimes are not good for the network, neither in terms of client data or committed capacity or consensus power. 180 days is way, way too long. That should not count as a migration.

Here are some thoughts for this issue now

• Storage providers should endeavor to live migrate deal sectors -- that means copy the data over, and set up a new endpoint before shutting down the old one. This should not be a big problem today, as all the deal data is ~32 PiB, and only a small fraction needs to migrate. The two-week DeclareFaults grace period, including its fees, is already the right incentive structure for client data.
• Committed capacity can undergo suspended migration -- and could be longer than 2 weeks (relocating EiB is not easy), as long as we dont create a problem for consensus power. If we have graceful suspension and resumption of power, and an appropriate incentive structure (this could be either higher collateral or network fee), the network could tolerate longer migrations of capacity (4 wk?), without loss of sectors (and collaterals).
• Suspension of a fraction of CC sectors per actor -- graceful consensus power changes. One way might be to enable suspended (dormant) migration of CC sectors up to some % of the miner's total power at any time (20%?). (The network fee or stake should make it irrational to do this in general, and irrational to reuse storage space / interleave in time to inflate storage power -- this means network fee or TVM has a low bound of the CC sectors reward). This could allow a storage provider to migrate hardware in parts and bring it online elsewhere. This might be hard to do with the software today.
• Suspension of whole actors I think this is hard to make work in general. if they have any deal data, that should not be allowed, or should require some special casing to keep user data available during the period. We would need to measure the amount of suspended power across the network, and rate-limit it (hard limits as a percentage of total QA power, or a dynamic fee structure that increases w/ percentage). This is hard to balance, and creates bad incentive structures for everyone (who gets to go first?) -- i would recommend against this, unless some very simple solution that balances problems emerges. If time is important, i think this will likely take longer to figure out and implement.
• Fastest option to implement: extend fault period from 2wk to 4wk or 6wk. Would need calculating the right fee structure, but it might be easiest/fastest to design and implement.
• Boat freight can take about 15-30 days for shipping boats to travel across an ocean. 4 - 6 weeks might be the right number as max suspended migration time limit. (I'm not sure ocean freight is indeed cheaper than air freight though, all costs considered (including time and lost block rewards)... )
• Business for someone on the Filecoin island economy: buy or rent a jet, paint it filecoin colors, help miners relocate, charge in FIL. (precedent).

[jbenet]

Btw, tons of great comments overall here, both in original proposal (very well thought out!) and in all the technical comments -- solid discussion so far -- keep it going, let's figure this out together

[cryptowhizzard]

@jbenet although i understand where you are coming from i still do not agree.

If we allow this, then it means that we have made the wrong decisions while investing in our setup to be N+1. We payed money for that while keeping in our mind that in the case of emergency we always have a backup somewhere else. We could have invested that money into extra workers to get extra sectors and thus extra FIL, however we choose to mitigate the risk while some others did not => People like @CodingJzy acknowledge this as they thing N+1 is to "expensive" reading his/her post above so they benefit from us with higher risks / rewards.

If the people in China would have done N+1, then they can just ship their N+1 backup elsewhere , sync it ( if at all , perhaps they can pause a few weeks of pledging sectors ) and put it online again elsewhere. There is no downtime whatsoever, so let' s not make this more complicated then it really is.

This is the right path forward for moving a farm and it still can be. In China there are enough harddrives available to sync your farm and then ship them elsewhere while not mining , but just keep storage online, being compliant with their new regulation. Yeah , the costs are high ... But they should be high to be a fair game to the people who did invest in N+1 and payed a lot for hardware to make this network resilient.

So my take, moving a farm without N+1 should, perhaps be allowed in a fixed period time ( like between now and 6 months from now ) to alleviate the current situation, but the penalty fees should not be adjusted. 14 days fines, that' s it but after that one can keep the sector. One can bring their sectors online again and start over from there with mining blocks and build their collatoral.

[likhita-8091]

Hello, @cryptowhizzard ! I think you misunderstood my point of view. Although I am Chinese, I did not participate in mining. I don't support anyone. I just listed the worst results if you agree and the good results if you disagree. These worst results are not used to threaten you.I live in China, I feel the authority of the Chinese government, and I also know the characteristics of Chinese miners. If a compromise solution can be found, tragedies can be avoided to the greatest extent. It’s better not to kill one hundred by mistake instead of letting one go.

As you said, If the people in China would have done N+1,

If the people in China would have done N+1, then they can just ship their N+1 backup elsewhere , sync it ( if at all , perhaps they can pause a few weeks of pledging sectors ) and put it online again elsewhere. There is no downtime whatsoever, so let' s not make this more complicated then it really is.

so I said: Through this emergency, some miners who falsified can be kicked out only for making money; instead, better, The storage service providers who did the real thing survived. This is good for the future.

[f8-ptrk]

@CodingJzy

this is basically asking for an exclusion from fault fees - to save costs on the back of the network. thats all. migration from china can be done within 14 days. no matter where you are you will be able to migrate to hong kong within 2 weeks. Chinese storage providers want to wait and have a safeguard for events occurring suddenly. it was clear that this would happen 3 month ago - everyone who hasn't migrated now has to bear the uncertainty or just move - i see really no problem in doing that. sure the costs will be ugly - but i don't see a reason why the network should be responsible for the costs individual businesses have when making bad business decisions.

btw. smart operations already migrated over the last 2-3 month. to taiwan, singapore - you name it.

[lanzafame]

I agree with @f8-ptrk that fundamentally this is not a network issue but a business issue. There are several avenues available to miners to migrate, though they are expensive, those costs should be the burden of the business not the network. Just in the same way we don't demand that the network pay for the tax burden on miners in jurisdictions with higher taxes, the network shouldn't pay for the choice of miners to setup in a particular country. A risk/reward analysis of setting up in China should have been done, which should of included the Chinese government's unsteady feelings about crypto as a risk and that there was potential to end up in the current position.

[jennijuju]

Fastest option to implement: extend fault period from 2wk to 4wk or 6wk.

extend the fault period by X days may cause client's collateral/funds to be locked up for X more days without data being proved to be stored. If the fault period extension approach is taken, i think core dev should consider https://github.com/filecoin-project/specs-actors/issues/667 as well.

[neogeweb3]

Migrations could be complex and risky to perform, like the hardware being detained by the customs by either side for over two weeks, etc. I have some quick thoughts as the supplementary plan for emergencies.

Note: this would only apply to Committed Capacity.

Option 1: The sector life cycle can be set backward for sectors with life that are greater than 180 days.

Option 2: Reduce the penalty for Committed Capacity. penalty=max(SP(t), BR(StartEpoch, 20d) + BR(StartEpoch, 1d) terminationRewardFactor min(SectorAgeInDays, 140))

1. Change BR(t), StartEpoch to the current time, using the current single-day expected return of the sector to calculate the penalty.
2. Reduce 140 days in the penalty parameter to 60 days, reducing the upper limit of the penalty of existing sectors.
3. Convert the cut-off penalty to lock-up; that is, the cut-off sector penalty is not fully deducted, and convert part or all of it to lock-up release. The lock-up vesting period can be set for a longer time, like 180 days release.

[herrehesse]

@jbenet @jennijuju I do not feel comfortable at all adjusting one of the most important security measures of the filecoin network to help a few large operations who deliberately did not invest in redundancy. It is known that the chinese government is not in favor of cryptocurrency mining for a decent amount of time and these entities still not invested in offshore storage for their operations.

Explain to me, why should the network change? So many others did the work and have N+1 installed on offsite locations in case of emergency. Now that the befenits of this approach become obvious, we turn around and change the network for the risk takers? Most of them are not even storing any important data, just empty pledges.

My take on this: Help them move all sectors containing actual data. I myself would love to host multiple PiB's for them to help them during moving. All to keep the filecoin network stable and secure. But i am NOT willing to change our protocol to let them move 100's of PiB's of non redundant empty pledges.

[Fatman13]

Can someone please help elaborate what N+1 is and how it works in context of filecoin? Thank you.

[f8-ptrk]

you store N+1 copies of the data you store while the +1 copy is not in the location the other copies are @Fatman13 then you just move the +1 to a new location and start proving while migrating the N copies

a storage mirror in the simplest case

[herrehesse]

@Fatman13 It's mirroring the data to make sure the integrity wont be compromised in any circumstance. Like what is happening right now.

[Fatman13]

which means when you done sealing, you store 2 or more copies of sealed sectors in potentially 2 or more locations?

[herrehesse]

Or, if you want to go full-fancy:

When you are done sealing you store the sector on a extremely fast storage server for fast retrieval and proofs. Then you mirror that storage server to a slow but highly redundant (raidz-3*) storage server offsite.

[Fatman13]

Could there be a new type of miner, say, migration miner besides storage and retrieval miner? Just throwing ideas...

[f8-ptrk]

@Fatman13 the basic problem many people here have is that it is really hard to understand why a "migration miner" or whatever this is asking for should lead to a cheaper solution for not proving sectors. if we allow a "migration whatever" it should at least come at the same if not higher costs of not proving.

if you ran el'cheapo operations for 15 month and now have a problem, tough shit, but hardly a problem the network/protocol should take care of. man up and find a solution for your problem.

[Fatman13]

I am thinking say M is a migration miner and S is a storage miner. They could strike a deal and through online or offline sealed sectors could be transferred to M from S while S losing power and M increasing power with no interruption of services. Kind like how a storage deal is done now but a migration deal. If that make sense at all. Effectively a market of buying and selling of power on a high level...

[f8-ptrk]

no one stops you from proving in two locations with the same miner ID. just relocate the sectors and prove them in the new location.

a pledge is a pledge. and if you do not honor it you do not honor it. and we shouldn't give any incentives to do that.

[xiaoliwe]

no one stops you from proving in two locations with the same miner ID. just relocate the sectors and prove them in the new location.

a pledge is a pledge. and if you do not honor it you do not honor it. and we shouldn't give any incentives to do that.

yes, agree with it, but we should consider the real events.

[herrehesse]

@shibowe You know what is also a real event? Large scale miners not having redundancy while knowing the risks of operating 100% on mainland china.

[ypool-xiaoyaozi]

If there is such a day, I wonder whether we can consider developing new functions and developing a sector life cycle customization function to make the existing sectors expire in advance without sector termination, which can reduce the loss. However, in this way, a large amount of money will circulate to the market, which will have an impact on the market price and the ecology. Let the sector expire naturally and make corresponding compensation for the storage order with filecoin plus

[dayou5168]

I don't really support this option in principle either. 1: We seem to be paying for a one-off event, which will lead to a degree of unfairness, but it is important to note that we are facing a crisis together, and it is not good for the long-term development of filecoin if Chinese storage providers are hit hard, so we should help Chinese storage providers through this difficult time, if not through a proposal, then through other ways of providing some help. 2: I think a mass migration of storage providers needs to be studied for feasibility, even if such a proposal is passed, will there really be a mass migration? The situation of each of the big storage providers in China is different, and this is not a technical problem.

So I think we should put our energy into how to help Chinese storage providers migrate and discuss this proposal on the basis that migration is feasible.

[rjan90]

I agree with all the listed network improvement principles @jbenet, and in particular that major events like these can improve the network as whole as long as it serves all the participants in the network (storage-providers, clients, devs, investors, ++). Either if that is to keep and solidify the security measures already put in place in the network, or improve/change them to something all participants can agree on. And a decision like that should definitely not be rushed.

• Storage providers should endeavor to live migrate deal sectors -- that means copy the data over, and set up a new endpoint before shutting down the old one. This should not be a big problem today, as all the deal data is ~32 PiB, and only a small fraction needs to migrate. The two-week DeclareFaults grace period, including its fees, is already the right incentive structure for client data.

• Committed capacity can undergo suspended migration -- and could be longer than 2 weeks (relocating EiB is not easy), as long as we dont create a problem for consensus power. If we have graceful suspension and resumption of power, and an appropriate incentive structure (this could be either higher collateral or network fee), the network could tolerate longer migrations of capacity (4 wk?), without loss of sectors (and collaterals).

My concern here, is that it seems storage providers that mostly have client data would be "worse off" then a storage provider which mostly has CC-sectors. Especially if paired with a reduced penalty but longer period for CC's. If anything, I really think this FIP-proposal should adhere to these two network improvement principles:

* Everything needs to be carefully balanced and incentive aligned, all participants should be doing better together. (aim for pareto improvements, and growing utility and value for all wherever possible)
* ("never waste a good crisis") Use problems to motivate solutions that leave things substantially better than they were before.

And that is especially to grow the utility and value of the network, which in my opinion is to store actual data. And thus this FIP should be tweaked so that after this, the network wants to actually store more data after it is implemented. And I'm seeing a risk that if not properly tweaked, this proposal might make even more storage-providers consider just having CC's, as that gives you more time for suspended migration.

Is the network too immature? I had a similar thought as @Fatman13 wrt to a "migration miner". If we had the earlier proposed "repair miner/storage-provider", there might have been some incentive structures where the network could replicate the data when you declare that you want to migrate, having the SP paying a fee for it, since they have run with a higher risk by not having a extra copy. And also allow for longer migrations-period of CC-sectors without risking that more SP's op in to mostly store CC's.

FIPs & discussions similar to this has already come up a couple of times, and I'm linking to them for historical context: #103, #84 #106

[s0nik42]

I agree with @jbenet on the principles and Idea to be able to extend the DeclareFault period for CC

BUT We should take the opportunity of this crisis to improve the network :

Today CC is more advantageous compared to unverified deals on a reward standpoint :

• its cheaper to produce (No PublishDeals fees)
• much simpler to operate and forecast but rewarded the same.

If we now also extend the DeclaureFaults period for CC but not for unverified deals. we create even more disadvantage to store deals and we don't incentivise the miners to move from CC to the storage market.

I would like us to consider reviewing the ratio of CC versus Unverified deals like :

Verified : x10 Unverified : x1 CC : x0.5

I really think the network as a whole will benefit from that and consider more move to the storage market

[IPFSUnion]

We have carefully considered and discussed all the above suggestions and proposals, and believe that the extend fault period from 2wk to 6wk proposed by Mr. Juan can not only alleviate the current situation, but also minimize the threat to security and principles of the network.

[f8-ptrk]

@s0nik42 if CCs are x0.5 people just put deals in every sector. it's not manageable - we will all pay more for the gas usage increase on the chain.

we should allow miners to extend the forced termination deadline and then maybe forbid these sectors to be terminated and to be extended or cut their adjusted power by 50% - or all of these. it needs to come at a price in addition to the normal fault fees.

[s0nik42]

@f8-ptrk in that case they will have the same obligation than people doing unverified deals, no declared fault xtension, and pay for publish deals.

CC providing the same power than unverified deals was decided prior this change.