Comments (14)
Since this type of event is always possible in any geographic location it would be better to have a more general solution that can be invoked whenever it is needed. What about a mechanism where a miner could stake some collateral to get a longer termination deadline?
from fips.
Is this an announcement issued by the Chinese government? The financial committee only talked about prohibiting Bitcoin mining and trading, but did not talk about filecoin mining? I don't quite understand why it will have an impact on filecoin. fil mining is normal power consumption, right?
from fips.
There are quite a few different interpretations regarding that statement is cycling around in the last few days. Just thought it might be a good idea to do some preparation in case worst case scenario happens.
from fips.
I did not interpret the principle of fil mining in depth. I just read some articles saying that it is a post and copy proof. Without pow, it will not consume as much power and energy as Bitcoin. It should not be banned. Moreover, mining is relative to Bitcoin. Also has practical value,
from fips.
It's very necessary for this proposal, the prohibition is not only aim to power consumption, but also to prevent affect financial business by cryptocurrency. The local government may not distinguish BTC mining and other cryptocurrency mining. So miners need to migrate Storage Power out of country, and need at least 2 month due to technical and supply chain factor.
from fips.
This is a good idea. It does not affect the persistence of stored data, and can reduce the loss. If one is prepared, he will be safe.
from fips.
I personally very much agree with this proposal. The government may not be able to distinguish between BTC mining and other cryptocurrency mining. Therefore, the government should give miners the time they need to move out of storage computing due to technical and supply chain factors.
from fips.
Since this type of event is always possible in any geographic location it would be better to have a more general solution that can be invoked whenever it is needed.
I agree with this. I would also suggest that in the product consideration
section of the FIP, we can add something like, "the network should accept this FIP under XYZ circumstance only"
from fips.
The original proposal can be easily implemented but is a quite rough one, because it doesn't consider different situations in different locations, local policy might be variant and whole network wide upgrade might be tough to coordinate. So this will only be used for last measure once the central government cleanly instruct to shutdown all mining facilities within few days or week across the country. The long term solution is to allow miners to decide when to pause and resume, meanwhile mining and commit sectors are prohibited from that miner, more collateral is required to extend termination is also quite reasonable. This can make miners to be more resilient not only while policy changes, but also other disasters like earthquake or super strong solar wind which might cut off infrastructure for days or weeks but data is preserved and can be come back online later.
This will require more crypto economic evaluation though and more change on protocol level I guess, so this might take more time to implement, before that, the original proposal is still can be used as safety net.
from fips.
Basically, this is like to design a maintenance window for a miner, which could be longer than 1 month or shorter than one day. This will allow a miner pay much less cost in a particular period without requiring to submit wdPoSt when there is an early notice.
This is more like the original idea of DeclareFaults mechanism, which is reasonable. However, after the FIP-0002 is implemented, the DeclearFaults method is rarely called, since it has no much use when one could miss one round of wdPoSt in most cases. We may reconsider this, to have a better parameters or mechanisms for DeclareFaults by lowering the penalty as an option. This is reasonable, since an expected failure will have much less damage than an unexpected one.
In addition, the DeclareFaults does not extend the sector termination time, this might be added into the whole design too, e.g. when there is declareFaults on a particular sector, we push back this sector termination a proving period.
from fips.
While both approaches can achieve same goal, but the implementation difference is pretty significant. One is change on miner actor level, another is on sector level. IMHO on miner level might require less change and much less run time cost on state tree migration.
from fips.
Slightly related: #84. But that proposal is only suitable for very short periods of time.
from fips.
FIPs are created here #106
from fips.
is that fair to those who didn't have the possibility to declare such a maintenance window?
this should come with hefty costs for the miner based on the amount of sectors declared under maintenance.
[amount of sectors] * [maintenance time in epochs] = [power loss period in epochs for all sectors] for example. otherwise we will see people using this as a tool on a regular basis to avoid proving sectors.
allowing to not prove sectors on an individual base without significant penalties is a bad idea i think
from fips.
Related Issues (20)
- # TLDR HOT 2
- Weekly Governance Update (8 April 2022)
- Using a dedicated address for the sector-fault penalty HOT 1
- Optimize parallel PreCommit1 tasks speed HOT 1
- Cancellation of deposit HOT 1
- Cancellation of filecoin pledge HOT 1
- Create FIP draft for Decouple FIL+ HOT 6
- Some words to fil HOT 2
- FIP0029 terminology doesnt match the implementation HOT 1
- FIP-0029 missing definition of nominee
- FIP-0044: Verifreg: Consider modifying RemoveDataCapProposal HOT 4
- Update address for Filecoin Plus Registry HOT 1
- Allow account-level operators to set approval for tokens HOT 1
- broken links HOT 2
- FIP 104: Implement scaling payments for storage deals
- Where is the definition of 'FRC'? HOT 1
- Should we consider tagging segment and aggregate pieces differently ? HOT 1
- FIP001v2 Process Updates
- TESTS TSLT
- FIP 0075 contains an invalid `created` date in the frontmatter HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fips.