specs
specs copied to clipboard
filecoin-project
The Filecoin protocol specification
Let’s talk about light clients. Before we launch, we need at the very least a compelling story for light clients. Ideally, we have it all figured out and implemented. Certain...
Filecoin client implementations should default to encrypting users data before storing it on the network. This functionality is not required, a client may store data with miners unencrypted, but for...
If content needs to be removed from the network, miners should be able to have a way to comply that is better than just 'drop the data and lose your...
### Problem statement Many Filecoin storage miners will require the ability to remove illegal content from their machines. By default, removing such content would make a storage miner unable to...
In the [recent storage throughput calculator](https://beta.observablehq.com/d/37ff2d55942d1354) I put together, A previously un-worried-about factor popped up, deal expiry. Essentially, if we assume that there is some average length of time that...
### Storage Expiry Everything on chain takes up space that must be stored by all full nodes indefinitely unless explicitly cleared out. As the chain ages and grows over time,...
#### Background Little background on Ask and Bid and Orderbook: 1. When Ask and Bid orders are added to the chain, they are added to the orderbook 2. The orderbook...
(should it check sectorID or commR?) We have a decision as a group (it should check sectorID), but let's confirm this in our comprehensive review of the spec.
The immediate influence of a bigger sector is below.(same means almost) Sector size | Replicate time | PoRep | PoSt -- | -- | -- | -- n times |...
A lot of this work seems close to landing. This issue calls out the need to get all of this great work written up in the spec and canonicalized to...
