Spec for content policy implementation

### 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 satisfy their proofs obligations, resulting in losing some of their stake. This seems unfair and also opens up pretty obvious attack vectors. But it's challenging to craft a system that accommodates an unbounded number of different legal systems and preferences, but is also consistent with the basic reliability guarantees Filecoin needs to provide.

We've conducted a survey of the space and confirmed that a large majority of bad content is discovered _after_ initial storage. A system that relies entirely on pre-screening won't address this problem for miners.

So, we need a mechanism that:
- Allows for the deletion of "bad" content that's already been accepted by a miner, without penalty.
- Is resistant to abuse (e.g., miners can't dump existing neutral content if the storage price goes up).
- Lets miners make their own decisions about what sorts of content they will/won't store, and communicate those decisions to storage purchasers.

This seems pretty hard. @jbenet, @mishmosh, and I discussed the problem and arrived on the following rough proposal, but we're open to alternatives.

### Proposed framework

To solve this, we're proposing an **additional step** in the bid/ask process, and a related **new capability** for storage miners. Apologies in advance if I abuse any customary Filecoin terminology, or confuse concepts as a result – please correct me.

#### The additional bid/ask step

- After a bid and ask cross, while the miner and storage purchaser are negotiating off-chain, the miner **may communicate the blocklist[s] to which it subscribes**.
- Loosely, a blocklist is a list of "bad" content (probably the double content hash of each item), according to whatever criteria the list follows. You could imagine regional law-specific blocklists, content-type blocklists, Nickelback song blocklists, whatever. These are **not** maintained or blessed by PL – it's 100% a mechanism for giving miners control over their own machines.
- Blocklists are updated periodically as new bad content is discovered.
- The purchaser can review the blocklists and, if they're unacceptable, decline to enter the contract and look for a miner with acceptable blocklists instead.

#### The new capability for storage miners

- If content held by the storage miner later appears on a blocklist to which the miner subscribed at the time the contract was entered, the miner **can decline to fulfill its proofs obligations with respect to that content without penalty**.
- To be determined: whether the remaining portion of the contract payment should be released or retained by the miner.

We hope this changes will permit **the growth of a robust ecosystem** of blocklists that miners can combine (or not!) based on their own risk tolerances and desire to comply with various laws. While it's out of scope for a spec issue, please note that we are thinking extremely hard about how to implement this from a UX and partnership perspective so that it's thoughtful and doesn't promote network-level censorship or bad behavior.

### Potentially tricky issues

- Can we set this up in such a way that it's conceptually possible to **charge for use of a blocklist**? (Maintaining these is hard, unpleasant work, and it may be difficult to sustain blocklists without incentives.)

There's further discussion of this, and surrounding issues, [here](https://docs.google.com/a/protocol.ai/document/d/1oXMyZOafAHwBeADvExBQjhYmJqmd6gXbnq7z9NWAdCk/edit?usp=sharing). Questions that aren't clearly spec-related are intentionally omitted from this issue to keep the scope as narrow as possible.

Start by reading the proposed framework and potentially tricky issues in this issue, then review the linked Google Docs discussion for the surrounding context. No repository files, tests, or implementation entry points are named; completion would require agreeing on and documenting a concrete content-policy specification.

Written by the indexing model from the issue text.